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 Delivering a Web Experience in 10KB

    Delivering a Web Experience in 10KB

    Thumbnail for Powered by sharp

    Powered by sharp

    Thumbnail for Get speedy with responsive images automation

    Get speedy with responsive images automation

    Thumbnail for Tuning web performance with just browser APIs

    Tuning web performance with just browser APIs

    Thumbnail for On the Cutting Edge: a Glimpse into the Future of Web Performance

    On the Cutting Edge: a Glimpse into the Future of Web Performance

    Thumbnail for Web Performance Incubations

    Web Performance Incubations

    Thumbnail for The State of Web Performance

    The State of Web Performance

    Thumbnail for Making Web Apps as Smooth as Native

    Making Web Apps as Smooth as Native

More presentations from Code 2015

    Thumbnail for Canvas Cold War

    Canvas Cold War

    Thumbnail for Pop-up Accessibility

    Pop-up Accessibility

    Thumbnail for Getting Offline with the Service Worker

    Getting Offline with the Service Worker

    Thumbnail for Async and Await

    Async and Await

    Thumbnail for Console Dot

    Console Dot

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

    Stop the Fanaticism – Using the Right Tools for the Job

    Thumbnail for Eliminate JavaScript Code Smells

    Eliminate JavaScript Code Smells

    Thumbnail for Crossing The Streams

    Crossing The Streams

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

© Conffab 2023