Akamai Diversity

The Akamai Blog

Where is my HTTP/2 Performance?

This blog post is part of an ongoing series where we will discuss a wide range of H2-related topics. In today's post, we talk about some of the misconceptions regarding HTTP/2 being a silver bullet for improved website performance. 

As a major advocate for HTTP/2 (h2) for years, I find it ironic that I now spend much of my time explaining to people why it may not help them.  Generally, this occurs when someone turns on h2 for a few objects on their page and then points out that they did not see an improvement.  When I say a few objects, what I mean is they put some of the page elements (images for example) on h2, and that is it. The following conversation generally follows: 

"Wait, I read that h2 was supposed to make my site much faster."

"It did, look at how well the h2 content performed..."

"But my site isn't faster."

"Most of the content on your page isn't taking advantage of h2."

"Most of my page is 3rd party content"

"Sucks, doesn't it?" 

There are many factors that can affect whether your site will see a performance bump from h2 (or anything that comes after).  For now, I'll give you a list of questions to consider.  Each of these deserves a post of its own, but to start the discussion, here is the high level top of mind list:

  • Is your base page on h2 as well as the objects?  Best performance will come when the HTML is served on h2 and the objects are on the same domain.
  • Are you sharded?  Unshard.
  • What percentage of the page content is on h2?
  • As referenced above, if a 3rd party provider blocks the page load, the 3rd party content can kill your performance. Even in an h2 world.
  • Are your users experiencing a high amount of packet loss? Loss is the enemy of h2, a well understood limitation when it was being developed. (See QUIC for a proposal for dealing with that.)
  • Are you doing large downloads? The benefits of h2 are more evident with webpages verses large file downloads.
  • Are you testing from a "super" connection? Lots of bandwidth?  Super low latency?  You should not expect to see much benefit there - life is already great for you.  Stop being greedy.
  • Are you already on TLS or are you serving in the clear?  If all is good, h2 should make the transition to TLS with as good as or better performance, but in the face of any of the above problems. The potential boost might be too small to make the difference.
  • How are you measuring your performance? With h2, Time to First Byte (or TTFB) does not mean what you think it means... Be sure you are measuring what matters most for your site's performance in an h2 world.
    • Stay tuned for a future post on blogs.akamai.com, which will discuss best practices for measuring h2 performance
  • Is your site very js heavy? Well connected mobile devices are going to be process bound rendering the site, not network bound. H2 won't help a handheld device wrestle with processing megabytes of javascript.

These are just a few questions / observations worth considering as you migrate to h2.  h2 is a different beast than h1, and though everything will be functional when you move from one to the other, and there is a lot of goodness out of the box, the new beast means opportunities for new learning and optimizations.

Finally, this was not intended to be a "Should I upgrade to HTTP/2?" piece, but let's get that out of the way... Should you upgrade?  Yes.  Why?  A simple reason is that the focus of innovation and optimization will be more and more on h2 and less on h1.  (Remember all of those hot gopher sites of the 90s?)   

To learn more, go to: https://http2.akamai.com/

Additional reading on HTTP/2: