How to Use HTTP/2 to Speed Up Your Websites and Apps – InApps Technology 2022

Now that Chrome has dropped support for Google’s SPDY protocol, if you want your users to get a faster connection to your code than good old HTTP/1.1, it’s time to switch to HTTP/2.

There are plenty of benefits to HTTP/2 according to Mozilla’s Patrick McManus (the author of Firefox’s HTTP/2 implementation and co-chair of the IETF HTTP working group): “Faster page load for high latency environments, better responsiveness, and a higher security and privacy bar.”

With HTTP/2, users will see as much as a 30 percent improvement in page load times. On the server side, HTTP/2 will lower CPU and bandwidth requirements, McManus said.

Web browsers and servers are ready for HTTP/2 (which was based, in part, on the SPDY protocol). But only around 9 percent of sites currently use HTTP/2, because it’s not as simple as changing the configuration on your web server — or even changing the configuration and then monitoring them more closely than usual.

Microsoft’s IIS (Internet Information Services web server software) won’t support HTTP/2 until version 10 ships with Windows Server 2016. Oracle has only just announced that Java EE 8 will more fully support HTTP/2, for example, and if you use NGINX, make sure you’re using 1.11.0 to avoid issues. (This list of HTTP/2 debugging tools may be useful, and you should check that your server software deals with HTTP/2 security issues disclosed at Black Hat this year).

You’ll also need to make some changes to your code to take full advantage of it, although you don’t need a significant rewrite to get the immediate benefits. You need to get an SSL certificate and move to HTTPS because Firefox and Chrome only support HTTP/2 over TLS using the new Application Layer Protocol Negotiation (ALPN). You need to think about any third-party content you’re calling because HTTP/2 won’t speed that up.

But more than that, you need to think about how you design sites for performance because, as Matthew Prince, CEO of web acceleration technology provider CloudFlare pointed out to us, HTTP/2 turns the principles we’ve used to improve website performance on their head.

Encrypt and Speed Up

HTTP1 1.1 is an inherently synchronous protocol. First, the browser requests the HTML for the page, and once it starts parsing that it requests all the other objects on the page in turn: CSS, JavaScript, then the different media formats and all the other page content. To speed things up, browsers make multiple simultaneous connections per domain. To take advantage of that, websites began splitting resources up onto multiple domains. “With domain sharding, you have www1, www2, www3 and so on, and you say ‘we’ll put all the JavaScript on this one, all the CSS on this one, all the images on this one,’” explained Prince.

HHTP/2 is asynchronous and multiplexes requests on a single TCP connection using binary streams (HTTP/2 is a binary rather than text-based protocol). There’s still an initial request for the HTML, but the requests for all the other resources happen in parallel. That’s faster for the user and more efficient for the server — and it means that domain sharding slows down the site because the browser has to open multiple connections again. (Browsers can optimize which assets they receive first using the stream priority option in HTTP/2.)

Then there’s encryption (which HTTP/2 itself doesn’t require, but every browser that’s implemented HTTP/2 has implemented it with the requirement for SSL). If you want to get a head start on moving to HTTP/2 says Google’s Ilya Grigorik (co-chair of the W3C Web Performance Working Group), “Migrate your site to HTTPS! It’s a prerequisite for HTTP/2.”

“We don’t know what the next great application that server push is going to enable will be, but we do think it is one of those opportunities to have there be a reshaping of how the Internet works”–Matthew Prince, CloudFlare

Web developers have sometimes avoided encryption in the belief that establishing and communicating over an encrypted channel slows down the connection. Modern CPUs and content delivery networks mean that’s rarely true anymore. And as fewer TCP connections per user means fewer server resources per user, the asynchronous requests in HTTP/2 more than makeup for any overhead from encryption.

“In the old HTTP1 world, adding encryption to your page was a performance hit. In the new HTTP/2 world if you want to get the advantage of these new protocols, you have to have encryption. Every piece of good advice becomes bad advice,” Prince pointed out. “If you want to be as fast as possible, you don’t use encryption, you shard domains, you never embed anything on pages, you try and concatenate things into as large files as possible, so you have fewer files. In this world it actually makes sense to slice things up into smaller pieces so you can cache smaller pieces and you can download everything in parallel, you have to have encryption on by default and sharding is the worst possible thing you can do.”

Changing that might be the hardest thing about switching to HTTP/2, Ian Fergusson of security software provider Thawte suggested; “A lot of sites have spent a lot of time trying to increase their speed. Any shortcuts and hacks taken will need to be reversed before implementing HTTP/2.”

Switching to push

The initial benefits of HTTP/2 are very similar to SPDY; CloudFlare supports both although Prince predicted that “SPDY will die off over the next 18 months as people upgrade.” But HTTP/2 has two additional features: header compression and server push.

