How many times have you come across an article which suggests ways to make your WordPress website faster?
You’re probably sick and tired of them. The sorry thing is most of them recycle the same old tricks over and over again.
I’ve got news for you: The bad news is that this is another article on how to make your WordPress website faster. The good news is that it’s a totally new concept.
It’s called HTTP/2.
First of all, you’re probably extremely familiar with HTTP. Although you may now know exactly what it means and what it does, you probably use it dozens of times every day.
Every time you visit Google.
Or WPMU DEV.
Or even WordPress.org
Essentially, HTTP (short for HyperText Transfer Protocol) is the way a browser and a web server communicate with each other. In not too technical terms, HTTP is the language that is used by the web server and the client to communicate.
I won’t be digging too deeply into HTTP, what it is and how it works. If you want to read more about it, check out the Wikipedia page.
HTTP was first documented officially in 1991 as version 0.9. This is more than 25 years ago, which in technology is eons.
Note: There were multiple versions of HTTP, including 1.0 and 1.1 – I’ll refer to HTTP1 as HTTP1.x in this article.
Suffice to say, back then, your run-of-the-mill website looked something like this:
We’ve come a long way since then – and this website you’re reading right now is an example of how the web has progressed.
The size of your standard website has mushroomed from a few kilobytes to easily a few megabytes. The actual number of files which make up a website has gone from just a handful to a hundred or more files being the norm.
This progress, and the resulting explosion in the size and number of files needed to run a website, exacerbated a number of limitations which the HTTP protocol had. These limitations were creating latency (or slowness) in the loading of a website.
Hence the need for HTTP/2.
HTTP/2 is essentially an evolution of the HTTP protocol, which is aimed at fixing these limitations. In fact, one of its stated primary goals is to:
“… Decrease latency to improve page load speeds in web browsers.” – Wikipedia
But before we explain what problems HTTP/2 wants to solve, what are the problems with HTTP1.x exactly?
As I referred to a few paragraphs up, HTTP1.x has a number of limitations, which have come about due to the ever-increasing complexity and size of websites today.
Let’s go back to have a look under the hood of what websites looked like in the early days.
If we once again refer to this website, which takes us back a few years to what websites looked like in the early days, we can see that the whole website is made up of two files:
The HTML file consists of nearly ALL of the content of the page. The only additional resource required to display the page correctly is the blueribbon.gif.
This means that the browser has to make two connections.
On the other hand, let’s look at a mature site, such as WPMU DEV.
There are literally tens of different files to download
The browser has to ask for EACH and every file mentioned in the HTML, CSS and JS files. That means it has to make hundreds of connections.
Now, creating a single connection requires significant technical overhead. Creating hundreds of connections means that this overhead is incurred hundreds of times.
Just imagine if your postman had to go back to the post office for every single letter they needed to post.
This was becoming a real issue – and hence, making a website fast, mostly involved two things:
HTTP/2 aims to implicitly solve these problems.
If you’re looking to understand the exact specifications of HTTP/2, may we suggest that you visit the HTTP2 Github FAQ.
If you don’t want to get too technical, I’m going to try to explain the improvements of HTTP/2 over HTTP in not too techy terms.
HTTP1.x was a text-based protocol, in essence intended to be human readable.
On the other hand, HTTP/2 is a binary protocol. This means that it is intended for communications between machines (your web server and your browser) rather than humans.
This makes communication between the server and the browser more efficient in a number of ways. In essence, it is faster to parse, it is compressible, it reduces the number of errors, and gets rid of a number of inefficiencies required for readability such as whitespace, blank lines, line endings, capitalization etc.
Remember when I mentioned the postman who had to go back to post office for each letter they wanted to deliver? They were limited by the fact that they could only transfer one letter at a time. HTTP1.x also suffered from the limitation that only one connection was allowed at a time.
HTTP/2 is multiplexed, which effectively means that several connections are allowed to happen at the same time.
Our “postman” can now deliver more than letter at a time, making the delivery of all of the resources of a website much more efficient and of course faster.
HTTP2 implements a mechanism called Server Push.
On the other hand, in HTTP1.x, the browser typically had to wait for an HTML file to get delivered and parse it. Once it realizes that it needs a CSS file, a JS file, and a few image files, it then had to request those files. If while parsing the resultant files, it required other files, it then had to send other requests later on.
Server Push is a mechanism where the server actually knows which files the browser will need before the browser actually asks for them. The server “pushes” those files to the browser without waiting for the browser to request them.
This makes the whole process of getting all of the resources required to display a website much faster.
HTTP2 allows what is called header compression. This is essentially a mechanism which reduces the overhead in creating the initial connection between the server and the client. This makes the time required to start a connection significantly lower, particularly on mobile devices, where the overhead is typically compounded by slow networks and the need to fetch data from multiple servers for a single website.
Let’s recap how HTTP2 is more efficient:
It has been known for a while that HTTP was somewhat inefficient. In 2009, two engineers at Google (Mike Belshe and Roberto Peon) embarked on a mission to improve the efficiency of HTTP – wanting to make the web 2x faster.
They did this by implementing the techniques discussed above, by essentially modifying how requests and replies are sent over the wire. This protocol became known as SPDY (or Speedy).
The code base of Speedy was eventually adopted as the starting point for the development of HTTP2 by the HTTP Working Group.
HTTP2 on browsers was defined and implemented in such a way that it can gracefully degrade to HTTP1.x. Essentially, if a browser does not support HTTP2, it will fallback to using HTTP1.x. The user will be none the wiser.
However, it is starting to become unlikely that the browser of your visitor does not support HTTP2.
As at the time of writing this article, about 70% of browsers currently in use support HTTP2.
Major browsers such as Chrome, FireFox, Microsoft Edge, Safari, Opera and other major browsers all support HTTP2.
You can check whether your own browser supports HTTP2 using Akamai’s testing tool. It is also a very neat demo of how HTTP2 will benefit the loading time of your website.
This is something which is mostly dependent on the web server that powers your website. Again, most major web servers such as Apache, nginx and IIS already have support for HTTP2.
However, even if your site is powered by one of these servers, this doesn’t automatically mean that your website can support HTTP2. It all depends on whether your website’s hosting server currently has a version of the software which supports HTTP2.
There are a few hosting companies which already support HTTP2, but not all of them. Your best bet is to actually ask whether your current hosting account supports HTTP2.
You can also check against the following tool to check whether HTTP/2 is already enabled on your website.
Not really, no. There’s a further complication.
Currently, implementations of HTTP2 on browsers require HTTP2 to be delivered over an encrypted connection.
This means that besides having a web server which supports HTTP2, your site must also have implemented HTTPS. (You may want to fully have a look at a full (but simple) guide to WordPress HTTPS if you’re not too familiar with the benefits of HTTPS).
This means that you’ll need to acquire a secure certificate for your website and implement it.
You can either acquire a commercial SSL certificate through your hosting company which will use an appropriate certificate authority to generate the certificate. You can then implement the secure certificate on your WordPress site.
Recently, there’s also been a push for free SSL certificates using Let’s Encrypt. This is also covered by another of our excellent guides in Adding Free SSL Certificate and HTTPS to WordPress with Let’s Encrypt and Certbot.
Simply put, HTTP/2 is independent of WordPress or any other CMS you are using. Since this is something which is implemented at the web server level, this is something which is “lower” in the stack than your WordPress website.
Then again there are specific things which you can do for WordPress.
One of the improvements we mentioned about HTTP2 is the implementation of a mechanism called Server Push. This requires suggestions or guidance by the CMS being used.
For WordPress, the HTTP/2 Server Push WordPress plugin allows site admins to suggest what resources can be “server pushed.” What this does is add the necessary support for pushing every enqueued script and style file.
This means that JS and CSS files which are using the WordPress enqueue mechanism can be pushed the web server to the browser, thus making full use of the HTTP/2 optimization techniques.
This is a bit of a hot issue and something where developers tend to disagree with each other.
There are different types of optimizations which make your WordPress website faster. Some of them are still applicable, some of them should be disabled. Otherwise, they can actually make your website slower if you use HTTP2.
Any optimization which is aimed at reducing the overall time it takes to render the pages of your WordPress can stay in place. Such stuff as:
These are all optimizations that are safe and can stay. Other optimizations which can stay are the ones where files are given a long expiration time, such that they are reused over and over again if they are not changed. This typically applies to CSS and JS files which do not change frequently.
The most common way of making a website faster (as we’ve discussed previously) is the combination of multiples files into fewer files, and also the minification of these files.
Combining files is something that creates overhead. With HTTP2, there is no benefit in reducing the number of requests so this overhead is actually creating a “longer” initial response time.
Minification, also another process which essentially reduces the size of files by eliminating characters intended for human legibility, also involves server overhead. Since HTTP/2 is actually doing very efficient compressing of its own, minification becomes superfluous. It also adds overhead for processing, which results in no additional benefit for HTTP/2-based websites.
Now that you’ve seen how HTTP/2 can make your website faster, I hope you’re eager to get it implemented on your site ASAP.
It will improve the loading times of your website significantly. That by default means that your users will have a much faster and more pleasant user experience.