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:
- How will this directly impact search engine optimisation and/or page speed?
- Can a recommendation be made off of the insight?
- 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/2 was designed to target three main areas of improvement to alleviate the issues discussed above:
- High Performance
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:
- Server Push
- Stream Prioritisation
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)
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 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 page (let’s say in this case index.html) server push can “push” the CSS to the user right after beginning to send response to index.html.
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 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)
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 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.
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:
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:
- It’s important to make certain that HTTPS is enabled.
- Utilise a TLS certificate from an authenticated authority and activate and install the certificate.
- 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.