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 an independent software developer ⌨️ & Linux sysadmin 👨‍💻, a general web geek & public speaker. Currently working on DNS Spy & Oh Dear! Follow me on Twitter as @mattiasgeniar 🐦.

🔥 If you're stuck with a technical problem, I'm available for hire to help you fix it!

Share this post

Did you like this post? Help me share it on social media! Thanks. 🤗

Have feedback?

New comments have been disabled on this blog, existing comments will remain as-is. Want to give feedback? Is there a mistake in the post?

Send me a tweet on @mattiasgeniar!


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

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 -

    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 -

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

    Mattias Geniar Tuesday, February 10, 2015 at 09:48 -

    Correct, but the difference here is that nghttp2 interprets that header sent via Nginx behind it, and immediately pushes that response to the client, without the client having to make a GET request to it first.

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

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 -

    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.

Inbound links