A few months back, it was announced that the specification for HTTP2 has been finalised and released. HTTP2 offers significant performance advantages to any website, so seeing as the many websites are powered by Joomla, it was only a matter of time before we needed to know how to setup Joomla HTTP2.
So here we are with a complete a full guide of what HTTP2 is, why you should enable Joomla HTTP2 on your website, what are the advantages and finally - how to actually do it.
- What is HTTP2 and why do we need it?
- Enter HTTP/2
- I've also heard that there's SPDY (aka Speedy)
- Great, so HTTP/2 removes many inefficiencies of HTTP. So what do I need to do to enable Joomla HTTP/2
- But wait - there's a further complication to enable Joomla HTTP/2
- Is there a plugin I can use for Joomla HTTP2
- Let's make Joomla faster with HTTP2
So let's start with the first few things.
What is HTTP2 and why do we need it?
Simply put HTTP2 is a way to make your website load much much faster, without any extra effort from your side. (Well not nothing, but it's just a one-off thing).
Before we actually get down to HTTP2, let's have a bit of a look back at HTTP and why a new version of HTTP was necessary.
What is HTTP?
The HyperText Transfer Protocol (aka HTTP) is simply a way by which your browser communicates with the web server of the website you are visiting.
There are many ways in which two (or more) machines communicate over the Internet. HTTP is the one used for browsing websites. It's not the one which carries the most traffic, but it is definetely the one which is most "visible" since it is involved in all website browsing.
Afterall, how many times do you type http:// every single day?
Without going into too much detail, the HTTP protocol is used by the visitor's browser to request all of the content of a website.
The conversation goes something like this:
Browser: Hello server at www.collectiveray.com - can you give me the content of this website?
Server: Hello browser, this is the HTML content of www.collectiveray.com
<!DOCTYPE html> <html xmlns:og="http://ogp.me/ns#" xmlns:fb="https://www.facebook.com/2008/fbml" lang="en-gb" dir="ltr" class='com_content view-article itemid-388 j35 mm-hover'>
Browser: Great, now I see that I also need the content of these js files: collectiveray.js, jquery.min.js, jquery-ui.min.js ... and also the content of these files: styles.css, jquery.min.css, ... Also, please send me the following images: favicon.ico, logo.jpg, blog-header.jpg, advert1.jpg, ...
- Here are the contents of the file collectiveray.js
- And here are the contents of the file jquery.min.js
- And here is jquery-ui.min.js
- and here is the image footer-icon.jpg ...
Really and truly, the server and browser are playing digital tennis with the data of the website you are visiting.
Each to and fro from the server sends a small part of the website. This keeps on happening until all of the content is sent from the site server to the browser.
Another very good analogy which has been used to describe HTTP1, is that of a waiter fetching drinks from the bar, getting only one drink every single time they visit the bar.
Of course, that is not terribly efficient, and here is where the problems with HTTP start...
The web has grown faster than the capabilities of HTTP
HTTP has been around for a very long time. When it was thought out and created, the internet was a very different place. Bandwidth was measured in bits, not tens of megabits. Consequently, to be usable, websites were made primarily out of text and hyperlinks. Images were few and far between.
Fast forward to 2016.
Websites, themes and all kinds of functionality have made websites heavier and heavier in terms of resources. Your average website contains hundreds of different files and images. Websites calling hundreds of resources is the order of the day.
To complicate matters, each site requests information from several different servers for all kinds of 3rd party scripts. The amount of toing and froing between a browser and the website server keeps growing and growing.
This is not a problem in itself, however creating a connection between the browser and the server is a technically expensive operation and takes time. As the number of different resources required on a website grows, so does the time it takes to load a site.
How to make a website faster (pre-HTTP2 version)
As can be seen from our simple example, HTTP1 had a number of limitations given the current state of the web. Now, you've probably seen hundreds of articles showing you how to make your Joomla website faster.
We're guilty of having such an article ourselves too (sorry!)
What most of these articles do is find a way to workaround the limitations of HTTP1. This is why there was such a pressing need for HTTP2, not just for Joomla, but for every other website out there. Something at the browser and server level had to be done to deal with the inherent problems of HTTP1.
What were the solutions / workarounds for making a website using HTTP1 faster? We typically referred to them as Reduce, Reuse, Recycle. For more of an explanation on that, we suggest you read our article on making websites faster.
- Create a lightweight site which uses a minimal amount of JS, CSS and image files
- Reduce the number of requests for different CSS files and JS files by combining as many of these files together as possible (reducing requests through combination of files)
- Reducing the number of requests for images by creating one image which combines all of them into one and using CSS sprites
- Remove any extra plugins (to reduce the number of images, CSS files and JS files they add to the site)
- Compressing the data required so that it is smaller in size (and thus faster to transport)
In essence, we wanted to reduce the number of separate requests between the server and the browser. We also wanted to reduce the size of these requests.
So how does HTTP/2 improve all of this?
HTTP/2 was written with the intent of fixing these inherent problems. One of the primary goals of HTTP2 is to
Decrease latency to improve page load speed in web browsers. (Source: WikiPedia)
and introduces the following improvements
- is binary, instead of textual
- is fully multiplexed, instead of ordered and blocking
- can, therefore, use one connection for parallelism
- uses header compression to reduce overhead
- allows servers to “push” responses proactively into client caches
Wait what? Don't worry - let's try to explain this a bit in layman's terms.
- Binary instead of textual: this is something which makes transfer and parsing of the data much more efficient. Binary data transfer is also much less prone to errors.
- Fully multiplexed: again, simply put, with HTTP the problem was that each connection was prone to blocking the connections after it. Imagine yourself in the queue to get into your favourite sports match, but rather than having multiple entry points, you only had 1 turnstile. You can imagine that things can get very very slow. Multiplexing allows multiple files and requests to be transferred at the same time. In the turnstile example, rather than have one person going in at a time, we have 10 gates, with 10 turnstiles going in together.
- Use one connection for parallelism: as we mentioned before, when a connection is expensive to create, if you keep creating and closing it for every resource you need, you're going to create a serious overhead issue. Multiplexing allows the same connection to be reused over and over again. Imagine the connection as a pipe through which data keeps flowing until you don't have any more data. Also, do note that for any website, you will typically have the browser talking to multiple web servers for various 3rd party scripts and resources (Facebook sharing scripts, Twitter, Google Analytics, Ad networks etc. etc.) Having one connection for each of these is more efficient.
- Header compression is also another efficient way of removing several of the overheads associated with having to retrieve several different resources from the same or multiple web servers. Once again, typically rather than having to perform multiple to and fro trips, one trip is typically enough.
- Allows servers to push resources proactively: this is a way that the server, rather than waiting for the client browser to request the different resources as per our first example, it will proactively send them resources they will probably need. This is called HTTP/2 Server push.
If we had to go back to the analogy of the waiter who was bringing one drink at a time, the largest advantage is that now the waiter is using a drinks tray to take all of the drinks together. And they are also taking drinks from the bar which they are likely to need when they are at the restaurant.
I've also heard that there's SPDY (aka Speedy)
Before HTTP2 was actually born, somebody else had actually tried to fix the issues with HTTP. This was a research project by a couple of Google engineers, who had attempted to fix some of the issues of HTTP1.1.
SPDY goals where to
- Allow multiplexing to allow concurrent requests - thus resolving the issues of latency created by having multiple connections
- Prioritize resources such as the most important resources of a site being sent first
- Compress HTTP headers to improve efficiency as discussed above
- Implement server push as discussed above too
In an initial blog released by the engineers who wrote the protocol, it was claimed that it would make the web 2 times faster. Although both major browsers and major web servers supported SPDY, there was little real adoption. However, it's research was critical to the eventual release of HTTP2, since the first draft of HTTP2 used SPDY as it's working base.
Great, so HTTP/2 removes many inefficiencies of HTTP. So what do I need to do to enable Joomla HTTP/2
Which browsers support HTTP/2?
As of at the time of writing, most popular client browsers fully support HTTP/2. FireFox, Chrome and browsers based on Blink (i.e. Opera and Yandex) support HTTP2. Microsoft Edge also supports HTTP2, whilst Apple has announced it will support it. Statistics from such sites as CanIUse? show that current support global distribution is at about 70%
If the browser does not support HTTP2, and the website supports HTTP2, there will be a graceful fallback to HTTP1, so there is absolutely no problem for any visitor if you enable HTTP/2. There can only be benefits.
Which servers support HTTP/2
Apache, Nginx and most popular server implementations already support HTTP/2 - you can check whether your favourite web server, or the web server you use has support for http2 here. However, whether you can use HTTP2 with Joomla actually depends on whether your hosting company has activated this. So you'll have to confirm the actual availability of HTTP/2 with your hosting company. The image below is a list of servers which support http/2.
Simply put, whether your website currently supports HTTP/2 fully depends on your hosting company or the server where you host your Joomla website. We use InMotion hosting (and here is our InMotion hosting review and InMotion VPS review), which currently does not support HTTP2. However, we also use MaxCDN to server our resources, which does support HTTP/2.
There are other companies such as SiteGround which support HTTP/2 already.
You can use this tool from KeyCDN to determine whether your site currently has support for HTTP/2. This HTTP/2 test can tell you whether you need to perform any additional actions or not.
But wait - there's a further complication to enable Joomla HTTP/2
Currently, all of the browsers out there only support encrypted HTTP2. This means that for your site to be able to support HTTP/2 you'll need to have your site served over a secure (TLS/SSL) connection. We've gone over this quite deeply in our article on setting up a WordPress secure certificate on your server.
To recapitulate though
- Secure sites get a SEO ranking signal boost
- They protect the data being transferred to and from the site (particularly important for passwords, credit card data and other sensitive data)
- There is a strong movement towards full secure websites, and if you don't implement security on your site, your website is bound to be left behind
You'll need to acquire a secure certificate via your hosting service company. Hosting companies such as InMotion allow you to use a shared certificate, though if you want to use it with your domain it's highly recommended that you purchase your own certificate.
Installation of the certificate is something which is typically done by your hosting server. It's a one-off thing, so you don't have to worry.
Once that is done, you'll simply need to perform a 301 permanent redirect via your .htaccess file.
Once again, hosts such as InMotion hosting can handle all of this for you, if you are not inclined to do this kind of technical tweaking yourself (which has a bit of risk of downtime if not done right).
Is there a plugin I can use for Joomla HTTP2
We mentioned one of the benefits of using HTTP2 to be the ability to perform a server push of items which will be necessary by the browser. This is, of course, is something which needs to be done at the CMS level, so this needs support from Joomla.
Whilst this is not yet supported at the core level, the Joomla prerendering plugin implements the ability to send a
This is actually taking additional real advantage of the features enabled by HTTP/2.
Let's make Joomla faster with HTTP2
At DART Creations, we've always been fixated with making our websites fast. HTTP2 is an evolution and a revolution at the same time, and we really hope that this article helps you move along towards your setup of Joomla HTTP2.
Please leave a comment below and tell us what else you would like to know.