Web Directions

Conffab

  • Speakers
  • Presentations
  • Conferences
  • Organizers
  • Topics
  • Pricing & Plans
  • Browse
  • Signup
  • Sign In
  • Speakers
  • Presentations
  • Conferences
  • Organizers
  • 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 Conffab Free to watch this and hundreds of other videos for free
  • 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 Once More with Feeling

Once More with Feeling

Tim Kadlec

Thumbnail for Progressing Your Web Apps With Service Worker

Progressing Your Web Apps With Service Worker

Marcos Caceres

Thumbnail for Memory Management in V8

Memory Management in V8

Hadi Michael

Thumbnail for Taking Back Control Over Third Party Content

Taking Back Control Over Third Party Content

Yoav Weiss

Thumbnail for Designing Web Apps for Performance

Designing Web Apps for Performance

Josh Duck

Thumbnail for Design Decisions Through the Lens of Performance

Design Decisions Through the Lens of Performance

Yesenia Perez-Cruz

Thumbnail for The Operable Front End

The Operable Front End

Emily Nakashima

Thumbnail for Offline First: Faster, More Robust and More Fun (Web) Apps

Offline First: Faster, More Robust and More Fun (Web) Apps

Alex Feyerke

More presentations from Code 2015

    Thumbnail for The State of the Animation

    The State of the Animation

    Rachel Nabors

    Thumbnail for What Comes Next for the Web Platform?

    What Comes Next for the Web Platform?

    Alex Russell

    Thumbnail for Async and Await

    Async and Await

    James Hunter

    Thumbnail for Async Frontiers in JavaScript

    Async Frontiers in JavaScript

    Domenic Denicola

    Thumbnail for Classing up ES6

    Classing up ES6

    Andy Sharman

    Thumbnail for Canvas Cold War

    Canvas Cold War

    Simon Swain

    Thumbnail for Current Best Practice in Front End Ops

    Current Best Practice in Front End Ops

    Alex Sexton

    Thumbnail for Stop the Fanaticism – Using the Right Tools for the Job

    Stop the Fanaticism – Using the Right Tools for the Job

    Kassandra Perch

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

© Conffab 2025