Almost half of the top 1000 retail websites don’t follow two easy performance best practices. Does yours?

I’m hip-deep in data from a big research project (the topic is still under wraps) that we’re working on here at Strangeloop. We’ve been studying the top 1000 online retailers, and we noticed a trend so significant that it merits some attention of its own.

Check out these charts showing how the top 1000 retail sites rated with two page speed scores: Keep-alive Enabled and Compress Text.*

Alexa Retail 1000: Page speed score for keep-alivesAlexa Retail 1000: Page speed scores for text compression

Summary

  • 85% of these sites use keep-alives.
  • 53% do compression.
  • But when I overlaid these two sets of numbers, I was surprised to find that 47% don’t do one or the other.

These are two of the easiest, lowest-hanging fruit on the performance optimization tree, and almost half of the leading retail websites aren’t taking advantage of them simultaneously.

Keep-Alives

TCP connection is the process by which both the user and the server send and receive acknowledgment that a connection has been made and data can begin to be transferred. Too many TCP connections will slow down your site. It’s not easy to speed up TCP connection, but you can control how many times the connection takes place.

If you’re an exec/marketing manager: First, test your site and get its keep-alive score. If it’s anything less than an A, then take a look at your site’s waterfall chart. (Here’s a quick primer on how to interpret this chart.) If you’re seeing a lot of orange bars, you have a problem that could be fixed by using keep-alives.

If you’re in dev/ops: Make sure you have the proper configuration on your servers and load balancer. Also, we saw a number of CDNs that don’t do keep-alives properly, so keep your eyes open for lots of orange bars on content coming from your CDN.

Compress Text

The average size of the web pages we studied is 836kb, which is a major slowness factor. Compressing resources can reduce the number of bytes sent over the network. Text compression isn’t the only way to reduce your payload, but it is the easiest.

If you’re an exec/marketing manager: As above, test your site and get its compress text score, then check out its waterfall chart. If you’re seeing a lot of bright blue bars, you have a problem that could be fixed through compression.

If you’re in dev/ops: Make sure you’re following Google’s best practices for compression, as outlined here.

Don’t underrate these two simple measures.

They can have a huge impact on page speed. In a session where I first de-optimized, then re-optimized, the Velocity website, the first fixes I implemented were keep-alives and text compression. With just these two fixes, the site experienced major improvements in these areas:

  • Start render: 52% faster
  • Document complete: 40% faster
  • Fully loaded: 31% faster

These two steps alone are not enough, but they’re definitely must-haves before you reach for the fruit on the higher branches.

*All tests conducted on Webpagetest — IE7 on DSL via the server in Dulles, VA.

Related posts

13 thoughts on “Almost half of the top 1000 retail websites don’t follow two easy performance best practices. Does yours?

  1. I wish I could say I was surprised by this. Convincing well resourced sites that should know better to make these types of simple changes has proven to be harder than I would have thought.

  2. I whole-heartedly agree that these are two things that are easy wins for improving website performance. The thing that struck me though is your statistics. I couldn’t figure out the math you used to derive that 47% of the sites used neither keep-alives or compression techniques. Could you write up a quick blurb for those of us that are math-challenged?

  3. Much like Joseph, I wish I could say I was surprised. What you are seeing is exactly why WebPagetest displays just the 6 most critical checks on the main results page. Until you’ve implemented those (and it’s scary how many sites haven’t) it’s usually not worth looking at any of the other checks that YSlow, Page Speed or WebPagetest check (and as you pointed out, most are trivially easy to implement).

  4. @Robert – The math used for deriving the 47% number is that 1000 sites were surveyed and 470 (± 5) did not use both keep-alive and compression.

  5. Are these measurements differentiating HTTP1.0 and HTTP1.1 connections? Since all connections are kept alive in HTTP 1.1 until Connection: close is sent it could have major impact on these numbers.

  6. one question:“The average size of the web pages we studied is 836kb”, this size in only HTML or include image and CSS? Thanks!

  7. @Robert: Just to clarify Ray’s comment, the math used for deriving the 47% number is that 1000 sites were surveyed and 470 (± 5) did not use one or the other (or both) of either keep-alive or compression.

    @Erik: These measurements do not differentiate between HTTP 1.0 and 1.1 connections. Given that you can and should do keep-alives in HTTP 1.0, I’m assuming everyone who does not should.

    @Tyler: The average size includes the size of the page and all of the objects.

  8. I wrote some blog posts about Front-End performance optimizing and techniques like cookieless domain, compressing content, combining/minifying css/jss…

    These techniques should be used by everyone (in my opinion) but noone seems to care.

  9. Pingback: How much performance value do ADCs/load balancers actually provide in the real world? — Web Performance Today

  10. Pingback: End-of-year performance report: Top retail sites are slower, not faster, than the rest of the pack — Web Performance Today

  11. Pingback: Customer experience: Bridging the gap between bricks and clicks at the NRF — Web Performance Today

  12. Pingback: Good question: We own a load balancer/ADC. Why not just use it to accelerate our site?

  13. Pingback: New findings: Ecommerce sites are 9% slower than in 2011

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>