An introduction to HTTP/2 & Page Speed

ByAyima Team

Introduction

In 1991, the first documented version of the request-response HTTP (HTTP 0.9) protocol was introduced. Since then, the web has drastically expanded and, 24 years later, the most recent version of HyperText Transfer Protocol (HTTP/2) was released in 2015, introducing a multitude of possible benefits to site performance when correctly implemented.

This article is aimed at SEOs wishing to implement HTTP/2 as part of their page speed optimisation initiatives.

HTTP/2 is an extremely rich topic which could be discussed in great detail. There is a wealth of online information discussing HTTP/2 and it’s wider benefits for end-users and developers, but before you find yourself immersed in the wealth of information around HTTP/2, make certain you’re getting the information that you need. This begins with asking the right questions:

  1. How will this directly impact search engine optimisation and/or page speed?
  2. Can a recommendation be made off of the insight?
  3. Can the recommendation realistically be carried out?

These questions help you to ask “is what I am doing effective and valuable?” and ultimately put you in a better position to evaluate how HTTP/2 can help improve a website.

Due to the broad nature of the topic, there is a large amount of knowledge around HTTP/2 that is not needed when trying to understand the importance to SEO. The core benefit of HTTP/2 for SEO is Page Speed. 

To help you navigate through the wealth of online information, here is an introduction to HTTP/2, describing the evolution from HTTP 1.1 through to Google’s HTTP compatible Spdy and eventually to HTTP/2. 

Understanding how the web has evolved will help highlight the improvements that have been made to it as a consequence of the addition of the HTTP/2 protocol. 

How does Google evaluate Page Speed?

To look at how Google evaluates Page Speed look no further than the Chrome User Experience Reports. These reports provide user experience metrics for how users are experiencing popular destinations across the web. This is powered using key user engagement metrics (First Paint, First Contentful Paint, First Meaningful Paint, Time to Interactive) and is further supported via common tools such as Page Speed Insights, Public Google Big Query Project, Lighthouse, and Web Page Test. Utilising these metrics and tools can help make possible improvements around Page Speed.

Introduction to HTTP/2

HTTP 1.1

By 2015, HTTP 1.1 had become outdated. Gone were the days where web pages/sites were built/relied on basic HTML, CSS, and JavaScript, and numerous resources and different frameworks. The pre-2015 era was based on the idea that you were limited to one request per TCP connection. This led to situations where web clients had multiple resources queuing for download, causing congestion of the network and slow page loading times. 

HTTP/2 was designed to target three main areas of improvement to alleviate the issues discussed above:

  • Simplicity
  • High Performance
  • Robustness

SEO Benefits for HTTP/2

Page Speed is probably the primary reason that SEOs would consider implementing HTTP/2 across either their own or their client’s websites. Page Speed/ Performance is a set of metrics which have been a ranking factor since 2010 for Desktop queries.  Due to the rise of mobile device usage, in July 2018 Google officially announced that Page Speed would become a ranking factor for Mobile.  

HTTP/2 provides 3 main functionalities which can be utilised when optimising sites for Page Speed:

  1. Multiplexing
  2. Server Push
  3. Stream Prioritisation

Multiplexing

Multiplexing allows a web client to include multiple requests within one single TCP connection, resulting in lower server load and reducing network congestion.

Modern web clients (Chrome, Firefox, Safari and Opera) utilising the older HTTP 1/1.1 protocols have a default limit on the number of simultaneous TCP connections per hostname. Therefore, a web client utilising HTTP 1/1.1 can easily have difficulty with TCP congestion. With modern web clients, this issue is resolved using multiplexing, which can give some of the most significant improvements to page speed.  

Demonstrated below is the benefit of Multiplexing using a comparison of HTTP/1.1 and HTTP/2, showing typical behaviour for when HTTP/2 multiplexing is and is not enabled.

(WebpageTest, HTTP/1.1, No Multiplexing Demonstrated)

(WebpageTest, HTTP/2, Multiplexing Demonstrated)

In the images above a performance-based waterfall is used to demonstrate the loading of resources between a user (who requests the resources) and the server (who responds with the resources) of a webpage. Typically, page resources include HTML, JavaScript, CSS and images. The performance-based waterfall demonstrates the exact point as to when a specific resource is called, downloaded and rendered within the client which is critical in discovering, evaluating and analysing page speed issues on a site. As demonstrated by the image above “HTTP/2”, all resources begin downloading concurrently without any resources beginning to load at a different point. As HTTP/2 utilises multiplexing and no longer relies on sending only 1 request over a single TCP connection, multiple resources can be downloaded at the same time seen above. In contrast, as demonstrated by image “HTTP/1.1”, resources do not download concurrently as they are unable to utilise the multiplexing functionality.  The average modern browser under HTTP/1.1 is able to concurrently have 6 connections, but the benefit for implementing HTTP/2 is that a TCP handshake is not needed for every request whereas no matter how many connections can concurrently run with HTTP/1.1 an initial connection process must be completed every time. Therefore they are beginning to download at different points thus causing a longer page load for the user.

