Savvy / Blog / Performance / Speed and Optimization in the Era of HTTP/2

Speed and Optimization in the Era of HTTP/2

By Roee Yossef

Published on Aug 17, 2023

No Comments

HTTP protocol has existed since around 1991 and received a significant upgrade in 1999 when HTTP/1.1 came into existence. Since the release of this protocol, many articles and guides have been published online to explain how to identify and attempt to address the shortcomings of this protocol in terms of performance, and there are quite a few limitations…

Websites like GTmetrix and WebPageTest, especially as you can read in this guide I wrote, are undoubtedly those that provide the final word in everything related to testing website loading speed, and in most cases, these are excellent tools. However, some of the recommendations you receive from these tools are not relevant to the era of HTTP/2.

So, What is HTTP/2 and What’s New in This Protocol?

HTTP/2 is a network protocol, an heir to the HTTP1.1 protocol. It was originally called HTTP2.0 and according to W3Techs, around 42.4% out of the top 10 million websites use this protocol as of December 2019.

Let’s present the innovations in the protocol and see how they manifest across websites in terms of performance improvement:

A. Multiplexing

Undoubtedly, this is the most significant feature in HTTP/2 that provides a solution to one of the central problems (head-of-line blocking) present in the HTTP/1.1 protocol. To briefly describe the issue, during a certain time, only one request can be received for a specific connection (TCP Connection), which leads to a lot of delays.

In other words, a request for an additional asset can only occur after a response for the current asset has been received, creating a kind of “queue” of assets that the browser needs to download from the server.

In an attempt to circumvent this obstacle, browsers try to open multiple connections, allowing them to download several assets in parallel. However, browsers are limited in the number of connections they can open simultaneously. This usually ranges between 2-8 connections, depending on the browser, in order not to flood the network with traffic.

It occurs to me (at this moment) that opening a new connection by the browser causes latency, especially when the connection is HTTPS.

Multiplexing solves these issues by allowing a large number of requests (and responses) over a single TCP connection. This capability enables the browser to start downloading assets as soon as it finds them in the DOM, without waiting for a free TCP connection.

Latency is also lower because the handshaking process that occurs when opening a new TCP connection is performed only once for a specific host or domain.

You can see the impact that multiplexing has in the images below. The HTTP/1.1 protocol starts downloading assets only when it has a free TCP connection:

In contrast, HTTP2 downloads these assets in parallel:

B. HPACK Header Compression

For every HTTP request, there’s a Header that allows the server and browser to add additional information to the request or response. A typical response from https://savvy.co.il would return the following header:

accept-ranges:bytes
cache-control:max-age=31536000, public
content-length:37534
content-type:image/jpeg
date:Sat, 21 Oct 2017 09:12:12 GMT
expires:Sun, 21 Oct 2018 09:12:12 GMT
last-modified:Sat, 30 Sep 2017 15:42:50 GMT
pragma:public
server:Apache
status:200
x-xss-protection:1; mode=block

Headers can contain additional information such as cookies or referrers, which can cause the header to be even larger. Assuming in the second request, the header only contains additional information, the difference between them would be:

:path: /logo.png
referer: https://savvy.co.il/lp/index.html

So, unlike HTTP1.1 where many assets contain the same header, it’s inefficient to send the full information again and again with each request.

The HTTP/2 protocol uses an index that stores the headers received from the first request it handles. Then, only the index of that same header is sent (or the difference), thus saving unnecessary data transmission, especially on websites with many assets.

C. Server Push

In simple terms – when a browser sends a request for a specific page, the server returns HTML as a response. Then, the server waits for the browser to parse the HTML and make requests for the remaining assets (CSS, JS, & Images) before sending them to the browser. Server Push allows avoiding this by automatically sending the assets it anticipates the browser will request.

For example, when there’s a request for a specific page, it’s reasonable to assume that this page will request a certain Stylesheet sooner or later. With Server Push, the server can send that Stylesheet even before it’s requested, avoiding the waiting time.

Unlike other features of HTTP/2, this feature requires thought and configuration before implementing it. If not implemented properly, it might even lead to a decrease in site performance.

HTTP/2 Works Only with HTTPS

If it hasn’t been stated yet – in order to use HTTP/2, your website must have an SSL certificate and run on HTTPS. While the HTTP/2 specifications do not explicitly state that HTTPS is mandatory, there’s no browser that uses this protocol when the

However, despite the cheaper costs of HTTP/2 requests, you can see performance improvement through greater logical consolidation, meaning:

styles/main.css
styles/blog.css

compared to delivering each module separately:

styles/header.css
styles/sidebar.css
styles/footer.css
styles/blog.css

2. Image Sprites

Similar to file consolidation, there’s no longer a need to combine images into one image and display each image by changing the background-position in CSS (a very tiresome process, I must say).
In this context, you should exclude SVG files from the equation since a single SVG file can achieve better compression results. Each case needs to be examined thoroughly in this situation…

3. Inlining

One method to reduce the number of HTTP requests is inlining. This is especially useful for small images that can be converted into data-URIs and loaded by the browser without making an additional request to the server.
The problem with this technique is that assets of this type aren’t cached by the browser, so they need to be re-downloaded with each page load as part of the page’s code.

4. Domain Sharding

Domain Sharding is a technique used before the era of HTTP/2 that aimed to make the browser “work” in a way that allows us to load more assets in parallel. For instance, as explained earlier, if you serve assets from your server, the browser can download 2-8 files simultaneously (due to TCP limitations).
On the other hand, if you distribute assets among three different domains, the browser can download 6-24 files in parallel (three times as many). That’s why it’s common to see assets and assets linked and loaded from multiple domains:

cdn1.domain.com
cdn2.domain.com
cdn3.domain.com

This situation should be avoided when using HTTP/2 since in this scenario, the multiplexing feature won’t fully utilize its potential.

To Sum Up

Not only is browsing in our time much faster and secure due to the adoption of HTTP/2, but it’s also much easier for developers and site owners to perform optimizations and improve loading speed, as well as site security.
There are no downsides to transitioning to HTTP/2; all major browsers in the market have supported this protocol for a long time, and those who don’t simply fall back to HTTP/1.1.

WordPress sites that serve a large number of assets and work with HTTP/2 will experience significant improvements in their site performance. Furthermore, these site owners no longer need to worry about file consolidation, spreading assets across different domains, and tasks like creating image sprites.

For further reading: