The web never remains static in its progress. Consumer behaviour changes as new technologies are produced, and the internet's basic infrastructure is obliged to adapt.
The HTTP protocol, which is used to convey data between client and server, has gone through several versions, each of which has added new and interesting capabilities to the fundamental functionality. After an 18-year gap between the introduction of HTTP/1.1 in 1997 and HTTP/2 in 2015, development has accelerated, with a draught proposal for HTTP/3 being presented just three years later.
HTTP/3 is, at its heart, a rewrite of the underlying transport layer that handles file transfers.
It signifies a shift between TCP (Transmission Control Protocol) to UDP (User Datagram Protocol), which addresses various TCP restrictions while also boosting user performance and security. 73 percent of web browsers now support the protocol, which is still awaiting final evaluation before being published. This figure will skyrocket once Safari makes it a standard feature; it's now experimental and must be activated through the developer menu.
Google and Facebook are among the 25 percent of the top 10 million websites that employ the HTTP/3 protocol.
In reality, you're already using the protocol to some extent if you're using Google Analytics, Tag Manager, or Fonts.
To properly appreciate the benefits of HTTP/3, it's necessary first to understand how HTTP/1.1 functioned and the issues that HTTP/2 was created to address.
When files (HTML, JS, CSS, pictures, and so on) are transferred, the data is split down into manageable, individual packets and transmitted over time.
The number of concurrent connections possible in browsers is limited, causing a bottleneck and delaying loading speeds. This necessitated many performance-enhancing solutions, such as domain sharding and picture sprites.
HTTP/2 solves the problem of connection restrictions by adding multiplexing, which allows several files to be sent over a single connection.
The addition of greater header compression, as well as a few other enhancements that have proven less successful in reality, was the second big upgrade.
However, these improvements did not solve all of the TCP protocol's issues.
TCP sends packets in chronological order, so if one is lost, the entire connection is halted until the packet is received correctly. Some of the advantages of multiplexing are negated by this phenomenon, known as the head of line blocking.
HTTP/1.1 was created with the intention of giving each file its own connection. However, more files were required to load each page as websites got more sophisticated. Another issue with TCP is that it is completely separate from the TLS protocol. Because websites may be both secure and vulnerable, this is by design.
As a result, before transferring data, a server and client typically make many round trips to establish a connection.
HTTP/3 provides three primary improvements that distinguish it from HTTP/1.1 and HTTP/2 by switching from TCP to UDP.
By offering distinct byte streams for each file, HTTP/3 eliminates head-of-line blocking. The data for a single stream is halted while the lost packet is reissued rather than the real connection. The core idea is that HTTP/1.1 causes several vehicles to queue up to travel down the same route (connection).
HTTP/2, on the other hand, allows numerous trucks to share the same lane at the same time. Unfortunately, if a truck stalls on TCP, the entire route is closed until the truck resumes its journey. The other trucks may just drive around it using HTTP/3 and UDP.
Rather than having two separate protocols working separately, TLS 1.3 is integrated into HTTP/3, requiring only a single handshake, decreasing the number of roundtrips from 2 (or 3 if using TLS 1.2) to one. Users will benefit from speedier – and more secured – connections as a result of this improvement. Because TLS and UDP are so tightly linked, HTTP/3 can only be utilised on a secure site as a result of this modification. This wasn't the case with HTTP/2, which may potentially be utilised on an unsecured site despite the fact that none of the main browsers supports it.
HTTP/3 utilises connection IDs instead of IP addresses to route packets. As a result, it can manage network changes this way without having to re-establish a connection.
In a mobile-first environment, where users often switch between wifi and cellular networks for speed and connection reliability, this is extremely beneficial. Returning to our truck scenario, this is the equivalent of arriving at a traffic light and having to queue again before proceeding to the next route. There is a slip-road with HTTP/3 that allows you to switch between the two effortlessly.
Although HTTP/3 provides some evident speed improvements, critics have pointed up some drawbacks. First, users with fast connections will receive minimal benefits from the protocol, with the slowest 1% to 10% of users benefiting the most. However, in terms of Core Web Vitals, this may be really advantageous. Because CWV scores are worldwide, it's completely conceivable for a small group of people in a remote geographic region to lower them. In a mobile-first environment, even consumers with fast devices and near geographical proximity might have brief network difficulties, which can negatively impact CWV. The more mobile your consumers are, the more likely this is to have an impact. Another gripe is that upgrading to HTTP/3 necessitates a significant server update since the transport layer is substantially altered.
Additionally, using UDP increases CPU needs, potentially putting greater strain on servers. Both arguments are valid. However, CPU use is being optimised right now. Furthermore, as we'll see in the following subsection below, many CDN suppliers already offer basic HTTP/3 solutions that may be implemented at the edge.
While Googlebot has accepted HTTP/2 since November 2020, and HTTP/2 accounting for 50% of all URLs scanned, it does not presently support HTTP/3.
HTTP/2 is only utilised when there is a demonstrable advantage, such as when adopting HTTP/2 will save both servers and Googlebot considerable amounts of resources. This will probably increase with time, but considering the five-year delay between the release of the HTTP/2 standard and Googlebot support, HTTP/3 is still a long way off. However, adding HTTP/3 might have an indirect SEO benefit if it improves Core Web Vitals ratings. Upgrading your server architecture to handle HTTP/3 – or, for that matter, HTTP/2 – is only one of many possible improvements you can make to make your website as fast as feasible.
The advantages of having a fast website, such as lower bounce rates, longer stay on site, and greater conversion rates, go beyond SEO. You may monitor Googlebot queries in your server access logs or search for a notice in GSC to discover what protocol Googlebot is using to scan a site. While forms vary, the protocol is usually included between quote marks in the HTTP request, along with the request method as well as the URL path.
If you're not sure whether a website supports HTTP/3, you may use an internet tool like https://http3check.net/ to find out. Alternatively, the protocol per request is displayed in the dev tools network tab in both Chrome and Firefox. These fields are hidden by default, but they may be seen by right-clicking on the menu bar and selecting "Protocol." "h3" stands for HTTP/3 requests. You may also use curl and the command line to check.
HTTP/3 is yet another big step forward for the web, providing a much-needed speed boost to let it continue to evolve.
As SEO and digital marketing experts, we should be aware of the protocol's benefits ahead of its upcoming release so that we may begin advocating it and allowing our clients to profit for years to come.
