For the uninitiated, the Hyper Text Transfer Protocol (HTTP) is the foundational application protocol. It facilitates the communication of data on the world wide web. Initially it was devised by Tim Berners-Lee with the advent of the internet. The first version of the HTTP was launched in 1991 and employed a basic model of client and server. The client represents the machine (and its user) requesting information. The server is the machine storing and sending that information.

Over the years, the HTTP has undergone incremental revisions geared towards improving its performance, with the 1997 version of HTTP/1.1 having enjoyed widespread use and experienced few improvements for over 15 years. However, the rapid development of the internet in recent times has seen a plethora of media-rich websites springing up all over the globe, while end users are demanding a consistently high-performance experience. These factors have meant that HTTP/1.1 has become increasingly unfit for purpose. This has prompted Google to develop their SPDY model as a more efficient alternative.

This SPDY protocol has become the basis for HTTP/2. With the core designers of the former having been involved in the development of the latter from the outset. Now that HTTP/2 is being gradually adopted on a widespread basis, support for SPDY is being withdrawn and although HTTP/2 is intended as an extension rather than a replacement for HTTP/1.1, it’s inevitable that it will represent the future of data communication online in the coming years. But how does it differ? And what are the advantages of HTTP/2 over its predecessor? Read on to find out.

The main differences between HTTP/2 and HTTP/1.1

Ensuring an optimal user experience is the main goal of upgrading the HTTP. Its success depends largely on three factors. A simple model, a fast and efficient service and a robust and reliable protocol that is impervious to security hacks and downtime. HTTP/1.1, although a sturdy option for many years, is ill-equipped to deal with the colossal amounts of traffic. Along with data requests and end users in the modern internet environment.

For this reason, the creators of HTTP/2 have seen fit to incorporate a number of feature upgrades. All designed to streamline operations and optimise the protocol’s performance going forwards. These feature upgrades include:

Multiplexed streaming

The messages sent between client and server (requesting and delivering information, respectively) are known as data streams. Previous incarnations of HTTP were only capable of sending one stream at a time, often with an inefficient lag between the transmission of each stream.

HTTP/2 has circumnavigated this problem by chopping up the payload of streams into smaller, more manageable chunks and adopting a binary frame of transmission to allow the streams to be sent from one entity to the other piecemeal, before being reconfigured at the other side.

This means that individual streams do not block one another or jostle for position, which optimises the use of network resources, reduces downtime, increases web speeds and facilitates improved search engine results.

HTTP/2 server push

Initially developed by Google’s SPDY protocol, this feature endows the server with capability to anticipate future data requests (based upon current or previous ones) and send along extraneous information that was not yet requested (but which is likely to be requested in the future) with the initial stream.

This “pushed” information can then be stored in the client’s cache until such time as it is required. When that time arrives, it can be far more efficiently extracted, saving another round trip to and from the server. This saves both time and network resources, resulting in improved user experience across the board.

What’s more, there is the potential for the system to recognise which pushed resources are never requested. Thus, through machine learning, gain a better understanding of when and where such pushes will be appropriate. On the other hand, the server push must be authorised by the end user. It can be disabled at any time if its services are not desired.

Binary protocols

Earlier iterations of HTTP utilised text commands to request and deliver information between client and server. While text might be easier for a human to read and comprehend, binary protocols (the use of 0s and 1s in place of words) is far more efficient from a computing perspective.

HTTP/2 implements a binary protocol, translating all text commands into binary code before sending them to the server. This reduces the amount of parsing data in the streams, alleviating stress on the network, as well as optimising resource consumption and making the system less susceptible to downtime.

Meanwhile, it’s also beneficial in security terms. Response splitting attacks could sometimes take advantage of vulnerable textual streams, but a binary protocol eliminates that threat entirely. Binary protocols also dovetail with all of the other amendments to create a smoother and more positive user experience.

Header compression

A header can be conveniently thought of as the envelope containing the payload (the desired information) that is requested from the server by the client. Given that HTTPs are stateless entities, each data stream necessarily must contain as much information as possible in order for the server to accurately meet its demands.

When it comes to media-rich websites, servers find themselves inundated with almost-identical header frames from multiple clients at the same time, or the same client at different times. This is an inefficient use of resources which slows down the network and adversely impacts upon the user experience.

HTTP/2 uses stateful header compression, which means that both client and server retain a list of headers that have been used in previous stream requests. This allows the header on individual streams to be greatly compressed, then indexed against the stored list at either end and reassembled. In this way, smaller amounts of data are being transmitted, improving efficiency and increasing speed of performance.

Stream prioritisation

HTTP/2 endows end users with the capability to prioritise certain streams above others. This is achieved by assigning a weight of between 1 and 256 to give precedence to one stream above another and deliver a more positive and individualised user experience.

However, this particular feature is still in development and at present, servers are rarely at liberty to accommodate stream prioritisation requests as fully as is desirable. Research and development into prioritisation is still ongoing and it is expected that in the future, this will comprise a significant advantage of HTTP/2 over HTTP/1.1.

What do these changes mean for WordPress users?

HTTP/2 represents a major advance for WordPress users, both in terms of those hosting WordPress sites and those visiting them. Previously, WordPress site owners were encouraged to incorporate fewer images into their sites and group images together when possible to reduce the strain on the servers meeting the demands of the network. This was all done in order to deliver as fast, efficient and user-friendly experience as possible, enhancing the popularity of a site among those visiting it.

Now, however, such hacks, fixes and workarounds have become redundant – which is just as well in today’s online climate. Web users want to have their cake and eat it. They demand high-resolution images and plenty of them, but they’re not prepared to wait around and withstand lengthy delays to access them. Fortunately, HTTP/2 means that WordPress users can take advantage of the improvements outlined above to optimise consumption of resources, make network traffic more efficient and ultimately deliver a speedier, more responsive website for their customers.

Best of all, since HTTP/2 was designed as an extension rather than a replacement for HTTP/1, if the browser being used by a visitor to your site does not support the updated technology, it will simply revert to its predecessor with the user being none the wiser. However, such a scenario is unlikely, since HTTP/2 is now almost ubiquitous and supported by the vast majority of browsers.

How do I implement HTTP/2 on my WordPress site?

Clearly, those website owners who don’t wish to fall behind the competition must roll with the times and update their WordPress site to HTTP/2. Luckily, doing so is a fairly straightforward task. But it’s one that depends largely on the hosting company or server which acts as the host for your site. In order to determine whether HTTP/2 is supported on your site, it’s best to contact them directly and enquire. Alternatively, this online tool can tell you whether HTTP/2 is running on your site.

One other prerequisite for supporting HTTP/2 is encryption. HTTP/2 demands that all websites which utilise it must run over a secure connection supported by either TSL or SSL. An easy way to verify whether your website has a secure connection is whether it begins with HTTPS in the address bar. If it does, you’re good to go. If it only reads HTTP, you’ll need to purchase a security certificate via your hosting company in order to enable HTTP/2.

WordPress support from the experts

Still unclear on the finer points of HTTP/2? Not to worry. The boffins at WP Tech Support are fully versed in all aspects of WordPress websites. This includes HTTP/2 incorporation or any other considerations you haven’t yet fully fathomed. Learn more about our WordPress support services and take your business to the next level with HTTP/2 today.