Fun with HTTPS/H2 Part 2

Maximum warp engage! Let’s put H2 through a simple performance test. I set up a full page Mapbox GL JS map based on my Quality of Life embed over HTTP1 and H2, ran 10 tests on each, and averaged the results.

On a maximized 1080p browser there were 34 requests. DOM Content Load fires when the HTML document is loaded and parsed, Load fires when dependent resources (CSS, JS, images, etc.) have finished loading, and Finish happens when any non-document stuff finishes loading, like map tiles and other AJAX requests. The test is run on my desktop computer over a wired network.

Perpare to be…underwhelmed.

This surprised me. H2 was consistently faster, but not in a way you’d notice. I get irrationally tickled by the tiniest bumps in page speed, but this falls below my tickle bar.

Ha! I’ll try remote debugging my Nexus 5 on LTE. The high latency of mobile networks will have H2 eating H1’s lunch!

Eh. A little better. H1 on 1-2 bars of LTE finishes on average in 12.14s, H2 in 10.53s. That’s a tad more significant, but the variability of my results (LTE bars fluttering and the magic of constantly scaling phone CPUs) doesn’t inspire faith in those figures.

There are some caveats. This site is still optimized for H1. JS and CSS are concatenated, which isn’t recommended for H2 (there’s an exception for <14kb files due to packet size, which I file under life is too short). With WebGL rendering, CPU rather than network speed may be the bigger performance factor. This site, with it’s 1.23s load time over HTTP1, didn’t leave a lot of wiggle room for improvement. And loading things over a constantly varying network introduces a lot of noise.

My results seem to be consistent with others I’ve seen: performance does improve, but the amount varies, and caveats abound. H2 is a worthwhile upgrade, and if you’re going HTTPS anyway, I can’t see a downside. But the onus of web performance still sits squarely on the shoulders of the developer.