The Cloudflare Blog

Accelerating Node.js applications with HTTP/2 Server Push

Terin Stock — Tue, 16 Aug 2016 12:17:19 GMT

In April, we announced support for HTTP/2 Server Push via the HTTP Link header. My coworker John has demonstrated how easy it is to add Server Push to an example PHP application.

CC BY 2.0 image by Nicky Fernandes

We wanted to make it easy to improve the performance of contemporary websites built with Node.js. we developed the netjet middleware to parse the generated HTML and automatically add the Link headers. When used with an example Express application you can see the headers being added:

We use Ghost to power this blog, so if your browser supports HTTP/2 you have already benefited from Server Push without realizing it! More on that below.

In netjet, we use the PostHTML project to parse the HTML with a custom plugin. Right now it is looking for images, scripts and external stylesheets. You can implement this same technique in other environments too.

Putting an HTML parser in the response stack has a downside: it will increase the page load latency (or "time to first byte"). In most cases, the added latency will be overshadowed by other parts of your application, such as database access. However, netjet includes an adjustable LRU cache keyed by ETag headers, allowing netjet to insert Link headers quickly on pages already parsed.

If you are designing a brand new application, however, you should consider storing metadata on embedded resources alongside your content, eliminating the HTML parse, and possible latency increase, entirely.

Netjet is compatible with any Node.js HTML framework that supports Express-like middleware. Getting started is as simple as adding netjet to the beginning of your middleware chain.

var express = require('express');
var netjet = require('netjet');
var root = '/path/to/static/folder';

express()
  .use(netjet({
    cache: {
      max: 100
    }
  }))
  .use(express.static(root))
  .listen(1337);

With a little more work, you can even use netjet without frameworks.

var http = require('http');
var netjet = require('netjet');

var port = 1337;
var hostname = 'localhost';
var preload = netjet({
  cache: {
    max: 100
  }
});

var server = http.createServer(function (req, res) {
  preload(req, res, function () {
      res.statusCode = 200;
      res.setHeader('Content-Type', 'text/html');
      res.end('Hello World');
  });
});

server.listen(port, hostname, function () {
  console.log('Server running at http://' + hostname + ':' + port+ '/');
});

See the netjet documentation for more information on the supported options.

Seeing what’s pushed

Chrome's Developer Tools makes it easy to verify that your site is using Server Push. The Network tab shows pushed assets with "Push" included as part of the initiator.

Unfortunately, Firefox's Developers Tools don't yet directly expose if the resource pushed. You can, however, check for the cf-h2-pushed header in the page's response headers, which contains a list of resources that CloudFlare offered browsers over Server Push.

Contributions to improve netjet or the documentation are greatly appreciated. I'm excited to hear where people are using netjet.

Ghost and Server Push

Ghost is one such exciting integration. With the aid of the Ghost team, I've integrated netjet, and it has been available as an opt-in beta since version 0.8.0.

If you are running a Ghost instance, you can enable Server Push by modifying the server's config.js file and add the preloadHeaders option to the production configuration block.

production: { 
  url: 'https://my-ghost-blog.com', 
  preloadHeaders: 100, 
  // ... 
}

Ghost has put together a support article for Ghost(Pro) customers.

Conclusion

With netjet, your Node.js applications can start to use browser preloading and, when used with CloudFlare, HTTP/2 Server Push today.

At CloudFlare, we're excited to make tools to help increase the performance of websites. If you find this interesting, we are hiring in Austin, Texas; Champaign, Illinois; London; San Francisco; and Singapore.

Ask Some HTTP/2 Pros The Hard Questions

Elenitsa Staykova — Wed, 20 Jul 2016 00:27:17 GMT

We're big fans of HTTP/2 and our customers make up the majority of HTTP/2 enabled domains today. HTTP/2 is a key part of the modern web, and its growth and adoption is changing how websites and applications are built.

On Thursday July 21, 2016, join web performance experts Ilya Grigorik (Web Performance Engineer at Google) and Suzanne Aldrich (Solutions Engineer at CloudFlare), as they discuss the latest in HTTP/2 and Server Push, the tools and resources you can use today to build fast and scalable web apps, and ways to speed up your content on any device.

When: Thursday July 21, 2016 from 1pm-2pm Eastern Time (1500 – 1600 UTC)

Who: CloudFlare’s own Suzanne Aldrich and Ilya Grigorik from Google

Need the basics of HTTP/2 and Server Push? Visit the CloudFlare HTTP/2 website.

HTTP/2 Server Push with multiple assets per Link header

John Graham-Cumming — Thu, 30 Jun 2016 12:09:46 GMT

