HTTP/2 is Not A Magic Bullet

Don’t expect to see a presentation at the next Velocity, AWS re:Invent, or Interop Conference that states:

HTTP/2 is here. CDNs are no longer necessary. Fire all your performance engineers. Performance is great. Nothing left to improve. We’re done.

What you should expect is a presentation that sounds more like this:

Multiplexing requests via TLS on a single TCP stream to a server that’s 160ms away with 4% packet loss is not the arrival of our long-awaited utopian future. Quite the contrary. We’re not done. We haven’t even started. We have a long way to go.

Here’s why.

Website and application performance are constantly evolving. Everything that we’re doing today with HTTP/1 isn’t what we thought we’d be doing back in 1990 or 1999. Granted, we have a lot more people thinking about these issues today, so we’re seeing performance accelerate.

Today’s contributors have a much deeper understanding of how the HTTP protocol is actually used and bring a significantly wider variety of experience and backgrounds to the effort.

In the end, though, the only reality is that performance will always move forward.

HTTP/2

Regardless of what you read, we are only at the beginning of understanding how to maximize performance with HTTP/2. The performance improvements and strategies around HTTP/2 will continue to change and evolve. While a switch in the protocol is certainly a step in the right direction, it’s just the first step.

Whenever I speak with people, whether they’re a customer, partner or new acquaintance, the perception I get is that HTTP/2 is a magic bullet – that it will right all previous wrongs and solve all existing issues with HTTP and put the web and applications on a perfect path.

The reality is much different.

HTTP/2 is not a magic bullet. It’s a powerful tool that we can use to improve web and application performance — but it needs a skilled engineer to wield it.

Granted, it *is* a much better tool for today’s internet than HTTP/1. Remember, HTTP/1 was designed in 1990 for a very different web environment than we have now.

But ask yourself, are techniques such as CSS sprites, inlining assets, and domain sharding helpful or hurtful on a given HTTP/2 site? How are you measuring? Is the answer the same for all sites and asset types?

There’s no denying that for the majority of sites, HTTP/2 is faster in terms of performance and load time. There are also a minority of sites where HTTP/2 will decrease performance by up to 30%.

Yes, that’s right.

There are known instances where HTTP/2 will make your application or site slower.

We can’t forget, however, that the realities of today’s internet are driven by much more demanding content and a set of protocols that we won’t solve anytime soon:

• We still have TCP at layer 3.
• We still have the speed-of-light constraints.
• TLS requires more packets to deliver the same payload.

We still have all of the original constraints behind the development of CDNs. HTTP/2 is just better at dealing with some of these constraints.

This is why it’s important to remember:

• There are actually a few things that HTTP/2 makes worse.
• There are actually some new problems HTTP/2 introduces.
• HTTP/2 should make you ask more questions.

The takeaway is this: deploying HTTP/2 isn’t the endgame. Rather, it’s a new and exciting beginning.