Why you should move to HTTP 2 and How You Can Start Using It
Imagine… You are googling up some stuff and your website loads much faster than previously it used to, the speed of your internet connection enhances manifold times, and your server uses fewer resources. It does not sound true. Right?
Well, You are wrong! With the incredible advancement in web technology over past 20 years, The FUTURE is here.
At Google Webmaster Central Hangout in the year 2015, Google’s webmaster trends analyst John Mueller said that GoogleBot will support HTTP/2. And true that! With time SPDY(Google’s own protocol for transferring web content) has deprecated.
Switching to HTTP/2 has many underlying reasons, including a tremendous speed increment which makes for a much better user experience.
What Is HTTP/2?
The Web has changed a lot over years, so a new protocol ie HTTP/2 is introduced post HTTP/1.1, which was drafted in the year 1999. It is the latest update to the HTTP protocol(Hyper Text Transfer Protocol) by the Internet Engineering Task Force (IETF). And to no surprise, HTTP/2 is a much-needed refresh, as the update brings with it advancements in efficiency, security, and speed.
History of HTTP/2
HTTP/2 is based mainly on Google’s own protocol SPDY (for web content transfer), which depreciated in the year 2016 SPDY manipulated HTTP traffic, with definite goals of reducing load latency of a web page and improving security over the web. And yes, some of the features are same and can be found in HTTP/2 which manages to improve data transmission while keeping backward compatibility. SPDY had already proved many concepts used in HTTP/2.
Features of HTTP/1.1 and HTTP/2 compared
Single Connection –The number of round trips needed to set up multiple TCP connections is reduced by using a single connection to a server to load any website, and the connection remains open as long as a website is open.
Multiplexing- Some websites require the web browser to make numerous requests to render a web page. HTTP/1.0 allowed only one request to be made at a time, whereas HTTP/1.1 allows multiple requests. The exact number of simultaneous requests with HTTP/1.1 was dependent on the browser being used.
With newer websites generally requiring over 100 connection the responsiveness of the website suffered. Another problem was “Head of line blocking” which means before any further request can be made the results of the initial request must have been received.
Previously, with HTTP/1.1, each transfer would have to wait for other transfers to complete but now with HTTP/2 multiple requests are allowed at the same time, on the same connection and browser can receive them in any order eliminating “Head of line blocking” and increasing speed and efficiency.
With HTTP/1.1, head-of-line blocking made it easy to load various components in the correct order. But now you might think that since there is no head of line blocking in HTTP/2. How would this happen?
Coming to the answer,
The new protocol solves this problem by allowing the browser(client) to communicate with the server and mention the priorities for the objects or files which are to be fetched. Since modern web browsers will take care of prioritization and handling of data streams, so no changes are to be made by web/app developers.
Header compression- HTTP/2 has made considerable improvements to the HTTP headers. The format to inform the servers what information is needed, and in which that information can be delivered are called headers. EG OF HEADERS IN HTTP
For every asset requested headers were required in HTTP/1.1. So in that case, if you had a page with over 50 requests can be time-consuming, and used bandwidth. But HTTP/2 can send all the headers in a single connection with the server, utilizing the idea of compression. Instead of 50 round trips required to load the headers for all the components, it can now be done in only one trip.
Instead of GZIP as in HTTP/1.1 a new header-specific compression scheme called.
HPACK has been introduced. HPACK provides a balance between safety and compression efficiency as HTTP headers seldom change between messages.
Server push- Using HTTP/2 Client can now use additional resources pushed by server in future unlike earlier when HTTP/1.1 was prevealent.But to utilize this feature of server push new applications must be designed carefully to balance performance and utility. People on high latency connections can see a substatial boost as it effectively removes multiple round trips to the server.
Improvements For Servers With HTTP/2
Many techniques used by developers place additional strain on the servers due to number of extra connections opened by browsers. But HTTP/2 eliminates the need of connection-related techniques which results is lower bandwidth requirements, lower server memory usage and less network overhead.
While using network on mobile phones, multiple TCP connections caused issues with it sometimes, resulting in dropping of packets and resubmitting the requests. Thus, these additional requests added to the server load.
But HTTP/2 brings benefits for a server, as well. Fewer TCP connections are necessary, as stated above. easier to parse, more compact and less error-prone
HTTP/2 is amazing protocol introduced.
SEOs and HTTP/2
Since GoogleBot has added support for HTTP/2, websites which support this protocol always see immense ranking boost from speed. But the fact is, Chrome and Firefox only supports HTTP/2 over HTTPS, so many websites which have not yet upgraded to HTTPS can see the boost in rankings whenever they do so.
HTTP/2 is faster and provides a better user experience.
Google made speed a ranking factor so, HTTP/2 being faster can provide better ranking and better user experience also comes along with it.
SEOs, server administrators,developers and infact everyone else should be switching to HTTP/2. There is no downside to upgrading to HTTP/2, we believe.
Step 1: Setting up The Necessary Files
Open the terminal as a root user and download the apt package for your linux distribution,
- Debian/Ubuntu (32-bit)
- Debian/Ubuntu (64-bit)
- CentOS/Fedora (32-bit)
- CentOS/Fedora (64-bit)
Install the packages (requires ‘at’)
- rpm -U mod-spdy-*.rpm
- servicehttpd restart
Install the packages
- dpkg -i mod-spdy-*.deb
- apt-get -f install
- service apache2 restart
Step : Updating your web stack
To start using HTTP2 protocol, you will need the following:
- The first version of Apache i.e. Apache 2.4.17 with mod_http2 built-in.
- The first version of nginx with official http2 support ie NGNIX 1.9.5
Integrate HTTP/2 On Apache
Apache’s mod_spdy is an opensource part that allows requests over secured HTTP ie HTTPS to be served using the SPDY protocol. Recently Google has given this project to the Apache foundation to be integrated directly in the Apache, so far the module is only included in edge repositories, rather than in the main 2.4 repo. It is planned for integration in Apache 2.4, 2.6/3.0 or later with the help of mod_http2 module. So if you have 2.2 or lower version then first you got to upgrade to the compatible version. This module does not work with HTTP connections, so you need to purchase and configure SSL/mod_sslfirst.
This concludes Apache HTTP is installed with HTTP/2 module and it’s time to do the necessary configuration.
- Take a backup of httpd.conf file (default location /etc/httpd/conf/httpd.conf)
- Open the httpd.conf file with vi and ensure following exist, if not then add it.
LoadModule http2_module modules/mod_http2.so
- Next, you need to add the Protocols directive like below
Protocols h2 h2c http/1.1
Enable HTTP/2 module
Apache’s HTTP/2 support comes from the
mod_http2 module. Enable it from:
a2enmod http2 apachectl restart
Add HTTP/2 Support
We highly recommend you enable HTTPS support for your web site first. Most web browser simply do not support HTTP/2 over plain text. Besides, there are no excuses to not use HTTPS anymore. HTTP/2 can enabled site-by-site basis. Locate your web site’s Apache virtual host configuration file, add the following right after the opening
Protocols h2 http/1.1
Overall, your configuration file should look something like this:
<VirtualHost *:443> Protocols h2 http/1.1 ServerAdmin email@example.com ServerName your-awesome-site.com ... </VirtualHost>
After the changes, don’t forget to reload/restart Apache.
Now, Apache HTTP instance is enabled to support HTTP/2 protocol.
Note: there are three parameters in above Protocols directive
- h2 – instructing Apache to support HTTP/2 protocol over SSL/TLS
- h2c – instructing Apache to support HTTP/2 over TCP
- http/1.1 – if client doesn’t accept HTTP/2 then serve the request over HTTP/1.1
Integrate Apache on Ubuntu
$ sudo add-apt-repository ppa:ondrej/apache2
$ sudo apt-get update
$ sudo apt-get install apache2
Server version: Apache/2.4.17 (Ubuntu)
Server built: 2015-11-05T00:00:00
Finally, enable HTTP 2
$ sudo service apache2 restart
Step 2: Configure & Test
The Google repository of mod_spy directly installs an NPN TLS HTTPS extension for Apache thus, adding support for HTTP/2 only on HTTPS, In addition, if you require PHP being served over HTTP/2 then you need to configure PHP to run in cgi mode or PHP-FPM, rather than mod_php.
In short, it’s a quick reconfiguration of your apache config, add the following lines (whichever appropriate) – bare in mind that whilst HTTP2 protocol does not require SSL, many browsers that use http2 do
# for a https server
# for a http server
A full guide for apache in Ubuntu is available here – via Pixelinc
Again, it’s a very simple recongifuration in NGINX – source
listen 443 ssl http2 default_server;
To test if HTTP/2 is working launch a web browser and goto http://spdycheck.org/ https://www.h2check.org/ – type your server domain name to check.
Step 3: Watch out for updates
Check your Website is enabled or not using this HTTP 2 Checker . This tool show you the perfect result whether your Website is using the benefit of HTTP/2 or not.
As this is new there’s likely to be many updates to the software in coming months, be sure to keep your server software up to date.
Update 09/11/2015 – Real HTTP2 support
Since the new HTTP/2 protocol has many benefits like faster load time of webpages, mobile friendliness because of header compression, multiplexing(enhancing the security of your website) and of course, the most beneficial to end users faster load times of web pages. So we recommend you to switch to new the new web protocol, HTTP/2.
Planning on moving to HTTPS? Here are 13 FAQs!
What’s missing? Let me know in the comments and I’ll expand this over time, perhaps it’s even worth a blog post or help center article. Note that these are specific to moving an existing site from HTTP to HTTPS on the same hostname. Also, remember to check out our help center at https://support.google.com/webmasters/answer/6073543
# Do I need to set something in Search Console? No, just add the HTTPS site there. The change-of-address setting doesn’t apply for HTTP -> HTTPS moves.
# How can we do an A/B test? Don’t cloak to Googlebot specifically, use 302 redirects + rel=canonical to HTTP if you want to test HTTPS but not have it indexed. Don’t block via robots.txt. More about A/B testing at https://googlewebmastercentral.blogspot.ch/2012/08/website-testing-google-search.html (302 redirects aren’t cached.)
# Will the rel=canonical guarantee that the HTTP URL is indexed? No, but it’s a very strong signal when picking the indexed URL.
# What’s the next step after testing? Follow our site-move documentation ( https://support.google.com/webmasters/answer/6033049 ). Use 301 redirects from HTTP to HTTPS, confirm the new version by adding a rel=canonical on the HTTPS page, pointing to itself, and submit sitemaps including both HTTP & HTTPS URLs with new change-dates (in the long run, just keep the HTTPS sitemap).
# What about the robots.txt file? The HTTPS site uses the HTTPS robots.txt file. Check that it’s reachable or serves a 404 result code, and check that your HTTP URLs aren’t blocked by the HTTP robots.txt file.
# Is it OK to have just some pages on HTTPS? Yes, no problem! Start with a part, test it, add more.
# Should I move everything together, or is it fine to do sections? Moving in sections is fine.
# Will I see a drop in search? Fluctuations can happen with any bigger site change. We can’t make any guarantees, but our systems are usually good with HTTP -> HTTPS moves.
# Which certificate do I need? For Google Search, any modern certificate that’s accepted by modern browsers is acceptable.
# Do I lose “link juice” from the redirects? No, for 301 or 302 redirects from HTTP to HTTPS no PageRank is lost.
# Will we see search keywords in Google Analytics when we’re on HTTPS? This won’t change with HTTPS, you can see the search queries in Search Console.
# How can I test how many pages were indexed? Verify HTTP / HTTPS separately in Search Console, use Index Status for a broad look, or the sitemaps indexed counts for sitemap URLs.
# How long will a move from HTTP to HTTPS take? There are no fixed crawl frequencies, it depends on the size of your site, and the speed of crawling that’s possible. The move takes place on a per-URL basis.