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 nghttp2.org site. When you access https://nghttp2.org 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.

nghttp2_server_side_push

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.

plain_http_1_1_requests

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.

nghttp_server_side_push_benefit

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 and podcaster. Currently working on DNS Spy. Follow me on Twitter as @mattiasgeniar.

I respect your privacy and you won't get spam. Ever.
Just a weekly newsletter about Linux and open source.

SysCast podcast

In the SysCast podcast I talk about Linux & open source projects, interview sysadmins or developers and discuss web-related technologies. A show by and for geeks!

cron.weekly newsletter

A weekly newsletter - delivered every Sunday - for Linux sysadmins and open source users. It helps keeps you informed about open source projects, Linux guides & tutorials and the latest news.

Share this post

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

Comments

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!

Reply


    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.

    Reply


Evert Tuesday, February 10, 2015 at 00:57

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

Reply


    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.

    Reply


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.

Reply


    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.

    Reply


Leave a Reply

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

Inbound links