What you need to know about HTTP/2

HTTP/2 is here and like many of you, I had little to no idea what that means. Until I did a bit of research and wrapped my head around all the jargon found inside many technical documents it started to become clearer. This article is more or less a reflection of what already exists in the community. I wanted to approach the concept of HTTP/2 in a more readable manner than much of what I had to read to understand it myself.

What HTTP/2 actually is and why it exists

It all begins with HTTP which stands for HyperText Transfer Protocol which essentially forms the inner lying foundation of the web we know today. HTTP essentially allows us to retrieve resources across the cyber landscape which is hosted on web servers worldwide. HTTP is a structured text that uses logic (a.k.a. hyperlinks) to move from one bit to another.

HTTP1.1 has served the web for over 15 years now and its patterns and makeup have served us well. Today, with the new forms of resource-intensive content being served across many websites the need to find a more efficient experience for the user is of the utmost important concern. Many native applications are migrating to a web app environment which means a lot of requests to the server are being made, some even in the background. With all of this said it’s easy to see why more attention is being put on a new and improved experience hence the arrival of HTTP/2.

The problem with HTTP1.1

HTTP1.1 limits processing to one request at a time. This forces your browser to utilize multiple connections (TCP connections) to process requests simultaneously. If you’ve ever been on a website that takes some time to load (assuming you have decent internet connectivity), this is what is happening. Nowadays, we developers and designers have found ways to hack this dilemma through a variety of methods of which you might be familiar:

Concatenation
Minification
Inline data
Sprites
Cookies
and much more

How HTTP/2 helps

HTTP/2 introduces what is known as “streams”. They are what I would describe as two-way exchanges between the client and the server. This means a request can return more than one source of content at a time. It does this in the form of small chunks of data which when are requested are sent to the browser to later get rebuilt before your eyes. The benefits:

No requests blocking each other
A single TCP connection is still used though multiple streams are transmitted.
No more need for the hacks I spoke of prior. Concatenation, sprites, and others really are no longer need (huge perk!)
Ultimately means better and faster performance

With HTTP/2 new goals were set which involved techniques such as:

Multiplexing
Compression
Request Prioritization
Server Push

This collection of techniques combined allows a server to respond more efficiently based on the request from the client’s end.

The following chart is from a Kinsta.com resource called What is HTTP/2? and explains the semantics of an HTTP1.x setup and the improvements added to HTTP/2.

Similarities with HTTP1 and SPDY

What HTTP/2 brings to the table

Server Push
Server Push allows the server to avoid this round trip of delay by “pushing” the responses it thinks the client will need into its cache.

It’s Multiplexed
HTTP/1.x has a problem where only one request can be made per connection.
HTTP/1.1 tried to fix this by adding a “waterfall” type of effect for multiple requests and connections at once. This didn’t really fix the problem and is why we are left with so many hacks we have to do to decrease load times today

Multiplexing targets their problems by allowing multiple requests and responses to occur simultaneously. This ultimately allows a client to use one connection to load a whole page.

It is Binary
Binary protocols are much more efficient to parse and leave a smaller footprint. They are also less prone to errors commonly found in HTTP/1.x or HTTP1.1

How will it affect you going forward

As a developer, the main areas of concern are just setting up your websites to utilize HTTP/2 correctly. A lot of web hosts are already offering HTTP/2 support at which you can turn on anytime. If you decide to jump on the bandwagon you’ll want to make sure you’re setup for success. One important note is that HTTP1.1 will play well with HTTP/2 so you don’t have to worry about conflicts or backward compatibility.

Enable HTTPS - HTTPS allows all data sent and received to be encrypted based on your website's domain. You’ll need to purchase an SSL or TLS certificate and activate it on your website. A free option called Let's Encrypt is certainly worth checking out as well!
Make Sure Your Server Supports HTTP/2 - If your current web host doesn’t offer HTTP/2 you might be out of luck until they do. You can always shop around for another host but switching hosts in my experience is not a simple task.
TEST - as with anything you’ll want to test to see if your HTTP/2 stack is working.

Client Support

Chrome 40+ supported
Firefox 36+ supported
IE 11+ supported
Safari 9+ supported
Opera 21+ supported

TL;DR

At a high level, HTTP/2:

is binary, instead of textual
is fully multiplexed, meaning it loads multiple streams of data on one TCP connection.
can, therefore, use one connection to load multiple streams of data
uses header compression to reduce overhead
allows servers to “push” responses proactively into client caches source

Where to go from here

There’s plenty to read regarding HTTP/2. Below is a small list that helped me understand what’s coming and why it’s a big deal for the web as we know it.