HTTP/2 is the new standard transfer protocol online. It can make websites faster, more secure, and use fewer network resources.
But should you make the switch to HTTP/2? What are the considerations? Or if you’ve already switched, why aren’t you seeing speed improvements?
The Internet has its name because it is a network at heart. Computer networks preceded the Internet, but it was only when the network became standardized and computers were able to communicate with each other in a consistent way that the Internet as we know it came to be.
That communication is where HTTP comes in. HTTP stands for HyperText Transfer Protocol. HTTP allows the transfer of information online by creating a set of rules that are followed by browsers and websites for communicating that information reliably every time. HTTP is the backbone of the Internet. HTTP/2 is the newest version of that backbone, replacing HTTP1.x.
It’s important to note that HTTP/2 is backwards-compatible with HTTP1.x, so most configurations on a site do not need to change when upgrading to HTTP/2, including methods, status codes, and more.
HTTP/2 introduced new protocols that make the transfer of information online more efficient, including:
In HTTP1.x, when a browser establishes a TCP connection to a website’s server, only one resource can download per connection. Multiplexing solved this problem in HTTP/2. Multiplexing allows multiple resource threads to be established per TCP connection, meaning that multiple resource can download concurrently with fewer calls to the server. Reducing the number of calls speeds up the total Round-Trip Time (RTT) per webpage download.
When requests to the server are made, header compression requires less data to transfer the same information in a request, further decreasing download times.
Resource prioritization doesn’t exist in HTTP1.x. A browser might request files in an order that doesn’t make sense in the context of building a webpage. With HTTP/2, the browser can send information about which resources are most needed on the page. Additionally, if requests are out of order, the server can respond and send back the files in an order that makes sense.
Finally, server push allows the server to identify critical files and send them along the wire before a browser even requests them. For instance, as soon as the base file for a webpage is requested, the server could identify critical styling files and send them before the browser realizes it needs them. In HTTP1.x, the server had to wait for the browser to request each resource.
HTTP/2 also has a couple of new properties over HTTP1.x that give it an advantage. Its binary layer reduces the data size of each transfer. And because most browsers require sites to have a TLS certificate in place for HTTP/2 to work, it is more secure than HTTP1.x.
It’s necessary to understand how HTTP/2 fits into the context of your current site configuration.
Your site may be using a couple of workarounds that existed in HTTP1.x to speed up pages, particularly concatenation and domain sharding. You probably also have some third party content loading on your pages with scripts, which is commonplace on the modern Web.
Concatenation, domain sharding, and third party scripts can all affect your site’s efficiency.
Concatenated files contain multiple pieces of content you might need on a site. The multiple requests that would occur to call each of these pieces of content are collapsed into just one. An example would be a sprite file containing a set of icons used on multiple pages.
In HTTP1.x, reducing the number of requests can speed up the page, but due to multiplexing in HTTP/2, concatenated files are not usually needed – this is good news since concatenated files are difficult to maintain.
While sprites might still be useful in the right context, they can also slow download times if the file changes frequently due to the content not being cached, or if the file contains unnecessary information that makes it larger.
Domain sharding is a method used to get around the maximum number of requests from a domain on HTTP1.x – typically two. As you might have guessed, many sites still request a large amount of content from an origin domain. Domain sharding splits that origin using alternate domains or subdomains, tricking the browser into establishing more than two connections at a time in order to request content faster.
In HTTP/2, the maximum number of requests from a domain at any given time is larger, and multiplexing allows more content to download simultaneously, largely reducing the need for domain sharding. While domain sharding can still be used successfully in HTTP/2 depending on the amount of content coming from a single source, splitting content across multiple domains or subdomains eliminates the benefits of resource prioritization.
On many websites today, third party scripts are placed into webpages to call external content. These scripts are powerful – they can do almost anything, from rendering the page based on the end-user’s browser and device type to loading in search engines, to tracking performance of your site.
However, each of these scripts that provide external services use their own network configurations. That means that even if your site switches to HTTP/2, your third-party services may not have made the switch. Aside from other considerations surrounding third-party content on your site, service providers that still use HTTP1.x can affect download times, block your content from loading on a page, and overall reduce the benefit of switching to HTTP/2.
Should you switch to HTTP/2? Absolutely. But try to think about what it means in the context of your current site configuration, and also in the broader context of third-party services you may be using.
If your site uses concatenation or domain sharding, the performance benefits might be reduced. Also, depending on the number of external scripts on your pages, a good portion of your content is outside of your control and may be loading via HTTP1.x. However, if your site is configured in a way that makes sense with HTTP/2, the new protocol can make the experience significantly faster for your end-users.