Issue 5: HTTP/2 Push

Jul 5, 2016 · 4 min read

HTTP/2! Our glorious saviour from all the awkward workarounds that HTTP/1 made us do to have a decently performing web app. I hope you are using it already. Since CloudFlare added support for HTTP/2, it has gotten a lot easier to switch to HTTP/2 and adoption has been steadily rising ever since. All the latest versions of browsers support it as well, so not only is it a good time to optimize for HTTP/2, but you can most likely safely ignore HTTP/1 at this point. I thought it was about time to take a look at HTTP/2’s infamous push feature. And then reality happened.

HTTP/2 push is a feature that lets you push a response to the client’s cache* that it hasn’t even requested yet. This will allow you to use the network while the browser is too busy parsing the HTML document. You can provide the resources you know the browser will need any moment now. This is yet another HTTP/2 knob you can use to turn your web app loading performance up to 11.

*) Not correct. See below.

The app

Image for post
Image for post
Yes, I wrote this code myself!

The web server uses HTTP/2 push to send that image to the browser when a request for `index.html` comes in. But how would I know if it worked? DevTools didn’t show me when resources were pushed. My idea was that I would use DevTools’ network throttling feature to make the image load slow. In normal circumstances the image would load progressively due to the throttling. If the image got pushed however, the 5 second timeout should be enough for the picture to be completely loaded into the browser’s cache and appear instantly. But no matter how I turned and twisted my code, the image would always load progressively and never instantly — until I unchecked “Disable cache” in DevTools. I have this option enabled almost all the time for development. Immediate conclusion: HTTP/2 needs the browser’s cache to be enabled to work! Interesting. This led me to make this tweet, which got decent exposure. And it’s wrong! Factually wrong. I failed y’all.

Image for post
Image for post
My tweet of shame

Fact #01: You can see pushes in DevTools’ network panel 🔎

*) In my defence: I did check Canary, but for some reason the initiator column was hidden.

Image for post
Image for post
DevTools in Canary marks pushed resources

But since I found out about this feature a little late, I also wrote http2-push-detect. It’s a simple node.js CLI tool that lists all pushed resources for a given URL.

Image for post
Image for post
Installing & using http2-push-detect

Fact #02: In Chrome*, pushed resources are stored in a magical place before the HTTP cache 🌈

*) I have yet to figure out the details for other browsers.

Fact #03: There’s a bug in Chrome DevTools that makes push and throttling not play nice 🐞

Bottom line: This just showed me how new HTTP/2 still is and that there’s a lot of explorations and tests to be done. With design patterns like PRPL arising, we will have to collect much more detailed knowledge to make informed decisions about what is best for our apps.

Totally Tooling Tears

Addy and Matt’s ramblings about tooling for the web.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store