Web Performance Today

I have some data:

http://w3techs.com/blog/entry/jquery_now_runs_on_every_second_website

Of the top 10k sites 58.8% use jQuery. That's good!

But only 26.6% use a cdn. Leaving only 15.6%. That's bad...

But 94.2% use Google's. Which is still 14.7%! That's good!

http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/

But only 1% use the newest version of jQuery. Leaving only 0.15%. That's bad...

http://www.quora.com/User-Behavior/How-many-websites-does-an-average-user-visit-per-day

But users visit on average 89 sites per month. Which gives us 12.5%. That's good!

http://stevesouders.com/cache.php

But default browser cache sizes are small. That's bad...

http://www.webperformancetoday.com/2013/06/05/web-page-growth-2010-2013/

But the average website is about 1MB so with a 50MB cache about 50 sites can be cached. Which leaves about 7.2%. That's... OK?

OK. So I don't actually know if a cdn cache hit is all that likely, but the situation is a bit worse, and a bit better than most people think.

Of course, using a cdn is still better than hosting yourself. If you bundle your jQuery then every time your site updates it needs to be redownloaded. If you serve it seperately on your domain, you won't have the distribution benefit of a cdn.

Should you use Google's cdn instead of a different commercial cdn provider that's faster? In that case I'm not sure.

That's also a minor side issue: it'll cost you a sub-1-second page load time but it doesn't cause the kinds of problems people are talking about where the backend components are overloaded to the point of failure.

The size of healthcare.gov is actually well under the average:

http://www.webpagetest.org/result/131010_ZG_X5C/1/details/

(see http://www.webperformancetoday.com/2013/06/05/web-page-growth-2010-2013/)

For comparison, look at WashingtonPost.com: it uses considerably more data and more total requests and yet the page loads much faster:

http://www.webpagetest.org/result/131010_GG_XDK/

If you look carefully, though, you'll see a) that they aren't setting Cache-Control headers and are setting ETags (both performance killers) and b) there's this weird staggered response behaviour which indicates something is seriously wrong. It seems to handle much better in Chrome - 3s vs 70! - so presumably there's some interaction with the browser going on as well:

http://www.webpagetest.org/result/131010_ZW_XD6/1/details/

Mobile bandwidth is somewhat of a red herring. While ubiquitous 4G isn't reality, most smartphones and networks are already capable of fairly high bandwidth.

Latency is the bottleneck you should tackle first when addressing mobile performance, not asset size - the world has already spent a lot of time optimizing asset size for web delivery. But phones are bad at handling lots of requests. Serving a single high-resolution graphic will have significantly less impact on page rendering speed (and even more important, perceived rendering speed) than a handful of smaller assets which add up to the same size.

For a real world example, a mobile phone can download and render a single large photo faster than the gaggle of javascript, css, and social network share icons typically presented next to it.

Many have examined and written about this. Here's a blog article that Google ranks on the subject: http://www.webperformancetoday.com/2012/04/02/mobile-versus-desktop-latency/