Why are pages slow?(themvcblog.typepad.com)
themvcblog.typepad.com
Why are pages slow?
http://themvcblog.typepad.com/programming/2012/12/why-are-pages-slow.html
12 comments
I'm interested to see what's said for "poor cache-ability". It's an area where the assumption of "more caching is better" can be wrong. I've seen real-world A/B test results that indicate client-side caching can often be slower than re-fetching a resource from the network. Typically, this is true for small resources being loaded from the disk cache (i.e. your home page on a new browser session). It's counter intuitive, but many network connections to hot CDNs are faster than fetching from a local physical (spinning) disk.
Until some guy from New Zealand that doesn't have an edge in his country comes along. Don't actually apply this optimisation just because it's faster for you. It's probably slower for a lot of the rest of the world.
The "real world A/B test" I mentioned was part of ongoing performance test for a global top 20 site. I'm talking about millions of hits across all browser variants, OSes, markets, networks, etc. I can't cite the data directly because it's not public. You're right though that there will be plenty of cases where optimizations like this will be not work for some users. The most important thing, obviously, is to gather data from your own users and make the right choices based on them. Things change fast: new browser features; new user groups; new networks routes or proxies in your way. Results that were conclusive previously need to be retested regularly, including the following.
The particular scenario where we saw network-loading of resources consistently being faster was on first load of a frequently viewed page. In this scenario we found that loading certain scripts and images from cache (which we inferred to be physical disk because it was 'home page' activity) was slower for a significant portion of the experiment group than loading from the network. In this context loading from 'network' meant either a hot HTTP request to a CDN or inlining small images and scripts directly in the HTML on every single request.
As I mention above, it's worth regularly re-evaluating assumptions. I'd bet that the big CDN players have a huge presence in New Zealand and Australia, given the latency, cost of ingress and density of the actual population centres.
The particular scenario where we saw network-loading of resources consistently being faster was on first load of a frequently viewed page. In this scenario we found that loading certain scripts and images from cache (which we inferred to be physical disk because it was 'home page' activity) was slower for a significant portion of the experiment group than loading from the network. In this context loading from 'network' meant either a hot HTTP request to a CDN or inlining small images and scripts directly in the HTML on every single request.
As I mention above, it's worth regularly re-evaluating assumptions. I'd bet that the big CDN players have a huge presence in New Zealand and Australia, given the latency, cost of ingress and density of the actual population centres.
>Until some guy from New Zealand that doesn't have an edge in his country comes along. Don't actually apply this optimisation just because it's faster for you. It's probably slower for a lot of the rest of the world.
And who cares about the "guy from New Zealand"? You optimise to the markets/areas you target.
And who cares about the "guy from New Zealand"? You optimise to the markets/areas you target.
I think that's probably less bad these days, a lot of the problem with slow cached resources was due to IE6 and it's default cache size being a percentage of disk space with no cap, resulting in an excessively large cache (and not well indexed either), but later versions of IE do percentage with a cap so it doesn't get absurdly large.
This StackOverflow answer, "Numbers everyone should know", seems relevant here: http://serverfault.com/a/238534
Could you provide the data and test methods to backup that claim?
I've spent a fair amount of time (over) optimizing https://starthq.com and would say that network latency needs to be at the top of the list of things to look at.
The solution has been to serve static HTML, i.e. the index page of the single page app part, with a one hour cache expiration and links to other static resources (JavaScript, CSS, images etc.) decorated with their E-Tag and loaded from a CDN. For non static pages the set up is the same, but the caching time is lower. The static resources have far off (one year or so) expiration headers so are cached permanently.
By using a CDN for all your assets you can reduce a 200ms roundtrip to 8ms for all users worldwide, bringing the page loading time to way below 200ms with an empty cache and well below 100ms with a primed cache since you still need to do an XHR to check the login status.
Small time saving tip: if you go with CloudFront, go all out and use all edge locations - it's cheap. I tried using Europe only at first only to eventually find out that I was still being given an edge location in the US despite being in Finland.
The solution has been to serve static HTML, i.e. the index page of the single page app part, with a one hour cache expiration and links to other static resources (JavaScript, CSS, images etc.) decorated with their E-Tag and loaded from a CDN. For non static pages the set up is the same, but the caching time is lower. The static resources have far off (one year or so) expiration headers so are cached permanently.
By using a CDN for all your assets you can reduce a 200ms roundtrip to 8ms for all users worldwide, bringing the page loading time to way below 200ms with an empty cache and well below 100ms with a primed cache since you still need to do an XHR to check the login status.
Small time saving tip: if you go with CloudFront, go all out and use all edge locations - it's cheap. I tried using Europe only at first only to eventually find out that I was still being given an edge location in the US despite being in Finland.
Most single page javascript apps that don't prerender are the biggest sinners in a multitude of ways.
1) with the amd loading system you spawn multitude http requests, where
2) none of the code went through a tree shaking to remove dead code (ala the closure compiler in advanced mode - or something which cross compiles) you download a whole steaming heap you don't need thus extra bytes
3) no pre-rendering, so now you are blocking the users experience till your whole steaming pile has managed to trickle down onto a mobile device, the joy
Install the YSlow plug-in and see the bottlenecks right the way.
Says the page that take 3.43s to (down)load in my browser, loading 8 CSS files and a lot of JS files.
On a serious note: I think Opera Dragonfly is also a great tool for this providing even more information.
On a serious note: I think Opera Dragonfly is also a great tool for this providing even more information.