What is HTTP/2?

HTTP/2 is the latest evolution of the Hypertext Transfer Protocol (HTTP). HTTP is the network protocol used to request and receive pages and data on the World Wide Web. The new technology will eventually supersede HTTP/1.1 which was standardized more than two decades ago.

This article is part of a series created in partnership with SiteGround. Thank you for supporting the partners who make SitePoint possible.

How Does HTTP/2 Differ from HTTP/1.1?

Perhaps HTTP/2 is better understood as its original name: HTTP/2.0. It has its roots in the SPDY (pronounced speedy) protocol devised by Google in 2009.

HTTP/1.1 has several issues. It was created at a time when web pages rarely exceeded 100Kb, CSS was not available and, while JavaScript had been introduced, it was rarely used for anything more than basic form validation or simple effects. High bandwidth, Ajax-powered, Single-Page Applications and client-side frameworks were many years away. No one could envisage pages making more than a few requests.

HTTP/2’s main objectives were to reduce latency. It gets a little technical but efficiencies were achieved using several techniques…

1. HTTP/2 is Binary Data

HTTP/1.1 uses textual data which is generally less efficient across a network.

2. HTTP/2 Headers are Compressed

Information sent with a request describes the data, its origin, type, length, how long it can be cached, etc. Unlike HTTP/1.1, this is now compressed in HTTP/2.

3. HTTP/2 Uses Pipelining

In HTTP/1.1, the server must send responses in the same order the requests were received. HTTP/2 is asynchronous so smaller or faster responses can be handled sooner.

4. HTTP/2 is Multiplexed

In HTTP/1.1, only one request can be handled on a TCP connection at any time. Browsers typically open between four and eight connections but large or slow assets can cause the download of other files to be delayed. HTTP/2 permits multiple request and response messages on the same (single) connection at the same time.

5. HTTP/2 Implements Server Push

The server can send assets before they are requested. For example, you may reference a script at the bottom of your web page. In HTTP/1.1, the browser will download the HTML, parse it, then load the JavaScript file when its <script> tag is encountered. An HTTP/2 server can push the JavaScript file to the browser before it knows it’s required.

Is HTTP/2 Noticeably Better?

Results will differ from system to system but the HTTP/1.1 vs HTTP/2 with HTTPS test tool typically reports HTTP/2 being 10x faster despite occurring over a secure connection.

Can HTTP/2 Be Used Today?

Yes. However, HTTP/2 is only enabled when both the web server and the browser support the protocol. The connection will normally fall back to HTTP/1.1 when either end fails. At the end of 2016, almost 11% of the top ten million websites supported HTTP/2. All recent versions of Firefox, Safari, Edge, Chrome and the other Blink-based browsers support the protocol.

You can test whether your host has enabled HTTP/2 by entering your website’s URL into the HTTP/2 Test tool provided by keycdn.com.

If you’re using managed or shared hosting, your host might need to enable HTTP/2. Some may make it an option that you can switch on or off, so contact them directly if you are unsure.

Ideally, it’s best to use a web host that enables HTTP/2 by default, like our hosting partner SiteGround. They support HTTP/2 on all servers with no need for further action. Additionally, they have free Let’s Encrypt SSL certificates — these are a must when using HTTP/2 because most browsers support HTTP/2 only if it’s encrypted.

If you’re running your own dedicated or virtual server, HTTP/2 will need to be enabled for whichever web server you are using. Most support the protocol directly or have installable modules. That includes Apache, nginx, LiteSpeed, Microsoft IIS and Node.js/Express but note that features can differ. For example, nginx does not support HTTP/2 Server Push at the time of writing. Consult your documentation for further information.

Do I Need to Update My Website?

No — HTTP/2 is backward-compatible with HTTP/1.1. However, some of the good development practises you use today may become anti-patterns in a more efficient HTTP/2 world.

You are possibly using a build system or manual processes to:

• convert many images into a single-image sprite
• inline images in the HTML page or CSS files
• concatenating and minifying CSS and JavaScript into single files.

Reducing the number of requests is good for HTTP/1.1 connections but numerous HTTP/2 requests are considerably less expensive. It is possibly better to deliver multiple files because, if one changes, you need only send the update.

You may also be moving assets to different domains or CDNs to permit more open HTTP/1.1 connections. This is not necessary for HTTP/2 because you can make as many requests as you need on a single connection. It’s possible that separate domains could harm performance owing to the additional DNS look-ups and TCP connections which need to be opened.

That said, I recommend a pragmatic approach. Concatenation will rarely be a problem unless you’re merging large source files which are prone to regular changes. Retain your build processes unless you can prove a large proportion of your users can use HTTP/2 and multiple files or single domains offer a significant performance boost.