In April we announced that we had added experimental support for HTTP/2 Server Push to all CloudFlare web sites. We did this so that our customers could iterate on this new functionality.

CC BY 2.0 image by https://www.flickr.com/photos/mryipyop/

Our implementation of Server Push made use of the HTTP Link header as detailed in W3C Preload Working Draft.

We also showed how to make Server Push work from within PHP code and many people started testing and using this feature.

However, there was a serious restriction in our initial version: it was not possible to specify more than one asset per Link header for Server Push and many CMS and web development platforms would not allow multiple Link headers.

We have now addressed that problem and it is possible to request that multiple assets be pushed in a single Link header. This change is live and was used to push assets in this blog post to your browser if your browser supports HTTP/2.

When CloudFlare reads a Link header sent by an origin web server it will remove assets that it pushes from the Link header passed on to the web browser. That made it a little difficult to debug problems with Link and Server Push so we have added a header called Cf-H2-Pushed which contains the assets that were pushed.

For example, browsing to this recent blog post results in the origin web server sending the following headers:

Cache-Control: public, max-age=0
Content-Encoding: gzip
Content-Length: 33640
Content-Type: text/html; charset=utf-8
Date: Wed, 29 Jun 2016 16:09:37 GMT
Expires: Wed, 29 Jun 2016 16:10:07 GMT
Link: ; rel=preload; as=style,; rel=preload; as=script,; rel=preload; as=image,; rel=preload; as=image,; rel=preload; as=script,; rel=preload; as=script,; rel=preload; as=script
Vary: Accept-Encoding
X-Ghost-Cache-Status:From Cache
X-Powered-By: Express

CloudFlare decides to HTTP/2 Server Push the assets /assets/css/screen.css?v=5fc240c512, /content/images/2016/06/Timeouts-001.png, /content/images/2016/06/Timeouts-002.png and /assets/js/jquery.fitvids.js?v=5fc240c512. As the response passes through CloudFlare those assets are removed from the Link header, pushed and added to the Cf-H2-Pushed header:

cache-control:public, max-age=30
cf-cache-status:EXPIRED
cf-h2-pushed:,,,
content-encoding:gzip
content-type:text/html; charset=utf-8
date:Wed, 29 Jun 2016 16:09:37 GMT
expires:Wed, 29 Jun 2016 16:10:07 GMT
link:; rel=preload; as=script,; rel=preload; as=script,; rel=preload; as=script
server:cloudflare-nginx
status:200 OK
vary:Accept-Encoding
x-ghost-cache-status:From Cache
x-powered-by:Express

In Google Chrome Canary's Developer view the pushed assets can be clearly seen.

Conclusion

Please let us know how you use Server Push. We're particularly interested in experiences with pushing different types of resources (images vs. styles vs. scripts) and working out the optimal number of items to push (we currently allow up to 50 resources per page).

Using HTTP/2 Server Push with PHP

John Graham-Cumming — Fri, 13 May 2016 13:11:28 GMT

Two weeks ago CloudFlare announced that it was supporting HTTP/2 Server Push for all our customers. By simply adding a Link header to an HTTP response specifying preload CloudFlare would automatically push items to web browsers that support Server Push.

To illustrate how easy this is I create a small PHP page that uses the PHP header function to insert appropriate Link headers to push images to the web browser via CloudFlare. The web page looks like this when loaded:

There are two images loaded from the same server both of which are pushed if the web browser supports Server Push. This is achieved by inserting two Link headers in the HTTP response. The response looks like:

HTTP/1.1 200 OK
Server: nginx/1.9.15
Date: Fri, 13 May 2016 10:52:13 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Link: ; rel=preload; as=image
Link: ; rel=preload; as=image

At the bottom are the two Link headers corresponding to the two images on the page with the rel=preload directive as specified in W3C preload draft.

The complete code can be found in this gist but the core of the code looks like this:

    ; rel=preload; as=image", false);
        return <<

    

    PHP Server Push
    

    PHP Server Push

Since you have to call the PHP header function before any output (such as HTML) has occurred the code makes two calls to a helper function called pushImage first. pushImage adds the appropriate Link header and returns the HTML needed to insert the actual image in the page.

Later the variables $image1 and $image2 (which contain the HTML needed to display the images) is inserted use two other helper functions (ccbysa and ccbynd) that add captions. Those two helper functions don't play any part in the Server Push, they just ensure that the HTML is placed correctly on the page with a caption.

Notice that the Link header is added as follows:

header("Link: <{$uri}>; rel=preload; as=image", false);

