HTTP/2 (H2) is the latest version of the HTTP protocol. The original protocol was developed by the HTTP Working Group, which is part of the Internet Engineering Task Force. The H2 specification was published in May 2015, and was based on the work Google did with the SPDY protocol.
The HTTP protocol allows a web browser to fetch web resources. It’s the foundation of data exchange on the web.
H2 maintains a high level of compatibility with previous versions of the protocol, so if a user's browser doesn't support the new protocol, the browser will continue to work by using the previous version, HTTP/1.1 (H1).
Enabling it for GOV.UK was as simple as asking our content delivery network (CDN) provider to switch it on for us. Users do not need to do anything to use H2, as the browser will make the switch.
HTTP/2 aims to improve web performance through a number of new features, including:
- minimising protocol overhead using HPACK header compression
- reducing network latency with the use of request and response multiplexing
- adding support for request prioritisation
The challenges we faced
Before going live, we had to make sure the H2 would improve the frontend performance of GOV.UK. When we started testing H2 we found that the performance of GOV.UK actually got worse, not better. That was the exact opposite of what we were trying to achieve.
The performance was notably worse when we simulated what performance would be like for users with an older device on a slower connection. As GOV.UK needs to be accessible to everyone, regardless of their device or connection, that kind of performance drop was unacceptable.
We decided to pause rollout of H2 until we’d fixed the issue. We eventually worked out that Subresource Integrity and its effect on connection coalescing was causing the slow down. After making some changes under the hood, we were in a position to enable H2 on GOV.UK, confident that we’d see performance improvements.
Measuring performance improvements
Using synthetic web performance testing, we looked at the impact moving to H2 had on GOV.UK users.
Here I’ve picked out 3 specific setups many of our users may use to browse. The data shows results from 18 pages from different areas of GOV.UK.
Low specification mobile device on a slow (2G) connection
First, we used SpeedCurve to test what users on a low specification mobile device using a slow, 2G connection would experience on GOV.UK.
We saw an improvement in the following web performance metrics:
- page load time dropped by 6 seconds
- start render time dropped by 2.5 seconds
- SpeedIndex dropped by 3.3 seconds
- First CPU Idle dropped by 4 seconds
So for users on legacy devices with a slow connection, H2 has improved both page load time and reduced the load on the CPU. Less load on the CPU will likely result in less energy used, giving the device longer battery life.
Medium spec mobile device on a semi-fast (3G) connection
Next, we used SpeedCurve to test what users with a medium specification mobile device on a 3G connection would experience.
We saw an improvement in the following metrics:
- page load time dropped by 1100 milliseconds
- start render time dropped by 700 milliseconds
- SpeedIndex dropped by 750 milliseconds
- First CPU Idle dropped by 620 milliseconds
These improvements may not sound as dramatic as those we saw on the low spec devices, but it’s still a considerable improvement.
High specification desktop device on a fast wired connection
Finally, we tested what users on a desktop computer with a fast wired connection would experience.
We saw an improvement in the following metrics:
- page load time dropped by 100 milliseconds
- start render time dropped by 100 milliseconds
- SpeedIndex dropped by 100 milliseconds
- First CPU Idle dropped by 100 milliseconds
Now 100 milliseconds doesn’t sound like a huge amount, but when you consider the pages are loading in less than a second, that’s a 10% improvement in the metrics examined!
What’s next for GOV.UK performance
Switching GOV.UK to HTTP/2 should improve performance for most of our users, no matter what device they’re using or how quick their connection is. It also means we can use future improvements to the HTTP protocol like HTTP/3 and QUIC when those are ready.
We’ll continue to look for areas to improve web performance. It is vital that web performance isn’t a barrier to entry for users, as the information our service provides is critical.
