Why are pages slow?
themvcblog.typepad.com
Why are pages slow?
1–10 of 13 posts
Re: Why are pages slow?
#2Install the YSlow plug-in and see the bottlenecks right the way.
Re: Why are pages slow?
#3I'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.
Re: Why are pages slow?
#4Excellent article. I see very few people talking about HTTP requests. It's a major issue.
the article also talks about latency, but with many people don't realize is that webpages are being served from all over the world. servers are located in many countries. The servers all have additional latencies from undersea links.
Re: Why are pages slow?
#5I'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 intuitiv…
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.
Re: Why are pages slow?
#6I'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 intuitiv…
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.
Re: Why are pages slow?
#7I'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 intuitiv…
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.
Re: Why are pages slow?
#8I'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 intuitiv…
Could you provide the data and test methods to backup that claim?
Re: Why are pages slow?
#9Says 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.
Re: Why are pages slow?
#10I'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.