Here's How HTTP/2 Server Push Can Help Your Website Load Faster 

Just imagine: a web server sending resources to a web browser before the later has even got the chance to explicitly request for them! Yes, I'm talking about the HTTP/2 server push instant performance-booster! And it's precisely this kind of "latency killers” that you, a performance-minded Drupal developer must be "hunting for", right? Well, let me explain to you how it works exactly, what planning it requires and how it impacts a site's performance:

First of all I need to put the spotlight on the two main "culprits" for the HTTP/2's impact on a web page's load time: 

  1. single TCP Connection 

     
  2. server push 

The first: an improved technique for handling requests. The second: a performance feature "empowering" the web server to "push" content to the web browser "ahead of time". Based on a promise sent by the server regarding a request that the web browser is most likely to make.

 

Single TCP Connection 

You know how HTTP/1.1 handles multiple requests, don't you? That it uses multiple TCP connections to answer the challenge? A way of addressing this aspect which inevitably “bugs down” the website.

Instead, HTTP/2 operates with a single TCP connection for all the requests that are being sent over. This way all the responses are being sent, in parallel, over the same connection!

And it's via streams masked with IDs that the web server and the web browser “interact” for handling the numerous requests!

 

HTTP/2 Server Push 

Basically, it's a revolutionary performance enhancement that HTTP/2 brings to make life easier for us, the performance-minded programmers, by restructuring the whole request-response pattern from the ground-up!

If, by now, whenever a site is being accessed, there's a:

  1. request that's being sent from the browser to the server

     
  2. the HTML that's being “tracked down” and parsed

     
  3. then all the one by one requests that follow up, whenever the server “realizes” that it needs all kinds of other resources (different stylesheets and several scripts), too

     

And it's all these round trips that delay the rendering of the page to the web browser and increase load time!

Now here's the HTTP/2 server push method presented in 2 simple steps:

  1. the request is being made and the HTML sent

     
  2. while the browser parses it through, the CSS and JavaScvript files are already being prepared to be sent over, before the browser even gets to “discover” that it actually needs them 

     

Or maybe a real-life example would be far more suggestive:

Imagine that you (or your client) own a Drupal website for which style.css sheets are defining. So, the moment a client requests for the index.html, your server preemptively prepares those the style.css, as well, and sends them over immediately after he's responded to the initial index.html request!

A time-saving, load time-enhancing technique! The server anticipates, based on the site's particularities (e.g. which type of resources it stores, JavaScript, CSS etc., and which are the most frequently requested ones) and prepares to send or push the right assets... ahead of the requests!

Pretty cunning, don't you think?

 

The Push_Promise Frame 

The HTTP/2 server push processes the whole request-response cycle by preparing a push_promise frame! 

It practically prepares the web server, letting it know what resources it will receive so that... it shouldn't be taken by surprise.

And here is where you should intervene if you really want to leverage the HTTP/2 server push' power and impact your Drupal site's performance! Planning is key here!

These are the 2 key aspects that you should think through and give due consideration to, so that this “promise-based” pushing process should go smoothly:

  1. mind you think through your pushes: push only those assets that are truly needed

     
  2. give catching due consideration: carefully plan the catching of your pushed resources (optimize your site's performance to ensure that the same assets are not repeatedly being forced upon the web browsers)

     

Quick Recap:

HTTP/2 server push does come “packed” with some tremendous performance gains, but you get to unlock and fully “exploit” them to your site's benefit only if/when handled right:

  1. mind the size of the pushed assets

     
  2. apply the web push notification best practices (e.g. push on the user's first visit only), thus sparing valuable bandwidth

I'm curious to hear your thoughts on HTTP/2 server push! Have you already harnessed the power of the new version of the HTTP protocol, along with its most powerful feature, on any of the Drupal websites that you've optimized for speed?