The false second parameter tells header to not override an existing Link header. With that option specified multiple Link headers can be added. Without it the last call to pushImage would win.

Effect of Server Push

To understand the effect of Server Push on the example I used Google Chrome Canary and loaded the page twice (once without the Link headers so that no push would occur and once with).

Here's the simple waterfall over HTTP/2 with no Server Push:

The page load time was 651ms. You can see the initial page HTML load in 175ms followed by the two images.

How here's the waterfall with HTTP/2 Server Push:

The page load time was 251ms (the HTML loaded in 168ms) and Chrome is showing that the two images were pushed (see the Initiator column).

It's not 100% obvious what happened there but digging into chrome://net-internals/ it's possible to see a detailed HTTP/2 timeline. I've edited out a few details of the protocol (such as the window size changes) to focus in on the requests and responses.

The t value gives the tick time (1ms per tick).

t=910212 [st=   1]    HTTP2_SESSION_SEND_HEADERS
                      --> exclusive = true
                      --> fin = true
                      --> has_priority = true
                      --> :method: GET
                          :scheme: https
                          :path: /index.php
                          pragma: no-cache
                          cache-control: no-cache
                          upgrade-insecure-requests: 1
                          accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
                          accept-encoding: gzip, deflate, sdch, br
                          accept-language: en-US,en;q=0.8
                          cookie: [52 bytes were stripped]
                      --> parent_stream_id = 0
                      --> priority = 0
                      --> stream_id = 1

[...]

t=910404 [st= 193]    HTTP2_SESSION_RECV_HEADERS
                      --> fin = false
                      --> :status: 200
                          date: Fri, 13 May 2016 11:28:16 GMT
                          content-type: text/html
                          content-encoding: gzip
                      --> stream_id = 1
t=910405 [st= 194]    HTTP2_SESSION_RECV_PUSH_PROMISE
                      --> :method: GET
                          :path: /images/drucken.jpg
                          :scheme: https
                          accept-encoding: gzip, deflate, sdch, br
                      --> id = 1
                      --> promised_stream_id = 2
t=910405 [st= 194]    HTTP2_SESSION_RECV_PUSH_PROMISE
                      --> :method: GET
                          :path: /images/empire.jpg
                          :scheme: https
                          accept-encoding: gzip, deflate, sdch, br
                      --> id = 1
                      --> promised_stream_id = 4
t=910405 [st= 194]    HTTP2_SESSION_RECV_DATA
                      --> fin = false
                      --> size = 298
                      --> stream_id = 1
t=910405 [st= 194]    HTTP2_SESSION_RECV_DATA
                      --> fin = true
                      --> size = 0
                      --> stream_id = 1
t=910409 [st= 198]    HTTP2_SESSION_RECV_HEADERS
                      --> fin = false
                      --> :status: 200
                          date: Fri, 13 May 2016 11:28:16 GMT
                          content-type: image/jpeg
                          content-length: 49852
                          set-cookie: [124 bytes were stripped]
                          etag: "5735aac0-12f99"
                          last-modified: Fri, 13 May 2016 10:21:52 GMT
                          cf-cache-status: HIT
                          vary: Accept-Encoding
                          expires: Fri, 13 May 2016 15:28:16 GMT
                          cache-control: public, max-age=14400
                          accept-ranges: bytes
                          server: cloudflare-nginx
                      --> stream_id = 2
t=910409 [st= 198]    HTTP2_SESSION_RECV_DATA
                      --> fin = false
                      --> size = 987
                      --> stream_id = 2
t=910409 [st= 198]    HTTP2_SESSION_RECV_DATA
                      --> fin = false
                      --> size = 1369
                      --> stream_id = 2
t=910410 [st= 199]    HTTP2_SESSION_RECV_DATA
                      --> fin = false
                      --> size = 1369
                      --> stream_id = 2

The web browser sends an HTTP2_SESSION_SEND_HEADERS request asking for the web page (that's the first item above) and subsequently receives the response headers and page followed immediately by two push promises for the two images. It then immediately starts receiving image data (see the stream_id 2).

CloudFlare's web server is pushing the image contents before the browser asked for them. When CloudFlare pushes an item specified in a Link header the header itself is stripped (to prevent the browser from re-requesting the resource).

The Future Starts Here

We released HTTP/2 Server Push support to help kick start innovative use of this critical feature of HTTP/2. We would love people to start experimenting with it to see how much of a speed improvement is possible with their specific websites.

As can be seen from this blog post making use of Server Push in a web application is easy: just insert Link headers with the appropriate format. Server Push will be particularly fast if the items being pushed are also stored in CloudFlare's cache (as was the case with the examples above).