A Beginner’s Guide to HTTP/2 and its Importance

Everyone understands the importance of improving the speed of your website, and HTTP/2 provides a great opportunity to do exactly that. As a relatively new opportunity, it is a great way to beat your competition and start improving the experience of your users today.

If you’re new to HTTP/2, don’t worry. We will run through what HTTP/2 is and how it allows web pages to load far more quickly in comparison to those using HTTP/1.1. It’s one of the biggest changes to the Internet made to date and should be of interest to anyone concerned with user experience.

What is a Protocol?

The HTTP/2 vs HTTP1 debate must proceed with a short primer on the term Protocol frequently used in this resource. A protocol is a set of rules that govern the data communication mechanisms between clients (for example web browsers used by internet users to request information) and servers (the machines containing the requested information).

Protocols usually consist of three main parts: Header, Payload and Footer. The Header placed before the Payload contains information such as source and destination addresses as well as other details (such as size and type) regarding the Payload. The payload is the actual information transmitted using the protocol. The Footer follows the Payload and works as a control field to route client-server requests to the intended recipients along with the Header to ensure the Payload data is transmitted free of errors.

What is HTTP/2?

HTTP/2 is a newish protocol for transporting data that will drastically speed up the web and can help your SEO. The ‘old’ HTTP1.1 protocol only allows web servers to send files down a single line one at a time, and that line has to open and close after each file has been sent — a process that can take ages. HTTP/2 offers a dramatic speed boost as the line can be kept open and a lot of stuff can be sent at once. This post covers how HTTP/2 works, why it’s good for your SEO and how to implement it on your website.

HTTP/2 uses new technologies to take away one of the web’s biggest bottlenecks by introducing full multiplexing connections. Servers can now open a single connection with a browser and keep sending all a website’s files until everything is done. After that, the connection closes and the browser can render the site.

In February 2015, the Internet Engineering Task Force (IETF) HTTP Working Group revised HTTP and developed the second major version of the application protocol in the form of HTTP/2.

Main goals of developing HTTP/2 is:

• Protocol negotiation mechanism — protocol electing, eg. HTTP/1.1, HTTP/2 or other.
• High-level compatibility with HTTP/1.1 — methods, status codes, URIs and header fields.
• Page load speed improvements trough
• Compression of request headers, to reduce overhead.
• Binary protocol
• HTTP/2 Server Push, Push request proactively into client caches instead of waiting for a new request for each resource.
• Request multiplexing over a single TCP connection
• Request pipelining
• HOL blocking (head-of-line) — Package blocking

1.Request multiplexing:

HTTP/2 can send multiple requests for data in parallel over a single TCP connection. This is the most advanced feature of the HTTP/2 protocol because it allows you to download web files asynchronously from one server. Most modern browsers limit TCP connections to one server.

This reduces the additional round trip time (RTT), making your website load faster without any optimization, and makes domain sharding unnecessary.

2.Stateful Header Compression

HTTP/2 compress a large number of redundant header frames. It uses the HPACK specification as a simple and secure approach to header compression. Both client and server maintain a list of headers used in previous client-server requests.

HPACK compresses the individual value of each header before it is transferred to the server, which then looks up the encoded information in a list of previously transferred header values to reconstruct the full header information.

3.Binary protocol

The latest HTTP version has evolved significantly in terms of capabilities and attributes such as transforming from a text protocol to a binary protocol. HTTP1.x used to process text commands to complete request-response cycles. HTTP/2 will use binary commands (in 1s and 0s) to execute the same tasks. This attribute eases complications with framing and simplifies the implementation of commands that were confusingly intermixed due to commands containing text and optional spaces.

Browsers using HTTP/2 implementation will convert the same text commands into binary before transmitting it over the network.

Benefits:

• Low overhead in parsing data — a critical value proposition in HTTP/2 vs HTTP1.
• Less prone to errors.
• Lighter network footprint.
• Effective network resource utilization.
• Eliminating security concerns associated with the textual nature of HTTP1.x such as response splitting attacks.
• Enables other capabilities of the HTTP/2 including compression, multiplexing, prioritization, flow control and effective handling of TLS.
• Compact representation of commands for easier processing and implementation.
• Efficient and robust in terms of processing of data between client and server.
• Reduced network latency and improved throughput.

4.HTTP/2 Server Push

This capability allows the server to send additional cacheable information to the client that isn’t requested but is anticipated in future requests. For example, if the client requests for the resource X and it is understood that the resource Y is referenced with the requested file, the server can choose to push Y along with X instead of waiting for an appropriate client request.

Benefits:

• The client saves pushed resources in the cache.
• The client can reuse these cached resources across different pages.
• The server can multiplex pushed resources along with originally requested information within the same TCP connection.
• The server can prioritize pushed resources — a key performance differentiator in HTTP/2 vs HTTP1.
• The client can decline pushed resources to maintain an effective repository of cached resources or disable Server Push entirely.
• The client can also limit the number of pushed streams multiplexed concurrently.

Similar Push capabilities are already available with suboptimal techniques such as Inlining to Push server responses, whereas Server Push presents a protocol-level solution to avoid complexities with optimization hacks secondary to the baseline capabilities of the application protocol itself.

