21
In Chrome, you can open the developer tools, click in the device icon (1), and then select the connection throttling (2).
Edit (2015-11-03)
Since around Chrome 45, it actually got a little bit easier: you don't have to be in device mode anymore.
17
The figure I keep hearing is that you should keep it below two seconds, that's actually Google's recommendation. There is a ClickZ article on page load times written by Bryan Eisenberg, where he mentions that:
Several influential people (SEOs and marketing execs) have shared with
me that getting load time under the two-second load time mark, as
...
14
As covered here, GitHub Pages is served with Nginx and automatically gzip's content.
You can confirm gzip compression for your site by checking the HTTP headers with online tools like this one. Enter the URL to a webpage or resource, and type in gzip under "Accept-Encoding" to indicate that the HTTP client (i.e., the online testing tool in this case) ...
12
The base64 image option should be used where you would only have a very small number of images and you want to eliminate the network overhead of fetching a picture from the server. However from what you are indicating in the question I assume this could scale to a large number of images. In this case I would use a single 1px x 1px transparent image from the ...
10
Browsers download data in parallel and try to start rendering the page as soon as possible.
If you do not specify the size, the browser has no idea how large the image is going to be until after the image download is fully complete.
This delay forces the browser to repaint or reflow the layout - delaying the page load time.
The more images with this ...
9
As of 2011, you will see the first drop in page performance after 14.6 KB has been sent. For the speediest page, all of your HTML code from the first byte up to and including the critical CSS should fit within this amount of data.
14.6 KB is the size of an HTTP server's initial TCP congestion window assuming a default TCP IW value of 10 (which was agreed on ...
answered Oct 10 '18 at 18:07
Maximillian Laumeister
5,7751 gold badge9 silver badges31 bronze badges
8
You can slow down specific resources with Deelay.me:
<img src="http://deelay.me/1000?http://mysite.com/image.gif">
Deelay.me is a delay proxy for web resources. You can use it with your images/stylesheets/scripts, to increase their load time.
8
If your framework/CMS/whatever has the appropriate functions, you can include the scripting conditionally as @Michael suggests, but without the additional library.
Taking your datatables case, for example, WordPress might handle the situation via something like:
// For reference; this isn't functional code.
if (is_page('whatever')) {
<script src="/...
8
You have no control over them because they are hosted by another provider. And honestly speaking you should not worry about them, it's up to Google, Facebook, etc to handle the caching accordingly to their need.
You could potentially proxy the URLs or download the files locally, but I don't encourage you to follow that route. In fact, you may potentially ...
8
Initial Connection
You will find that the initial connection includes negotiating the SSL, so since the handshake is high, its a good indicator that something is seriously wrong with the way you have setup the SSL.
Google Chrome: Understanding Resource Timing
Time it took to establish a connection, including TCP handshakes/retries and negotiating a ...
7
The URL change is a mix of an old feature of HTML when calling an A tag with hashes,
<a href="#home">Go to my home</a>
<p>TextTextTextTextTextTextText</p>
<a id="home">
that makes possible linking parts of the same page without reloading at all,
and a new HTML5 JavaScript window object
window.onhashchange
This new object it'...
7
There's a bunch of tools that illustrate the waterfall (the cascading chain of HTTP requests from the browser to the server):
gtMetrix (combines ySlow and PageSpeed)
pingdom tools
http://loadimpact.com/page-analyzer
webpagetest (best in my opinion)
Also, note that your point:
...browsers can only load 6 resources at a time...
is not quite correct, ...
6
For MacOSX ImageOptim optimizes the images. Internally it uses the same tools used by google page speed.
http://imageoptim.com
6
Yes, it is. Making users download useless extra image data just so the browser can resize the image to less than half the size is bad practice, and it's one of the warning signs of a poorly designed/developed website.
If you want to improve page performance why wouldn't you reduce unnecessary bandwidth usage? That's like asking, "If I want to get better ...
6
A couple of hours on, and I realise I could perhaps have checked Google Webmaster Tools before posting my question.
GWT have the kind of overview I wanted under Labs -> Site Performance
6
A review of the github Pages Documentation would suggest that this level of configuration is not made available to github Pages users.
You can contact github Pages Support to see if this level of configurability will be made available (or if they can configure for you), however, I suspect that you will find a more expedient solution by hosting your images ...
6
You can use requirejs to dynamically load the libraries you need only on that pages. Then you only have to load the requirejs (which is about 14k) on all pages, saving about 385kb.
Integration is also very easy: just "wrap" the code you have with the require include stuff:
require(["jquery", "jquery.alpha", "jquery.beta"], function($) {
//the jquery....
6
Based on your reference to the ImageMagick convert method and quality parameter, it appears you're working with JPEG images. If that's the case, the EXIF information for JPEG images does not have a standard compression level tag.
However, ImageMagick appears to be able to obtain this information from the image's quantization tables using the identify ...
6
IFrame's are by nature slower due to the overhead they add while rendering a new page within the browser window. And some browsers are slower at rendering iFrame's than others (i.e., IE).
As the chart here demonstrates, iFrames can cost up to 100x more time to create elements than scripts and styles.
IFrame's will also block a window's onload event until ...
6
Reading the title of your question, there are two things you can do to speed up the initial connection and SSL/TLS handshake. These work for any connection, not just 3G, so you should use these as best practice anyway.
First, use HTTP/2 to serve the site. This requires Apache 2.4.17 or later.
Second, configure Apache to use OCSP stapling. This requires ...
5
Please note: I am answering based on what you've described above only (which, while descriptive, isn't the same as analysing the source(s)).
To your questions above:
From Google Page Speed's own FAQ:
Some of the suggestions differ from the Page Speed browser extensions. Why?
Page Speed Online uses a different rendering engine and user agent, which may ...
5
Almost certainly no. Every network request is sent using packets usually of 1500 bytes. If the request is under 1500 bytes (including the URL, cookies etc) then it makes no difference whether it's 30 bytes or 1300 bytes. Even if a request spans 2 packets the difference would be negligible - that's definitely a micro-optimisation you don't need to do unless ...
5
If you're using the Google Page Speed extension for Firefox, then a copy of the optimized images (as well as JavaScript and CSS files) are put in a temporary folder.
http://code.google.com/speed/page-speed/docs/using_firefox.html#advanced
You can then take these out, cleanup the file names, and reuse them.
Download Google Page Speed extension for Firefox
5
You could try http://www.smushit.com/ysmush.it/
Click "Uploader" and select all images that needs to be "smushed".
Your files will be uploaded to their server, become optimized without quality loss, and you will then be able to download all images in a zip file.
5
In both cases jquery is being loaded from mountain view servers
I don't think this is true.
As you said, ajax.googleapis.com is 'located' in Mountain View (according to Geo tools). This server is responding (ping) in 24 ms (my location: Switzerland), but with speed of light it actually needs 68 ms. So I don't get routed to Mountain View at all, since ...
5
I don't have any data that directly correlates page speed with click thrus. However, this article shows how important page speed is in a variety of other areas and may be useful to you:
Amazon: 100 ms delay caused a drop in revenue.
Google: 400 ms delay caused a 0.59% decrease in search requests per
user.
Yahoo!: 400 ms delay caused a 5-9% ...
5
It would appear, according to the metric you're using, that DNS is not the real reason that your site is 'slow'. According to this utility, DNS takes 1 milisecond to resolve. 15.73 seconds are spent waiting on the server queue up and send the HTML. I'm thinking the bottleneck is at the web server, not the DNS.
5
Depending on the browser you use, that may be correct. As javascript may alter the page content, add new dom elements etc., the execution of anything after one script is blocked until that script gets executed. Nevertheless the download of other resources may happen in parallel.
The best advice is to put script tags in the bottom of your body and pack them ...
5
700kb of JavaScript IS a performance issue, because it must be parsed after page load. Because of it, you should take care, that only those scripts, that are needed, are loaded. One big JavaScript may be OK on full AJAX sites, such as GMail, when the navigation is handled internally without leaving the single page. However, even full AJAX sites do dynamic JS ...
5
First of all: you are basically doing a lot of things very good at the moment. This results in good grades in PageSpeed for example. Also keep in mind that the biggest part of the waiting time is spent on the frontend, so it makes sense to optimize this before going deep into server configuration.
These are some ideas:
there are a lot of image requests, ...
Only top voted, non community-wiki answers of a minimum length are eligible
