Service Side Push in HTTP/2 With nghttp2

Mattias Geniar, Monday, February 9, 2015 - last modified: Tuesday, February 10, 2015

At this pace of development, nghttp2 is a project to keep an eye on.

We implemented HTTP/2 server push in nghttpx and we enabled server push in site. When you access via HTTP/2 protocol, CSS file /stylesheets/screen.css is pushed to client.
nghttp2 blog

If you look at the page load of that blog in the browser, a few things stand out.


The response header contained the link: resource for sending additional content to the browser, without the client having to request for it (and thus needing to parse the DOM). This is finally showing server side push in HTTP/2 in the real world.

(note: to view the HTTP/2 protocol in the network tab, you should run Chrome Canary for the moment)

The result of this action is that the download of the stylesheet can happen much quicker. This is best shown with a comparison of a plain HTTP/1.1 site vs. the new HTTP/2 method with server side push.

Traditional HTTP/1.1 page load

For instance, here's the waterfall view of my own blog, running the classic HTTP/1.1 protocol.


The GET / request is made, and then stalls for a few milliseconds (~20ms) parsing the page before requesting the next resource, widget.css.

HTTP/2 Server Side Push page load

Compared to the HTTP/2 flow.


The DOM and all additional resources don't need to be parsed, the client can already begin the download of the screen.css resource, without "wasting time" processing the DOM and all external resources, only to make a new request to the server to begin fetching them.

When you add this all up for all resources on a page, this can easily save 100-200ms of the total page load/paint of a website. Those are numbers that should really have you consider implementing HTTP/2.

In terms of responsiveness and web speed, HTTP/2 can make a serious difference -- especially with server side push.

Hi! My name is Mattias Geniar. I'm a Support Manager at Nucleus Hosting in Belgium, a general web geek & public speaker. Currently working on DNS Spy & Oh Dear!. Follow me on Twitter as @mattiasgeniar.

Share this post

Did you like this post? Will you help me share it on social media? Thanks!


Thomas Tuesday, February 10, 2015 at 00:11 - Reply

So Google had a valid reason to abandon SPDY it seems.

Looking forward to a faster web!

    Mani Tuesday, May 12, 2015 at 22:26 - Reply

    SPDY is the first version of HTTP/2 and was what started everything.

    Google didn’t abandon it but rather showed off a better system and then pushed towards making it official as HTTP/2.

Evert Tuesday, February 10, 2015 at 00:57 - Reply

The Link header works on HTTP/1.1 as well though.

Frank Wednesday, February 18, 2015 at 18:30 - Reply

What about security? Will this affect browser plugins like NoScript for example? I don’t want to load all the scripts that the webmaster “thinks” I need.

    Evert Pot Friday, April 24, 2015 at 21:13 - Reply

    The fact that the server might push the scripts, doesn’t mean that the browser will load and parse them. Those mechanisms are separate.

    In reality the browser will likely just check out the list of resources it needs to parse as normally, and only then check which of those resources have already been pushed.

    This does mean that the ‘webmaster’ (people still have the title webmaster?) controls what gets sent, and that might be ‘more’ than you need. A browser can indicate however that it doesn’t want to receive push messages altogether. I can see this to be a useful setting for those on very low bandwidth.

Leave a Reply

Your email address will not be published. Required fields are marked *

Inbound links