Someone might have noticed it in the reports of Google Pagespeed Insights, which since March began to use it for network requests, while Googlebot had already started to support it in its scans in November: let’s talk about the HTTP2 protocol, which is now used by half of all websites in the world. Here is an overview of HTTP2, to understand what it is, how it works, what are the pros and cons of its use and, not least, what may be its positive aspects for the SEO.

What is the HTTP2

HTTP/2 is a protocol to control communication between a browser that makes a request and the server that contains the requested information.

Officially standardized in 2015, it is an optimized expression of the semantics of the Hypertext Transfer Protocol, called HTTP, the protocol that has served the Web for over 20 years, of which it represents the evolution: according to the latest surveys of w3techs, HTTP2 is currently used by more than 50 percent of all sites, up from 42 percent in 2020.

In addition to ensuring a technical breakthrough over the previous generation, while maintaining maximum compatibility, the HTTP/2 protocol improves the loading of web pages on various browsers and offers great application simplicity to users, that do not have to make any particular changes to the site to apply this technology.

In particular, HTTP/2 allows a more efficient use of network resources and a reduced perception of latency, introducing the compression of the header field and allowing multiple simultaneous exchanges on the same connection; also introduces the unsolicited push of representations from servers to clients.

What is a protocol

To better understand the functioning of such a system it is also good to remember what is a protocol, using the help of Ruth Everett: essentially, protocol is the set of rules in place to manage the request between client and server. Typically it consists of three main parts: the header, payload and footer.

  1. The Header contains information such as the source and destination address of the page, as well as size and type details.
  2. The Payload is the actual information that will be transmitted.
  3. Finally, the Footer directs the request to the intended recipient and ensures that the data is free of errors when transmitted to the browser.

The technical features of the HTTP/2

HTTP/2 is based on the same syntax as HTTP/1, so this protocol is more an update than a complete migration; this was an intentional decision, to make the transition as smooth as possible.

These are some of the main technical features of this protocol:

  • Binary commands

HTTP/2 introduces a change to the transformation protocol, which goes from textual to binary to complete the request to the response cycles: the same tasks are performed, but using only binary commands 1 and 0 instead of text.

This simplifies the implementation of commands, which become easier to generate and analyze.

  • Multiplex

Multiplexing allows multiple requests to be made simultaneously on a single connection: in this way, the payload is divided into smaller sequences, analyzed and transmitted on a single connection and then reassembled before they reach the browser.

The main objective of this change was to solve problems related to resource-consuming requests and help prevent requests and responses from blocking others.

  • Compression of the header

Header compression is designed to reduce the overload provided with the slow boot mechanism in HTTP/1. As most websites are rich in graphics and content, client requests cause multiple header frames to be sent almost identical to the browser, which can cause latency and unnecessary consumption of already limited network resources.

The header compression mechanism offers the ability to compress a large number of redundant header frames and allows the server to maintain a list of headers used in previous requests; essentially, the headers will be encoded into a compressed block and sent along with the client.

  • Server Push

The server push mechanism allows you to insert resources that could be used in the cache of a browser before they are requested; they are sent, without waiting for the response of another client, also the information or resources that are expected to be present in future requests (based on previous requests).

This avoids the need for another round trip request and response and reduces the network latency that results from different resources used to load a page.

  • Priority in the flow

The Stream prioritization allows you to give preference to particular data streams, based on the dependencies and weight assigned to each.

In this way, the server can optimize the allocation of resources according to the requirements of the end user.


HTTP/2 support is only available via encrypted connections, and therefore requires HTTPS.

Unsurprisingly, the two protocols complement each other in many ways: they increase security for users and applications, but they also require fewer TLS handshakes and reduce resource consumption on both the client and server sides.

How HTTP requests work: the truck analogy

Everett’s article also gives a useful analogy to understand HTTP requests, using a truck as a reference.

Basically, a truck represents the request from the client to the server and the road traveled by the truck is the network connection; when the truck that carries the request from the browser reaches the server, it will load the response and return it to the browser.

The HTTPS protocol adds a layer of protection to these responses, to ensure that no one is able to look inside the truck to see what it contains, such as personal data or sensitive information.

The main problem is that the trucks that make the request cannot travel faster than the speed of light: they must also travel at a constant speed, regardless of how large the demand is and how far they have to travel to reach it.

In addition, it should also be considered that most websites require a sequence of many requests and answers to load a page: for example, even image files, CSS and/or Javascript may have their own dependencies, requiring multiple trips between the browser and the server.

When making requests via HTTP/1, every truck needs its own road or network request, and for certain requests must also be made new network requests; all this is added to the latency.

Typically, only six simultaneous connections can be made at a time, and other requests are forced to wait for network connections to be free. Cascade diagrams are a useful way to see this latency in action.

How things change with the HTTP/2 protocol

It is at this point that HTTP/2 can intervene and provide a positive impact on the behavior of requests.

For example, thanks to the multiplex function more trucks can run on a single road simultaneously, so the network connection is able to handle more requests and provide more answers faster.

The content of these requests and answers remains the same: they are only handled in a slightly different way.

Another useful feature of HTTP/2 is Server Push, which allows the server to respond to a request with multiple responses simultaneously. So, if for example we have to return CSS and Javascript files along with HTML, they can all be sent at the same time, instead of having to be delivered individually to the browser.

The benefits of HTTP2 protocollo for sites

Being an up-to-date technology, the adoption of HTTP/2 brings some benefits for sites.

