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.
In this post, we’ll answer the following questions:
- What is HTTP and Why Do We Need HTTP/2?
- What Are the Limitations of HTTP1.x?
- How Is a Website Using HTTP/2 Faster?
- HTTP/2 Allows Multiple Files to be in Transfer Simultaneously
- HTTP2 Employs Other Optimization Techniques
- Who “Invented” HTTP2? And What is Speedy?
- When Can I Implement HTTP2 on My Site? What Happens if a Visitor’s Browser Doesn’t Support HTTP2?
- How Do I Implement HTTP2 on My Website?
- What About HTTP/2 for WordPress?
- What About Other Techniques for Making WordPress Faster?
Let’s jump in…
What is HTTP and Why Do We Need 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?
The Limitations of HTTP1.x
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:
- index(.html)
- blueribbon.gif
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
-
- Several HTML files used for different features and functions required by WordPress and other plugins
- CSS files to style the site
- JS files to enable interactive functions
- Imagery to beautify the site and to complement the HTML, JS and CSS files
- Third party scripts to enable functions such as Analytics, social sharing, Google Ads and so much more.
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:
- Decreasing the latency by combining as many of the above files into as few files as possible – thus requiring fewer requests
- Compressing and minifying the files thus reducing the size of the data being sent between the browser and the server
HTTP/2 aims to implicitly solve these problems.
How Is a Website Using HTTP/2 Faster?
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.
HTTP/2 is Meant to be Readable by Machines, Not Humans
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.
HTTP/2 Allows Multiple Files to be in Transfer Simultaneously
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 Allows the Server to Send Files to the Browser That It Knows It Will Need
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 Employs Other Optimization Techniques
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 is faster to create a connection between the client and the server;
- The actual connection between a browser and a web server is more efficient hence implicitly faster;
- Files and resources needed by the client can be transferred simultaneously rather than sequentially;
- Files can be pushed to the web browser by the server if it thinks it’s going to need them later on – making the whole transfer time of files shorter; and
- Initial connections have been made more efficient.
Who “Invented” HTTP2? And What is Speedy?
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.
When Can I Implement HTTP2 on My Site? What Happens if a Visitor’s Browser Doesn’t Support HTTP2?
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.
How Do I Implement HTTP2 on My 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.
Many hosting companies already support HTTP2 (including WPMU DEV hosting). If you are not sure, ask your host whether your current hosting account supports HTTP2.
You can also use a tool to check whether HTTP/2 is already enabled on your website.
Is That All I Need to Do?
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.
What About HTTP/2 for WordPress?
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.
What About Other Techniques for Making WordPress Faster?
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.
Allowed Optimizations: Anything That Reduces Render Time
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:
- Reducing plugins to decrease render time,
- Implementing various levels of caching mechanisms, and
- Making your site leaner overall through themes or otherwise.
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.
Disallowed Optimizations: Anything That Reduces the Number of Requests
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.
For this reason, we advise sites hosted with WPMU DEV that use our Hummingbird WordPress optimization plugin not to expect huge improvements, as our optimized servers already squeeze all the speed they can out of your assets.
Let’s Make the Web Faster With HTTP/2
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. This, by default, means that your users will have a much faster and more pleasant user experience.
For HTTP2 optimized managed WordPress hosting with 24/7 expert support, we recommend checking out our great range of flexible and affordable hosting plans.
Editor’s Note: This post has been updated for accuracy and relevancy. [Originally Published: June 2016 / Revised: February 2022]
Tags:
