Web Directions

Conffab

  • Speakers
  • Presentations
  • Conferences
  • Topics
  • Pricing & Plans
  • Browse
  • Signup
  • Sign In
  • Speakers
  • Presentations
  • Conferences
  • Topics
  • Pricing & Plans
  • Browse
  • Signup
  • Sign In
Advanced Search
Searching videos

What Does HTTP/2 Mean for Front End Engineers?

Mark Nottingham at Code 2015
  • performance
Sign up for a free membership to watch this and hundreds of other videos
  • Details
  • References
  • Keypoints

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…”

  1. A fully multiplexed binary protocol
    • one connection per origin (better network utilisation)
    • browsers don’t have to guess when/where to send requests
  2. …with header compression
    • many requests in one packet
  3. …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)

 

You may also be interested in

    Thumbnail for HTTP2: The reckoning

    HTTP2: The reckoning

    Thumbnail for JavaScript performance patterns

    JavaScript performance patterns

    Thumbnail for Taking Back Control Over Third Party Content

    Taking Back Control Over Third Party Content

    Thumbnail for Is your Progressive Web App Lazy? How to read and improve your PWA Performance

    Is your Progressive Web App Lazy? How to read and improve your PWA Performance

    Thumbnail for Lazy Load Everything!

    Lazy Load Everything!

    Thumbnail for Delivering a Web Experience in 10KB

    Delivering a Web Experience in 10KB

    Thumbnail for What’s New at the W3C Web Performance Working Group?

    What’s New at the W3C Web Performance Working Group?

    Thumbnail for The Loaded JavaScript

    The Loaded JavaScript

More presentations from Code 2015

    Thumbnail for Console Dot

    Console Dot

    Thumbnail for Back to the Future with Web Components

    Back to the Future with Web Components

    Thumbnail for Current Best Practice in Front End Ops

    Current Best Practice in Front End Ops

    Thumbnail for Crossing The Streams

    Crossing The Streams

    Thumbnail for What Comes Next for the Web Platform?

    What Comes Next for the Web Platform?

    Thumbnail for Dawn of the Progressive Single Page App

    Dawn of the Progressive Single Page App

    Thumbnail for ES6 Symbols, What They Are and How to Use Them

    ES6 Symbols, What They Are and How to Use Them

    Thumbnail for Async and Await

    Async and Await

Conffab
  • About
  • Speakers
  • Presentations
  • Conferences
  • Contact
  • Sign in
Sign Up

© Conffab 2023