The first is technical and practical: the update to HTTP2 is not a migration and does not require changes to Urls, but it is simply a change of protocol that does not require application efforts or special interventions.

Everett highlighted “four of the biggest SEO benefits”, a non-exhaustive list of the overall benefits of HTTP/2.

  1. Web performance

Many of the new HTTP/2 features have been designed to improve site performance and to help save the resources needed to scan sites.

For example, multiplexing means that requests and responses will not block each other, which helps reduce latency and, in turn, provides faster web performance.

The ability to send and receive more data per communication request is another practical example of performance benefits.

Moreover, prioritizing the flow allows effective use of resources, which reduces the time needed to provide content requests to the user.

  1. Mobile performance

In addition to overall web performance, mobile performance can also be improved with HTTP/2, which is designed in the context of today’s usage trends, which certainly favor mobile devices.

Multiplexing and header compression help in particular to reduce latency in accessing Web pages, and this also occurs on mobile networks, which can have a limited bandwidth.

In essence, HTTP/2 optimizes the web experience for mobile users in ways that were previously attributed only to desktop users, including through performance and security.

  1. Improved User Experience

Performance improvements also positively influence the user experience: it is easy to imagine that a fast-loading site leads to greater customer satisfaction and general brand favor.

As Google says, there is a 32% increase in the bounce rate if a page load goes from 1 second to 3 seconds, and HTTP/2 is just one way we can try to improve the loading speed.

  1. Greater security

Since HTTP/2 must be served over HTTPS, it ensures that all websites are encrypted and protected.

In addition, it also helps to ensure that the applications themselves are protected from any malicious attacks, which may result in manual penalties for the site or potentially have it removed entirely from search results.

Possible disadvantages

Next to these “pros”, even HTTP/2 brings some disadvantages to consider, as is the case with all technologies.

The first negative aspect reported by the article is that not all browsers still support HTTP/2. In fact, since 2015 most major browsers have added support for the new protocol, but it is good to make sure that the main browsers from which users access the site are supported.

This is however a limited problem, as the incompatibility mainly concerns obsolete versions of browsers, which have a low overall use, as revealed by the graph of the site

Supporto browser di HTTP2

Due to the server push function, there is a potential waste of bandwidth due to the data that can be sent to the browser but not actually used: “just because a page upload request may require a particular resource or another request may be expected, it does not always mean that it will,” says Everett, and this is likely to determine that “unnecessary resources can be sent to the browser”.

Also, because multiplexing can make the server “receive short bursts of a number of requests at once, it has the potential to overwhelm the servers, especially if they are not limited”. There may be slight delays and complications in debugging, due to the binary format used instead of the text format used in HTTP/1.

How to implement HTTP2 on site

The upgrade to HTTP/2 ultimately depends on our server: if, at the moment, we are not able to support HTTP/2, you need to talk to the server administrator or the hosting provider.

Instead, if the server is able to support HTTP/2, it may automatically serve the content via the new protocol. We can ensure “that the server is able to support it using a CDN that also supports HTTP/2 and has an updated HTTPS certificate”; moreover, we can check whether the server is able to support HTTP/2 using the site, which informs about the server’s functionality with respect to HTTP/2, ALPN and Server-push support. Another useful tool is Chrome Dev Tools, which lets you check what resources are currently served on HTTP/2.

Google and HTTP2

As anticipated, since mid-November 2020 Google has started scanning sites on HTTP/2 and already in May, as revealed by John Mueller, Googlebot is scanning more than half of all Urls with the new protocol.

In addition, since March 2021 even the PageSpeed Insights tool uses HTTP/2 to make network requests, if the server supports it; if a site is on HTTP/2, as a result you may see your Pagespeed Insights scores increase – but that does not mean an increase in rankings, let’s be clear.

Previously, all requests were made with HTTP/1.1 due to constraints in the connectivity infrastructure; with this improvement, it is more likely that there is “greater similarity among results of Lighthouse from PSI and Lighthouse CLI and Devtools (who have always made requests with h2)”, although “consistency between environments is almost impossible“, explain from Google.

It is worth noting that it is not possible to “force” Googlebot to scan our site on HTTP/2: if the site supports it, it will automatically be eligible to be scanned with the protocol, but for the moment Google will only do so if it considers it beneficial in terms of saving resources).

HTTP2 and advantages for the SEO

All the positive aspects of this protocol, combined together, can also have a positive impact on the SEO.

We reiterate that there is no direct increase in the ranking resulting from the use of HTTP2, as confirmed several times by Google, but in any case, the performance and UX increments can still help to achieve the objectives set by the Page Experience Update party last June 15, as well as affecting, in some way, the visibility of a site in Google Search and conversions.

Then there is another interesting aspect, revealed by John Mueller in an intervention at Google I/O 2021 and reported by Seroundtable, because scanning in HTTP2 could improve the budget crawl, ie “a mix of how many Urls Google wants to scan from your website – the scanning request (crawl demand) and how many of your Urls our systems think your server can handle without problems – the crawl capacity”.

With HTTP/2 scanning, Mueller explains, this becomes a bit more complicated “because a single connection can include multiple Urls“; overall, however, Google thinks “that HTTP/2 scanning gives our systems the ability to request multiple Urls with a similar load on your servers“.

However, the decision to scan with HTTP/2 “is based on the fact that the server supports it and that our systems determine a possible increase in efficiency“; this means that Googlebot “will not need to spend as much time scanning your server as before”, and that in general the new protocol, with its features, brings improvements that help both the Google scan and the service infrastructure of the website.