Is anybody else disgusted that 1.6 seconds is considered an acceptable page load time? When did this happen? Whatever happened to 200ms being the benchmark?
Dear Lord, people, please stop loading 14 zillion different domains every time I hit a web page.
If you can tell me how to make a decent looking site with a few MB of images load in 200 ms, I'm all ears. The only method I can think of, is by making the website ugly (i.e. few images and other design assets).
Did you see how much time was being used in multiple DNS requests?
To an end user, everything not on your domain is CRAP. It's not there for me, the end user. It's there for you, the website owner so you can aggregate my eyeballs, pitch me something, use somebody's comment service, extract advertising revenue, push network bandwidth onto Google, jQuery, etc.
2) Why on Earth do you need megabytes of images?
Really? WTF? Just because you took the picture with a gigapixel camera doesn't mean you need to serve every pixel.
3) Minimize the Javascript
No, you don't need that Javascript framework. Shoot it.
Especially on tablet/mobile browsers, a very small number of pages cache before the browser has to reload and regenerate (and that's REALLY slow).
The research is against you. Every extra 100ms is a significant drop in retention rate. Your website will stick out because everything is so snappy. Users can feel this--especially on tablets and mobile.
Agree with the above comments about reducing bloat, and I'm surprised by the number of smart people who think nothing of setting up a Wordpress site with dozens of CSS and JS files.
I just spent 20 minutes trying to find a link to an Apache function I found recently, which will join all your CSS or JS files together with something like an @include server-side automatically. Can't find it now but as I have been doing this manually I hope I find it again. Anyone know what this is? I seem to recall it was a native Apache function, not part of mod_pagespeed.
Nah, found that while searching for the other. I can probably use that, though. The one I'm thinking of had you putting a short instruction at the top of the file (like @include) if you wanted it to be part of the output file. Maybe I'm not remembering this correctly as I can find nothing on it now.
Server Side Includes? (mod_include for apache, mod_ssi for some others)? Not sure I'd recommend that as a general solution today -- for static sites I think you're better of building the static html, and serve that up. With varnish, you might want to look at edge-side includes.
It's quite a common optimization to distribute assets on multiple domains. This is because only a limited number of connections are allowed to made per domain (changes with HTTP2).
Furthermore, a CDN often has a faster connection to the user and you might benefit from it already being in the cache on first connection.
We use a cookieless domain for most of our static content (as the name implies, to avoid sending cookies on those requests, which helps the desktop case a little bit, but helps the mobile use case a lot). We originally did it because of the 2 connections per origin limit, but left it in place once that went away and was replaced with a huge uptick in mobile users.
We should test whether we should move the CSS back to the primary domain and pay the cookie uplift penalty to avoid the DNS and TCP penalty for that. (Another poster below rang that bell for me and it makes logical sense, but need to verify via testing.)
Yes, it's easy to make a page load quickly if you make "loading quickly" the most important design criteria. Then you just take out everything that would make it load slowly, like big beautiful pictures, or videos, or animated gifs.
The thing is, though, people really like to look at big beautiful pictures, and videos, and animated gifs. So if you want to give people what they want, then making a page load faster is not as easy as "just don't serve anything heavy."
Making HN load fast is easy. Making Flickr, or Buzzfeed, load fast is not. The minimum product weight is just always going to be heavier on sites that use more visuals.
Sorry, no reference other than me. :) Just personal experience on Chrome on iOS.
I have a bunch of websites that do "Cool Javascript Tricks" that I surf on iOS. The moment I switch a tab and switch back, the whole page loads again and takes almost 10-20 seconds.
I'm a fan of simple sites, but no, a small png with just a couple of colors will already take something on the order of 100kB. A couple of MB for images isn't something that people can work around - their site will be different if they avoid it.
About the Javascript, what happened to postponing its load to after the page is displayed?
> 2) Why on Earth do you need megabytes of images?
Because I don't want my website to look like Hacker News? It's great that Hacker News loads fast, but it's not exactly aesthetically pleasing.
And ever heard of retina displays? Having too low resolution images makes things blurry and ugly.
> Really? WTF? Just because you took the picture with a gigapixel camera doesn't mean you need to serve every pixel.
Okay, let's just limit it to 1200 pixels wide. That should look okay on a laptop, on a mobile device and on big monitor screens. If the image is 600 pixels high... that's a 2 MB uncompressed image right there. Compressed, maybe it's 500 KB. Show a few of them and voila, a few MB over the wire.
Making it less than 1200 pixels wide makes it look blurry on laptops and big monitor screens.
> 3) Minimize the Javascript
Dude, the Javascript I'm using is only 50 KB. That's a drop in the bucket compared to all the images.
You've been smug with your response, but you haven't given a single helpful tip. You're just assuming that anybody who doesn't succeed at the goal must be wrong and stupid.
Smug? No, I simply stated based upon what I see every day.
> Show a few of them and voila, a few MB over the wire.
Show a few 1200x600 images?!?!? What are you doing? Dude, someone with a normal screen (1920x1080) cant even view 4 of those. They can't even view more than one without clipping.
If you want to scroll to them, then loading a lower-resolution version and then swapping in the higher resolution version is the right solution.
In addition, almost every mobile browser I have seen would force a reload every single time I swap to your page. They simply will not cache that much image data persistently.
You magically are smart enough to put the assets on the same domain, minimize your javascript, and yet are shipping around a number of pixels that is bigger than the average screen size. o_O!?
And if I'm on a smartphone I don't want you transmitting megabytes of images, thanks.
I am reminded of all of these blog articles that start with one full screen picture that I have to scroll down to get to the first sentence. Generally, I just close the page when I see that because it indicates someone more interested in plastering my eyeballs than in giving me content.
Try the dutch tech site http://tweakers.net/ it's one of the best sites in terms of page speed vs complexity and shows what can be done if you just do it right.
If you do view-source, they also provide their stats:
For me:
<!-- Request ID: Pontus_25418_551cff14675926.65349173, Server time: 0,0369 s (C: 0,0302; Q: 5; 0,0018; E: 1; 0,0008 s, M: 12; 0,0046 s, A: 0; 0,0000 s), Mem: 5270 KB, User: CMG, Engines: (S) pontus (1) -->
Concentrate on the CSS and HTML, then have the images loaded in after. That way it will look like the site has loaded quick and the images are what takes most of the time, anyway.
(which loads some content/initial display pretty fast, btw) -- even a full-screen image intended for the Apple Retina iMac is "just" ~3MB. And if you're going to fill the entire viewport (and then some) -- you'll not be needing a lot of other images...
Aren't they also useful because if you and I use the same CDN for our libraries, we both use the same library/version, and a user visits my site and then visits your site, the libraries are already cached in the browser? If we both store those libraries locally, the library is loaded twice.
Yes, though there's some debate as to how often this actually matters. A surprisingly large number of the general web public comes in with a completely cold cache.
...which creates another problem with optimization: As soon as you make a change--no matter how small--to a single one of those concatenated assets you now have to deliver the entire new combined asset to the client. If you make changes to your JS/CSS assets on a regular basis (rapid iteration anyone?) this means your clients might be best served via individual assets (depending on your traffic patterns).
I have solved this problem myself by avoiding concatenation and using the browser's IndexedDB to store assets that can be loaded dynamically (JS, CSS, and client-side templates). Assets like this get downloaded over a WebSocket connection which provides the same advantage of SPDY in that no re-negotiation is necessary.
Google used to say "We're aiming for 100ms!" a lot quite some time ago. Now the their advocates are saying more like aim for 1000ms(1s) which is very realistic and good. 200ms will easily be eaten by SSL's 3 chunks of RTT(with the smaller initial cwnd cases).
To add to that, 100ms-200ms is only the cutoff time to determine the bid winner from adexchange perspective. We still need to add the time for adexchange to notify bid winner + adserving load time for total ad response latency.
Not sure why you'd want to load ads synchronously. Surely you can just load the page with placeholder divs, and swap them out when the ads are ready? The extra jarring blink when ads arrive, should increase visibility anyway. And for the rest of us, that browse with ad-blockers the only change would be a quicker load time...
1.6 seconds to seeing the main content of the page is too slow. But if you're just loading up "other articles" at the bottom, or "latest tweets" on the side, then it doesn't really matter if it's slow.
It isn't a matter of can't, it's a matter of don't want to.
Death by a thousand small cuts, a single 2 second wait isn't objectionable, the entire app being that slow means literally every time I do something I wait 2 seconds. It cuts into your mental flow.
On the other hand, it's pretty amazing that a ~2MB application can be downloaded over the network and executed to a state of responsiveness within 2 seconds. Some of us remember when the MS Word binary was roughly that size and took ~20-30 seconds to start up (with a splash screen, etc).
It's trivial to get a single static HTML hello world page with no assets to load in 100ms.
I'd really rather not be downloading 2MB applications from random internet sites, like, ever. I've started browsing with noscript turned on by default, and despite what everyone says about how useless the modern web is without it, things are pretty great - everything loads instantly and the stuff that doesn't load generally isn't much I care about.
My experience: https://medium.com/p/196b5024899c
Major browsers will not support h2c switching(switching from http, rather than TLS), and faster(but less secure) ciphers or null ciphers will not work for those browsers either, so speed in the HTTP/2 world will likely be something on top of SSL's latency.
We optimise and host websites for our clients, use an https/spdy CDN exclusively, most sites we work on are dogs when it comes to performance, and aim for half second page load times on average. Anything over 1 second is unacceptable. I read this article before, I think it was posted to HN previously, and wasn't impressed at the time. Still not impressed now....
Long story short: Not using a CDN is stupid. Learn to CDN.
In this case, that's an appropriate attitude. If your environment is a mess and you add complexity with a CDN, you've got a complicated mess. But a local optimization like this benefits your entire organization and puts off the need for a CDN (a solution to a problem that no longer exists). They may grow to a point where a real strain is being put on their systems, they can't make local improvements, and involving a CDN is the right choice.
In the Australia comparison, the CDN version spends almost 1.5 second on DNS lookup for the main domain. In the non-CDN version this figure is much lower. It seems disingenuous to attribute this overhead to the CDN, no?
And as an aside - Maybe there are some low hanging fruits in tuning their DNS setup instead? 1.5s seems extremely high to me.
60 comments
[ 3.0 ms ] story [ 41.9 ms ] threadhttps://wiki.mozilla.org/Security/Server_Side_TLS
Dear Lord, people, please stop loading 14 zillion different domains every time I hit a web page.
Did you see how much time was being used in multiple DNS requests?
To an end user, everything not on your domain is CRAP. It's not there for me, the end user. It's there for you, the website owner so you can aggregate my eyeballs, pitch me something, use somebody's comment service, extract advertising revenue, push network bandwidth onto Google, jQuery, etc.
2) Why on Earth do you need megabytes of images?
Really? WTF? Just because you took the picture with a gigapixel camera doesn't mean you need to serve every pixel.
3) Minimize the Javascript
No, you don't need that Javascript framework. Shoot it.
Especially on tablet/mobile browsers, a very small number of pages cache before the browser has to reload and regenerate (and that's REALLY slow).
The research is against you. Every extra 100ms is a significant drop in retention rate. Your website will stick out because everything is so snappy. Users can feel this--especially on tablets and mobile.
I just spent 20 minutes trying to find a link to an Apache function I found recently, which will join all your CSS or JS files together with something like an @include server-side automatically. Can't find it now but as I have been doing this manually I hope I find it again. Anyone know what this is? I seem to recall it was a native Apache function, not part of mod_pagespeed.
[0] https://code.google.com/p/modconcat/
[1] https://github.com/alibaba/nginx-http-concat
It's quite a common optimization to distribute assets on multiple domains. This is because only a limited number of connections are allowed to made per domain (changes with HTTP2).
Furthermore, a CDN often has a faster connection to the user and you might benefit from it already being in the cache on first connection.
We should test whether we should move the CSS back to the primary domain and pay the cookie uplift penalty to avoid the DNS and TCP penalty for that. (Another poster below rang that bell for me and it makes logical sense, but need to verify via testing.)
Yes, it's easy to make a page load quickly if you make "loading quickly" the most important design criteria. Then you just take out everything that would make it load slowly, like big beautiful pictures, or videos, or animated gifs.
The thing is, though, people really like to look at big beautiful pictures, and videos, and animated gifs. So if you want to give people what they want, then making a page load faster is not as easy as "just don't serve anything heavy."
Making HN load fast is easy. Making Flickr, or Buzzfeed, load fast is not. The minimum product weight is just always going to be heavier on sites that use more visuals.
I have a bunch of websites that do "Cool Javascript Tricks" that I surf on iOS. The moment I switch a tab and switch back, the whole page loads again and takes almost 10-20 seconds.
About the Javascript, what happened to postponing its load to after the page is displayed?
I already do that.
> 2) Why on Earth do you need megabytes of images?
Because I don't want my website to look like Hacker News? It's great that Hacker News loads fast, but it's not exactly aesthetically pleasing.
And ever heard of retina displays? Having too low resolution images makes things blurry and ugly.
> Really? WTF? Just because you took the picture with a gigapixel camera doesn't mean you need to serve every pixel.
Okay, let's just limit it to 1200 pixels wide. That should look okay on a laptop, on a mobile device and on big monitor screens. If the image is 600 pixels high... that's a 2 MB uncompressed image right there. Compressed, maybe it's 500 KB. Show a few of them and voila, a few MB over the wire.
Making it less than 1200 pixels wide makes it look blurry on laptops and big monitor screens.
> 3) Minimize the Javascript
Dude, the Javascript I'm using is only 50 KB. That's a drop in the bucket compared to all the images.
You've been smug with your response, but you haven't given a single helpful tip. You're just assuming that anybody who doesn't succeed at the goal must be wrong and stupid.
> Show a few of them and voila, a few MB over the wire.
Show a few 1200x600 images?!?!? What are you doing? Dude, someone with a normal screen (1920x1080) cant even view 4 of those. They can't even view more than one without clipping.
If you want to scroll to them, then loading a lower-resolution version and then swapping in the higher resolution version is the right solution.
In addition, almost every mobile browser I have seen would force a reload every single time I swap to your page. They simply will not cache that much image data persistently.
You magically are smart enough to put the assets on the same domain, minimize your javascript, and yet are shipping around a number of pixels that is bigger than the average screen size. o_O!?
I'm beginning to think you're just trolling me.
QHD -- which will show four of those simultaneously -- isn't that uncommon on tablets (and even some smartphones, like the Note 4.)
I am reminded of all of these blog articles that start with one full screen picture that I have to scroll down to get to the first sentence. Generally, I just close the page when I see that because it indicates someone more interested in plastering my eyeballs than in giving me content.
If you do view-source, they also provide their stats: For me: <!-- Request ID: Pontus_25418_551cff14675926.65349173, Server time: 0,0369 s (C: 0,0302; Q: 5; 0,0018; E: 1; 0,0008 s, M: 12; 0,0046 s, A: 0; 0,0000 s), Mem: 5270 KB, User: CMG, Engines: (S) pontus (1) -->
http://www.sorryana.rocks/mavericks-wallpaper/
(which loads some content/initial display pretty fast, btw) -- even a full-screen image intended for the Apple Retina iMac is "just" ~3MB. And if you're going to fill the entire viewport (and then some) -- you'll not be needing a lot of other images...
CDNs are useful because they load content closest to where the user is located.
That's my understanding of it anyway.
(I.e. "This links points to this file - if you already have the file with this hash use it instead")
I have solved this problem myself by avoiding concatenation and using the browser's IndexedDB to store assets that can be loaded dynamically (JS, CSS, and client-side templates). Assets like this get downloaded over a WebSocket connection which provides the same advantage of SPDY in that no re-negotiation is necessary.
You can see the implementation of this here:
https://github.com/liftoff/GateOne/blob/master/gateone/core/...
...and the client side code is here:
https://github.com/liftoff/GateOne/blob/master/gateone/stati...
(Including the functions immediately following that one)
1.6 seconds is entirely too. fucking. slow.
Mobile browsers cache a LOT less after rendering than desktop browsers.
Death by a thousand small cuts, a single 2 second wait isn't objectionable, the entire app being that slow means literally every time I do something I wait 2 seconds. It cuts into your mental flow.
It's trivial to get a single static HTML hello world page with no assets to load in 100ms.
That means you have to wait for DNS resolution and the TCP connection roundtrips (or worse, unoptimised TLS roundtrips) just to get the CSS.
If they were on the same host name, and the CSS is the first thing in the HTML, it'll be downloaded immediately after the HTML.
(And with SPDY, the browser could start downloading the CSS on the same connection as soon as it parses the link element.)
I think all we can gather from this example is that MaxCDNs TLS implementation wasn't optimal and they were working on it
Would be interesting to see how this behaves for other CDNs or with link rel= optimisations in place
Long story short: Not using a CDN is stupid. Learn to CDN.
And as an aside - Maybe there are some low hanging fruits in tuning their DNS setup instead? 1.5s seems extremely high to me.
http://www.webpagetest.org/result/150402_22_0fa16aec7ebc410a... also shows 8 seconds from tokyo
http://www.webpagetest.org/result/150402_AN_22f88770d4bab89c... shows 8 seconds from India
http://www.webpagetest.org/result/150402_CT_49277f5267e82b6b... shows 36 seconds from Amsetrdam
http://www.webpagetest.org/result/150402_9G_0810eaa940dc2941... shows 12 seconds from Buenos Aires
Not so sure that you dont need a CDN based on this