(Upwork HTTP/1.1 vs HTTP/2 Diagram)

Search crawlers such as Google and Bing do not directly benefit from HTTP/2 implementation. As described above the major benefit from these optimisations could potentially be for Page Speed.  Therefore although HTTP/2 implementation may not affect the search crawler directly, it can impact Page Speed which is a direct ranking factor for Google for Desktop queries since 2010 and Mobile queries since July 2018. As a result, it’s critical that websites are not delivering a slow experience to users, as Google may suppress performance by impacting rankings, or more recently, flagging to users that your site may be slow.

Server Push

Server Push allows the specific server or edge network to send resources to web clients when they have not been requested by the client. For an understanding of how server push functions, it’s first important to understand the request-response pattern that a website follows. A user requests a page from a website, and the server responds with the requested content/resource. 

Hypothetically, think about a site which has all of its styles defined in an external style sheet called styles.css. When the user requests the HTML skeleton for the page (let’s say in this case index.html) server push can “push” the CSS to the user right after beginning to send a response to index.html. 

(Smashing Magazine, Server Push)

Before understanding how Server Push can help improve Page Speed it is important to understand how a browser works with different resources such as images, CSS, and JavaScript to appear within your browser. You see, the browser sends instructions for how to download images, CSS, and JavaScript resources. When first visiting a website you usually make a GET request, which is the .html file. Once this .html file is received, the browser scans through it to understand it and then may make additional GET requests depending on what is contained within the HTML file.

How does Server Push help improve Page Speed?

Through the use of Server Push, the number of GET requests needed from the browser (round trips) are reduced and delays in rendering that cause increased page load times are avoided. This can dramatically help improve the rendering time for the web client, which helps the webpage appear quicker for users thereby providing them with a far better experience. 

While Server Push does not directly impact how Googlebot crawls your site, or indeed other crawlers, the SEO benefit is gained through improvements to user-centric factors such as First Paint and First Meaningful Content.

Utilising Web Page Test, Lighthouse, Page Speed Insights, and the Chrome User Experience Report, you can determine how a site/page is performing in comparison to competitors within the same industries. Below are two images demonstrating implementation without (Image 1) and with Server Push (Image 2).

(WebpageTest, Without Server Push)

(WebpageTest, HTTP/1.1, With Server Push)

With server push, the server can be configured so that it always sends any additional page components (such as CSS files, JavaScript and images) if it is asked to send over the .html file containing them.

In the waterfalls above we can see that push.php uses four CSS files. 

Without server push, the browser needs to receive the push.php file, parse the HTML and then make specific requests for each additional CSS file. Only once it’s received all CSS files can it start using them in the rendering process.

When server push is enabled, the request for push.php automatically triggers the server to send over the four CSS files. The browser receives them and can start using them in the rendering process much earlier. This means the browser can start rendering the page content much sooner, which results in better page speed metrics.

HTTP/2 Prioritisation

HTTP/2 Prioritisation hands control of the order in which resources are loaded, back to site owners. Done properly, Prioritisation benefits user experience and Page/Site speed by delivering page resources in an optimised order, thus creating a “fast” user experience.

If we look at HTTP/2’s predecessor HTTP/1.1, the web client controlled the order of when resources would be loaded. As discussed above this was due to the fact that each TCP connection was only able to support one resource at a time. It is up to the browser to schedule requests by deciding what resources to choose and how many connections to open in parallel. 

Before getting into how it’s done, it is important to understand why we would want to use Prioritisation for our resources. 

If we have an image at the top of a page and an image at the bottom of the page, logically we would want to make sure the image at the top loads before the image at the bottom. This concept helps demonstrate the importance and impact of HTTP/2 Prioritisation can bring. HTTP/2 prioritisation allows us to specify which resources should be delivered first and load before others (whether they are JavaScript, CSS, or images), thus ensuring the fastest load time for the page.

While the browser can now request multiple resources simultaneously over a single TCP connection using multiplexing, it can now also specify priority information with each request to help determine when/how the resource should be delivered. If both the server and the browser supports HTTP/2 Prioritisation the browser should define the rules for prioritisation utilising full bandwidth without having resources competing with each other. In order to better understand how the prioritisation process functions it’s important to discuss three parameters which are important for HTTP/2 Prioritisation:

Stream: This is a bidirectional flow of bytes within an established connection which may carry one or messages.

Parent Stream: This is a stream which the resources are dependent on

Child Stream: This is a dependent stream of the parent stream. They share the same parent and thus are known as child stream

Weight: This is a number allocated between 1 and 256 which identifies how much bandwidth to allocate to stream if multiple streams are sharing a connection. Bandwidth is allocated relative to the weights of all other active streams.

Exclusive Bit:  This is a flag indicating that the stream should be downloaded without sharing bandwidth with any other streams.

Headers Frame: This is the identification for the stream to which frame it belongs to 

Binary Framing Layer: This is how HTTP messages are encapsulated and transferred between client and server

An example below demonstrates an example of the above:

(Google Developers HTTP/2 Stream Prioritisation)

