Why isn't HTTP/2 improving the pagespeed score

Why isn't HTTP/2 improving the pagespeed score

Sometimes a LinkedIn post of mine is leading to new questions as well. This time: "How do you get a high PageSpeed score when a site is using HTTP/2?"

In this case, it was a Wordpress website where HTTP/2 was enabled. Despite HTTP/2 support the PageSpeed score did not improve. This led to the following question.

Hi Erwin, question. How do you get a high PageSpeed Insights score when a site is using HTTP/2? I can't seem to improve the PageSpeed score because of render-blocking JavaScript / CSS.

Earlier, I wrote a LinkedIn post about the impact of TTFB on your PageSpeed score and if HTTP/2 should be enabled by default by hosting providers. As HTTP/2 was mentioned, this led to new questions.

When does HTTP/2 improve pagespeed?

HTTP/2 is cool, but isn't likely to perceptibly improve things in real life within the average website. This is because the average website often has more severe bottlenecks. For example, Wordpress (and plugins) will often bundle CSS and JS resources. Despite HTTP/2 being around for a while, people are still using such plugins.

As a result, the amount of requests that are render blocking are likely to be below the maximum amount of simultaneous requests already. Within HTTP/1, concurrent requests could vary between 2 and 8 per domain, depending on the browse that is being used. Although HTTP/2 is resulting in virtually unlimited concurrent requests per domain, the impact in such scenario won't be that noticeable.

The impact of HTTP/2 will be different though when for example:

  • having Magento 2 with a lot of simultaneous JS requests;
  • having a product listing page with a lot of images and no JS or native image lazyloading.

HTTP/2 and render blocking resources

The impact of HTTP/2 could be limited due to the presence of other bottlenecks, such as render blocking resources. Where you won't read anything about HTTP/1 versus HTTP/2 as a recommendation within a Google PageSpeed Insights audit, chances are you stumbled on the render blocking resource recommendation once or twice.

Moreover, even with HTTP/2 enabled, the perceived performance will be as good as the single worst render blocking CSS or JS (depending on size + network latency). This will impact visual metrics -and thus user engagement and conversion- such as:

  • First Contentful Paint;
  • First Meaningful Paint;
  • Largest Contentful Paint;
  • SpeedIndex.

Render blocking JavaScript

Although these metrics will benefit from fixing any render blocking resource, you really want to fix render blocking JavaScript. This is because JavaScript is both render blocking as well as parse blocking.

Your goal should be to defer or move all JavaScript, even inline JavaScript. Next, reduce the CSS resources in the head to only load the CSS that is needed for compositing above-the-fold elements. This could be done by inline critical CSS. This could lead to new challenges such as longer content download, style inheritance or cumulative layout shifts and thus bad UX, but obviously is out of the scope of HTTP/2.

If inlining critical CSS is too much of an effort, then at least reduce the amount of render blocking stylesheets to only those stylesheets needed for compositing above-the-fold elements. Codesplit or lazyload other CSS, for example using Filamentgroup Inc's CSS solution.

HTTP/2 conclusion

Depending on your hosting provider, your website might already load via the HTTP/2 protocol. HTTP/2 is one of of many pagespeed and performance improvements you get for free.

However, don't expect magical things from HTTP/2 alone, at all times. It will be able to make a difference when you know what is happening within your website as well as how to use it in your advantage.