4 Good Reasons for Using HTTP/2

October 6, 2015

HTTP/2 is too good to pass.

4 Good Reasons for Using HTTP/2

If you don’t know much about HTTP/2 then check this HTTP/2 101 I’ve written half a year ago.

In essence, it is the next version of how we all get to consume the web over a browser – and it has been standardized and deployed already. My own website here doesn’t yet use it because I am dependent on the third parties that host my service. I hope they will upgrade to HTTP/2 soon.

Watching this from the sidelines, here are 4 good reasons why you should be using HTTP/2. Not tomorrow. Today.

#1 – Page Load Speed

This one is a no-brainer.

A modern web page isn’t a single resource that gets pulled towards your browser for the pleasure of your viewing. Websites today are built with many different layers:

  • The core of the site itself, comprising of your good old HTML and CSS files
  • Additional JavaScript files – either because you picked them yourself (JQuery or some other piece of interactive code) or through a third party (Angular framework, ad network, site tracking code, etc.)
  • Additional JavaScript and CSS files coming from different add-ons and plugins (WordPress is fond of these)
  • Images and videos. These may be served from your server or via a CDN

At the time of writing, my own website’s homepage takes 116 requests to render. These requests don’t come from a single source, but rather from a multitude of them, and that’s when I am using weird hacks such as CSS sprites to reduce the number of resources that get loaded.

There’s no running away from it – as we move towards richer experiences, the resources required to render them grows.

A small HTTP/2 demo that CDN77 put in place shows exactly that different – they try loading 200 small images to a page in either HTTP/1.1 or HTTP/2 shows the improved load times of the page.

HTTP/2 has some more features that can be used to speed up web page serving – we just need to collectively start adopting it.

#2 – Avoiding Content Injection

In August, AT&T was caught using ad injection. Apparently, AT&T ran a pilot where people accessing the internet via its WiFi hotspots in airports got ads injected to the pages they browsed over the internet.

This means that your website’s ads could be replaced with those used by a third party – who will get the income and insights coming from the served ads. It can also mean that your website, that doesn’t really have ads – now shows them. The control freak that I am, this doesn’t sound right to me.

While HTTP/2 allows both encrypted and unencrypted content to be served, only the encrypted variant is supported by browsers today. You get the added benefits of encryption when you deploy HTTP/2. This makes it hard to impossible to inject 3rd party ads or content to your site.

#3 – Granularity

During that same August (which was the reason this post was planned to begin with), Russia took the stupid step of blocking Wikipedia. This move lasted less than a week.

The reason? Apparently inappropriate content in a Wikipedia page about drugs. Why was the ban lifted? You can’t really block a site like Wikipedia and get away with it. Now, since Wikipedia uses encryption (SPDY, the predecessor of HTTP/2 in a way), Russia couldn’t really block specific pages on the site – it is an all or nothing game.

When you shift towards an encrypted website, external third parties can’t see what pages get served to viewers. They can’t monetize this information without your assistance and they can’t block (or modify) specific pages either.

And again, HTTP/2 is encrypted by default.

#4 – SEO Juice

Three things that make HTTP/2 good for your site’s SEO:

  1. Encrypted by default. Google is making moves towards giving higher ranking for encrypted sites
  2. Shorter page load times translate to better SEO
  3. As Google migrates its own sites to HTTP/2, expect to see them giving it higher ranking as well – Google is all about furthering the web in this area, so they will place either a carrot or a stick in front of business owners with websites

You may also like

Two years of WebRTC Insights

Two years of WebRTC Insights

Your email address will not be published. Required fields are marked

  1. Deploying HTTPS can be a bit daunting because there are so many things you can do wrong.

    Here are some tips for making it easier for people to deploy HTTPS (which you need for HTTP/2) without having to know all the details.

    Tip 1: Install a recent Linux distribution on your server (these have the openssl version you’ll need with all the fixes and features). Or use containers (Docker or LXC) to add a mini Linux server with a recent distribution to your server (you might want to use it as a proxy in front of your real webserver).

    Information on how to configure your server:

    Where to get some free certificates:
    http://www.startssl.com/ (for personal websites/non-commercial ?)
    https://www.globalsign.com/en/ssl/ssl-open-source/ (for open source projects)
    https://www.ohling.org/blog/2015/02/wosign-free-2y-ssl-certificate.html (free certificates from China)

    How to check if your HTTPS configuration is correct:

    And you should occasionally re-check with the ssltest site so you know you are still doing it correctly, because what might have been considered secure today, might not be tomorrow.

      1. No problem. Technology isn’t always easy and encryption is one of those technologies.

        I forgot to mention https://letsencrypt.org/ is going to start their beta program soon. It’s really exciting. 🙂

        They will allow you to have not only free certificates, but in an automated way.

        This should really help with the burden of deploying HTTPS, because for example you don’t need to talk to different people in your organization to get your certificates, don’t need to worry about the certificates expiring (it automatically renews) and their tooling configures your server with the right settings.

      1. While I can’t imagine them not doing that other than for technical reasons. One reason is that they are already experimenting with it: https://blog.cloudflare.com/test-all-the-things-ipv6-http2-sha-2/

        But in practice it really doesn’t matter much.

        Look at this blog, it’s already using SPDY. The protocol is very similar and the browser support is similar too. Pretty sure Cloudflare will implement HTTP/2 before browsers start dropping support for SPDY.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}