HTTP/2, the long awaited update to the Web’s venerable transfer protocol is now complete, and indeed supported in some browsers and by some servers. But we Front End Engineers don’t need to worry about all that low level stuff right? After all it just makes everything faster between the client and server.
Well, it’s not quite that simple. In fact there are plenty of things you’re likely doing right now, best practices for performance over the network like using sprites, domain sharding, concatentating files and the like that not only won’t you have to do with HTTP/2, but which might actually make things worse.
In this presentation we’ll learn from the chair of the IETF working group that developed HTTP/2, Mark Nottingham about what HTTP/2 brings, and what you should and shouldn’t be doing to get the most performance benefit from it.
https://www.mnot.net/talks/h2fe/
“in one slide…”
- A fully multiplexed binary protocol
- one connection per origin (better network utilisation)
- browsers don’t have to guess when/where to send requests
- …with header compression
- many requests in one packet
- …and server push
- put a response in the browser cache before it knows it needs it
Just by turning it on you can expect ~5-15% performance improvement in most cases. You can do much better by tweaking and tuning.
HTTP/2 is the same for APIs, headers, methods, etc.
You might need new URLs – it requires an encrypted connection, which means in effect https.
Recommendation: move to https now.
HTTP/1 optimisations that no longer work:
- spriting, inline, concatenation
- these things reduce the granularity of your code
- that means this hurts you with http2
You can either serve differently to http2 capable browsers; or you can aggressively push on with http2, but the recommendation here is to get a strategy in place.
Think about prioritisation… in http1, browsers are responsible for deciding request priority and ordering. Http2 gets the server to do it. Look for APIs, data and studies. We don’t have a lot of knowledge in this area yet as we haven’t had access to do it. You can get this really wrong! It’s a lot like chunking… get it wrong and you do a lot of harm.
Server push – in theory can save you a round trip by putting something into cache before the browser needs it. This is so new we don’t have any data on how best to use this. Try it, measure, but be careful.
Header compression – it is coarse grained, it works on an entire header. Any header variation blows this up and you don’t get any compression. Avoid header variability.
Quick points…
- TLS – this needs tuning.
- Client certificates don’t work with http2
More reasons you might need new URLs…
Spreading traffic to multiple hosts hurts perf in both http1 and http2. Sharding etc can cause flooding and congestion. You can use connection coalescing if DNS and certificate agree. Recommendation: there can be only one (hostname).
DoS Protection – the bad news is http2 needs more state. The good news is it lets you bound connection.
Connections are long-lived in http2, so you need to architect to accommodate this. It can mess up DNS load balancing (use GOAWAY and soon ALTSVC to manage this).
More servers or less? It’s not totally nailed down yet. Twitter was able to reduce their servers; but it’s so situational proceed with caution.
Key point: we are just getting started. Give this a year and people are going to have heaps more data, open source tools, frameworks etc.
(lots of deep detail in these slides, if you need the details definitely look this up)
