Portent.com Embraces HTTP/2 (with open arms)

One of my goals this year was to get portent.com set-up utilizing HTTP/2 and optimizing that configuration. Late last week I was able to accomplish that, and the results are impressive.

Like, 500 milliseconds impressive. We used to top out around 1.2 seconds after going to HTTPS, so I didn’t think the results would be that dramatic. What’s more, this was a relatively easy win.

Warning, if you don’t already believe site speed is important, take a minute to read the study we published a few years ago about the direct impact of site speed on revenue or conversions. For more depth, dig into Portent’s massive guide to site speed optimization. And if you’re struggling with how to prioritize investments in site speed based on impact across your overall digital marketing program, start with Infrastructure as a foundation for the digital marketing stack.

What is HTTP/2 anyway?

HTTP/2 is the newest (and only) revision of the Hypertext Transfer Protocol, or HTTP. Since 1997, HTTP/1.1 has been standard in all browser-based communications on the web. Considering all of the technological advancements since 1997, you can probably understand the significance here.

At a high level, the goals of HTTP/2 are fairly straightforward:

1. Maintain compatibility with HTTP/1.1 and any future protocol improvements
2. Reduce latency in web browsers to improve page loading speed

What has changed to make HTTP/2 better?

There are quite a few changes from HTTP/1 to HTTP/2, but three core changes have the largest impact:

1. Compressing HTTP header data. Sending “less” is always faster.
2. Requests are multiplexed over a single connection. Allows every request over the TCP connection to be made immediately without waiting for the previous response to come back. The responses may come back in any order. In HTTP/1.1 it is ordered and therefore, blocking.
3. A new HTTP/2 Server Push feature. Allows the hosting server to push known resources (like your site’s main CSS and/or javascript file) that the browser would have to discover and request from parsing the page’s source code.

For more specifics, check out the HTTP/2 Wikipedia article and/or this HTTP/2 FAQ.

So, what does this mean?

At a high level, it means everything is faster. It also means that parallelization and asset combination, or concatenation, are no longer optimization tactics. In fact, they are deterrents.

Because of the new multiplexing techniques used with HTTP/2, the less unique domain connections, the better. Now that multiple requests can be stuffed into a single connection, dividing up a page’s assets among many domains is hurtful because more hand shaking is required. Parallelization was essentially a work around for shortcomings with HTTP/1.

Under HTTP/1, CSS and javascript files were often concatenated into single files so less TCP connections were made. With HTTP/2 eliminating the multiple connections issue, it no longer makes sense to combine these files — mainly because every time a change is made, the combined file is regenerated and forces users to reacquire it, which is costly because of its size. Better to make a granular change to one of many CSS files for a smaller and quicker delivery.

Encryption/HTTPS

Technically, HTTP/2 works under non-encrypted connections. That being said, currently no major browsers support it. So, as of now, a move to HTTP/2 is a move to HTTPS.

For my money, you might as well do both at the same time — Google is certainly pushing for encryption everywhere and it’s only a matter of time until all major browsers follow suit.

How Can I Implement HTTP/2?

Most major browsers already support HTTP/2, so there is no sense in waiting to implement. There are many page speed gains to be had.

The largest hurdle will be in deciding how to implement it. All major web servers now support HTTP/2 as well, but in many cases, that requires upgrading, which very likely means migrating, and/or rewriting configuration files.

An easier win is implementing a CDN that supports HTTP/2, like Cloudflare. That’s ultimately what we decided on for Portent.com at this point. The determining factor in our case is that our site is behind load balancers that do not support HTTP/2. So, it would have required firing up new web servers and upgrading to the latest versions of NGINX and Apache (yes, we run both), and then either ditching our load balancing setup, or writing/configuring our own. As you can probably imagine, I was not excited with those options. =)

Whichever path you choose, we’d strongly urge you to look at making this switch. Here’s to your (site) health!