RWD Podcast Episode 8: HTTP2 & Client Hints
Listen to episode
Hey everyone and welcome to podcast number 8.
This week I wanted to talk a little bit about performance, and specifically around some new options coming up in the future with Client Hints and HTTP2.
Earlier this week I attended this months London Web Standards where Mark Nottingham of @mnot was speaking. Mark has been working with HTTP/1.1 and HTTP2 for the past 7 years so he knows what he’s talking about.
I will try and cover off some of the things he mentioned.
We’re at http/1.1 right now.
History
- started in 94/95, since then not much has changed in the spec. Nothing wrong with the current implementation, but the web has fundamentally changed since then.
- Websites are heaveier
- More interactive.
- Past 2 years avg number of http requests have gone from 79 – 100, and 626kb to more than a MB.
- Profit and bottom line is affected with poor performance. We all know that the slower sites load the less conversions, and therefore profit, we make. Amazon, Bing, Google… they have all tested this for us.
- Mobile has arrived. In 94/95, mobile was a giant brink you needed a car to move around.
- Unforutnately 3g has a 400ms delay and 4g, super fast, has a 150ms delay with every http request.
- To deal with this we have developed coping mechanisms.
Coping Techniques
Spriting
If you’re going to update a small part of the image you need to recall the in tire image.
Inlining
Inlining the images into the CSS as Base64. It was decided that was faster than calling multiple http requests.
Sharding
If you split images or files across multiple hosts then you can do more parallel requests.
Concatenation
Tie a series of files together to only have a single HTTP request.
We know all of these things as performance techniques when in fact they are all hacks on the spec of http1.1 to cheat better performance.
This, like the hacks for responsive images, point to the fact that something needs to be improved.
What’s new in HTTP2?
Eliminate http requests
The common theme is to limit the number of requests. The less times you request something from the server the faster you site will be. but what happens if we improve the protocol, could we limit this?
- http/1 users uses TCP poorly
- with 1.1 they included pipelining to send across multiple requests on a single tcp but there was blocking.
- HTTP flows are short and bursty, but TCP was built for long and lengthy requests.
- 83 requests take approximately 7-8 round trips to just send it out on to the wire. With a 3g connection of 400ms per request that’s a lot of time mobile.
Server Push
Allows the server to actively push files to the client before it has to request it. Basically if you’re sending back the HTML document back the server already knows what files are going to be requested next (CSS, JS, images etc etc).
How will this affect me?
- It will be easier to server faster websites.
- Google has released numbers, increase of 43% faster improvements.
- Twitter – Twitter client on the phones are using http2 using speedy requesting from the twitter servers. They don’t care, they just put it into production. lol.
- The point is that you should still be able to use the same http api, but provide a few additional knobs to tweak things you didn’t previously have access to.
How does client hints work?
Well one of the things we would like to be able to do is send down the wire a high DPI version of an image when the device requires it, and a smaller dpi version when we can skimp on the large image. This might be when the bandwidth is low, or the device can not take advantage of a higher DPI image.
At the moment we’re only able to do this via Media Queries in CSS, however wouldn’t it be great if that could be done outside of the CSS.
// Client Hints can be used as input to proactive content negotiation; just as the Accept header allowed clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences. //
(request) GET /img.jpg HTTP/1.1 User-Agent: Awesome Browser Accept: image/webp, image/jpg CH-DPR: 2.0 (response) HTTP/1.1 200 OK Server: Awesome Server Content-Type: image/jpg Content-Length: 124523 Vary: CH-DPR DPR: 2.0 CH-DPR – Device Pixel Ratio
CH-RW – Requested Width
This would allow you, effectively, to only include a single image source within your markup and allow the server to decide the correct image to return.
So what else could we do with Client Hints?
We could pass the bandwidth information across to the server as well. That might give us more understanding over the type of connection the user is currently on a allow us to choose the size of the resource that is returned.
For example even if the CH-DPR is set to 2 or greater, or the CH-RW is set to a desktop sized screen we could detect that the client is accessing the internet over a tethered 3G connection in a slow area… and therefore still just serve up a lower quality image.
I always used to think that caching would be an issue in this area, but if there server is making the decision which content to send the request then it can already cache those responses to those requests… even if it’s the same URI it now has the additional information as part of the request to make the cache more fine grained. On the client side the same image won’t be re-requested unless it’s expired, so there’s a regualr win there too.
some complaints about this is that it increases the header size and therefore makes the request slower over the wire, however with http2 that is no longer true. So really there’s no downside.
Automating DPR switching with Client-Hints
