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.
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.
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.