The headers in every HTTP request are very similar; “there are fields that are repeated thousands of times,” Prince said. HTTP/2 includes a compression dictionary for request and response headers so instead of sending plain text every time; the headers are compressed (and header fields that have been sent once are referred to rather than duplicated). That’s faster for visitors and saves you bandwidth. Prince said CloudFlare saw a 30 percent bandwidth saving in headers when they turned on header compression and Dropbox saw ingress traffic bandwidth halve after turning on HTTP/2 (although they’d used SPDY before, they hadn’t used header compression because of security issues)

From the “Can I Use” Website.

Server push is a more significant change. While the main browsers have supported HTTP/2 for some time, server push is a more recent addition. “Traditionally the browser has said ‘give me something’ then the server responds and sends it back. Server push flips the model so the server can say ‘here are the things you’re going to need’ and proactively push those down the line to the browser. The HTML still takes the same amount of time to render, but all the other resources, the CSS and JavaScript and the JPEGs and PNGs and GIFs are all sent proactively while you’re waiting for the HTML to render,” Prince explained.

That particularly helps dynamic sites and it’s a good match for development patterns like web workers, web hooks and async/await that are starting to become important for JavaScript, as well as for real-time communications like WebRTC, and resource-constrained devices like IoT devices.

Prince expects it to have a broad impact. “AJAX-like JavaScript calls can now get transferred into a much simpler more streamlined function; the server can simply say ‘that query you needed. I’m going to send the request down, so you have that’.”

In some ways it’s like the way push email turned email from a desktop tool into something you could do on your phone in real time, but for a broad range of sites and apps.

“When you think about how much bandwidth and battery power and CPU is wasted on a mobile device by having to poll continuously back and forth to the client; if you flip that around and say ‘I’m here, I’m waiting and the minute you’re ready for me just push down what I need’, that flips the entire model,” Prince explained. “We don’t know what the next great application that server push is going to enable will be, but we do think it is one of those opportunities to have there be a reshaping of how the Internet works.”

But Prince warned that the way server push works currently – you have to put a Link header in the header response from the server – is “kind of clunky and brittle; we’re having conversations with developers to put in place what are more efficient ways to deliver this.”

Expect to see this show up in applications and platforms beyond web servers and browsers; “people are working on WordPress plugins and are playing with it in Rails and in PHP to see how can we use it to build new tools,” said Prince. And McManus noted, “The WHAT-WG [Web Hypertext Application Technology Working Group] is discussing how push can be exposed directly to JavaScript as another promising push use case.”

You also have to think about the tradeoffs between getting better performance and responsiveness on your site by using Server Push versus the bandwidth impact of pushing resources that might not be consumed, especially for mobile users.

“Server push works reliably in browsers, but it can be tricky determining what a website may want to push to get the best benefit,” McManus noted. “The biggest HTTP/2-related gains for mobile users are due to its improved request parallelism on high latency mobile networks. HTTP/2 is also much better at managing the priorities of different objects than its predecessor, and this is very important on slower networks.”

“Developers should tread carefully when experimenting with different strategies with server push as best practices have not yet emerged,” he said. “Effective strategies will depend greatly on site content. Less is more has been the experience so far; aggressively pushing can waste bandwidth. Real User Monitoring is highly recommended to help developers evaluate their site performance. Targeted approaches rather than site-wide policies make sense at first.”

McManus also pointed out that “the optimal impact of push is limited to a fairly short window of time at the beginning of page load so pushing something small and critical, such as a font or a stylesheet, would be a reasonable place to start.”

Grigorik agreed. “There isn’t a right universal answer here. Some applications will want to trade off latency against risk of redundant bytes, others might want to optimize bytes over latency. It depends on the application.”
You also have to think about how you handle third-party content (especially ad networks), which may not yet be available over HTTPS, let alone HTTP/2.

“With third-party content, there are a number of techniques developers can use to get around this issue such as async, preload and preconnect,” Fergusson suggested.

“One important feature of HTTP/2 that helps with the multiple origin problem is connection coalescing,” McManus explained. “Coalescing allows different host names that share the same hosting provider and secure proof of identity to share the same connection, even though they have different host names. The emergence of HTTP/2 Alternative Services as a recent IETF HTTP/2 extension (RFC 7838) also helps with this transition. Every connection that is eliminated has an incremental benefit in performance.”

You might think about switching more things onto your own host rather than pulling them in from external sites. “There are benefits to keeping more assets on the same host. That’s not a requirement, though,” Grigorik pointed out. “And in the worst case — you’re no worse off.”

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Real.

Feature image: “The HTTP/2 Server Implementers Club,” Twitter photo by Brad Fitzpatrick.