The HTTP/2 multiplexes and prioritizes the pushed data stream to ensure better transmission performance as seen with other request-response data streams. As a built-in security mechanism, the server must be authorized to Push the resources beforehand.

The Main Benefits of HTTP/2

If you remember the typical story about a guest in a restaurant and waiter, that would be an example for HTTP/1.1 and HTTP/2 protocol with a slight difference.

Imagine that waiters are TCP connections and you want to order your meal and a bottle of water. For HTTP/1.1 that would mean that you ask one waiter for your meal and another one for water, hence you would allocate two TCP connections. For HTTP/2 that would mean that you ask only one waiter for both, but he brings them separately. You only allocate one TCP connection and that will already result with lower server load, plus the server would have one extra free connection (waiter) for the next client (guest).

The real difference between HTTP/1.1 and HTTP/2 comes with server push example. Imagine that the guest (Client) asks (sends request) a waiter (Server) for a meal, then the waiter gets the meal from the restaurant chef (your application logic), but the waiter also thinks you would need a bottle of water so he brings that too with your meal. The end result of this would be only one TCP connection and only one request that will significantly lower the server load.

As a simple showcase of those mechanics, I made a simple page example.

What we have here is a simple page with 100 images of checks which I’ll use to demonstrate HTTP/1.1, HTTP/2 AND HTTP/2 server push.

What is important to note in the picture above are number of requests, load time, protocol column, initiator column and waterfall diagram itself (we can see how requests are made through multiple batches, unfortunately, it is hard to see other data from it except TTFB and content download time; eg. resource scheduling and connection start time).

For HTTP/1.1:

Number of requests: 102

Load time: 12.97s

Protocol: “http/1.1”

Initiator column: Initiator of the first one is user/client and the rest of the requests are initiated by the response to a client who realizes he needs some other resources (in this case, images).

Waterfall diagram: We can see how requests are made through multiple batches (TCP connections).

For HTTP/2:

Number of requests: 102

Load time: 11.19s

Protocol: “h2” (HTTP/2)

Initiator column: Initiator of the first one is user/client and the rest of the requests are initiated by a response to a client who realizes he needs some other resources (in this case, images).

Waterfall diagram: We can see how requests are made through 2 batches (TCP connections).

Take note of the load time. In this case, it is a bit lower than the load time of HTTP/1.1 example but it doesn’t have to be always. This example shows the multiplexing of client requests.

HTTP/2 server push:

Number of requests: 102

Load time: 3.17 s

Protocol: “h2” (HTTP/2)

Initiator column: Initiator of the first one is user/client and the rest of requests are initiated by the push of the server (virtually one request/response cycle).

Waterfall diagram: We can see how requests are made through 1 batch (1 TCP connection).

Drawbacks of HTTP/2:

Nonetheless, there are also some limitations businesses should take into account before switching to the new protocol.

• Be aware of your audience: Although 75% of UK users are using browsers that can take advantage of the protocol, a number of people continue to use older browsers which don’t. Additionally, not all web servers out there support HTTP/2. Therefore, current page speed optimisation techniques will remain necessary.
• HTTPS Prerequisite: Switching from HTTP/1.1 will be more difficult if a site isn’t already using HTTPS. since HTTP/2 has the prerequisite of the site already being on HTTPS. Migrating a website to HTTPS will need some work, requiring all HTTP URLs to be redirected to the HTTPS secure version of the protocol. However, HTTPS is a positive ranking factor for Google and, since security is a top priority for the search engine, we expect them to apply more weight to this signal in the future. Therefore, it would be a good idea to upgrade your site as and when you can.
• Performance impact could be minimal: Switching from HTTP/1.1 to HTTP/2 could take a lot of time and resources so it’s important to be sure that the impact in site speed worth it. If a website is already well-optimised for speed, the performance improvements might be smaller than expected.
• HTTP/2 Unknowns: The protocol is still relatively new; a lot of studies will have to be conducted in order to determine best practices and possible pitfalls.
• Browser Compatibility:

Most of the modern browser fully supports HTTP/2 protocol with an exception (red) of Opera mini (all versions) and UC Browser for Android. There are also the ones that have partial support (light green) like IE11.

You can find more details on browser support on this link

Use HTTP/2 and speed up your site

HTTP/2 provides us with many new mechanics that will mitigate HTTP/1.1 issues and ones that will boost your web page performance. Currently, it is widely supported by web clients so its implementation is painless. Although the implementation of HTTP/2 protocol is easy you should have in mind that with it you will probably have to change the mechanics (like serving assets to the client) to use the full potential of this protocol.

HTTP/2 is the biggest, most innovative change to the protocol family since 1999. 🤘

Conclusion

As search engines and consumers constantly demand faster experiences, the opportunity of HTTP/2 should be of great interest to brands looking to gain competitive advantage. It’s one of the biggest changes to the Internet to date, and now is the right time to start evaluating whether this is right for your business.

Googlebot does not currently request URLs over the HTTP/2 protocol itself yet, but you don’t need to wait to start getting the advantage. Pages will load faster for your users, which makes them happy, and through search engines leveraging user signals, this will lead to improved SEO performance.