In order to carry out HTTP/2 Prioritisation, you will need to add prioritisation information within the Headers Frame located within the new HTTP/2 Binary Framing Layer. The parent stream and dependency/non-dependency on other child streams will determine the priority/weighting and thus the delivery to the web client of the resource. 

Although HTTP/2 prioritisation is now supported across numerous platforms, many CDNs and hosting providers do not support HTTP/2 prioritisation. It is therefore important to make sure that you are utilising a CDN/hosting provider that does support HTTP/2 prioritisation if you wish to use this optimisation technique. Below is a table describing which CDN/hosting/servers are able and unable to support HTTP/2 Prioritisation.

HTTP/2 Prioritisation – Common Server/Hosting/CDNs Compatibility

This comparison was correct on 02/01/2020, but it’s worth checking if potential service providers have improved their compatibility before making your decision about which to choose.

It is also important to look at specific browsers critically because unfortunately not all browsers support HTTP/2 prioritisation and prioritise differently due to being different web clients. Below is a table describing which web clients are able to support HTTP/2 Prioritisation.

HTTP/2 Prioritisation Web Client Compatibility

HTTP/2 Prioritisation can significantly improve a user’s perception of Page/Site Speed and will positively impact the data accumulated within the Chrome User Experience Report. While this optimisation has no impact on search crawlers such as Googlebot, tools such as Lighthouse and Page Speed Insights will help you assess the impact of HTTP/2 Prioritisation on page speed performance from a user’s perspective.

By correctly configuring the stream weight with both server and client utilising an HTTP/2 supported CDN/host, you’ll be able to drastically improve your page speed metrics for your client. 

What are the prerequisites for HTTP/2

Before you’re able to take advantage of the speed benefits of HTTP/2, make certain that you’re able to utilise it. There are a few prerequisites that need to be taken into account: 

  1. It’s important to make certain that HTTPS is enabled.
  2. Utilise a TLS certificate from an authenticated authority and activate and install the certificate. 
  3. Make certain that your Web Server software such as Nginx, Apache, and IIS supports HTTP/2. A full authenticated list for support can be found at http://ayi.ma/browsershttp2 which will show browser support for HTTP/2. If you’re looking for HTTP/2 support for CDN’s/Hosting please refer to http://ayi.ma/serverhosting. 

Common Pitfalls / Things That Must Change with the Introduction of HTTP/2

Due to the limitations of the earlier HTTP 1.0 and HTTP 1.1  protocols, developers and SEOs have strived to find ways around the multitude of issues that these limitations presented for page speed performance and security. 

Eventually, they were able to find “hacks” to side-step some of these limitations, but many of these methods caused developers even more work. What are some of these hacks you may ask? Here are some of the most common hacks you’ll see on sites which can be resolved through the correct implementation of HTTP/2.

Avoid Domain Sharding

Surprisingly, a multitude of sites still use this hack although they have HTTP/2 correctly implemented. When HTTP/2 is enabled it will be important to avoid utilising domain sharding. Domain Sharding is the technique of splitting resources across different hostnames, thus allowing more resources to be served simultaneously. 

Thanks to the updated HTTP/2 protocol, Domain Sharding is no longer needed and in fact, causes more issues than it resolves. If HTTP/2 is correctly configured and enabled for your site and you also use Domain Sharding, you are actually counteracting some of the benefits of HTTP/2 since the browser will be unable to benefit from multiplexing and downloads across multiple hostnames. 

Furthermore, through Domain Sharding you are actually breaking Stream Prioritisation and your resources will not be able to be loaded to get the most out of Page Speed. 

Properly Utilise Server Push

Server Push has some drawbacks that you should be aware of. Server Push can, in fact, be overused and you should be selective when choosing when to use it. You do not necessarily want to push too many resources since this could cause the web client to download not only HTML but everything that it is “pushed” with. This means that the page might actually take longer to load and render (increasing user-centric metrics that are focused on by Google such as Time to Interactive). 

A second common pitfall for server push is figuring out how to not push resources that the web client already has. This can be controlled through numerous methods. One method is to choose to not push resources to returning users and therefore allow the returned users to utilise their cached assets. This is by far the easiest implementation. This can simply be done by checking the cache headers for the resources making sure that the headers do not overlap with the server push implementation.

Real-Life Tests under HTTP/2

Theoretical knowledge is always important for laying the foundation to understanding HTTP/2 and its benefits. Once the concepts are grasped and understood though it’s important to test these theories in order to measure the impact HTTP/2 can make to Page Speed.

Part 2 of this Page Speed series HTTP/2 In Real Life – using Website Tests & Analysis will discuss the true benefit of HTTP/2 in regard to Page Speed and value for SEO, so don’t miss out!

What about HTTP/3?

Although HTTP/3 demonstrates clear potential as the successor protocol to HTTP/2, it does not and should not signal the end of HTTP/2 for SEO’s across the web. As with every new major development to the worldwide web, it will go through a normal rollout phase and it will probably take time for a site to adopt the new protocol and before it becomes a de-facto standard within the SEO industry. HTTP/2 implementation still represents a beneficial and simple gain that when implemented correctly can help improve your site’s performance.