Page Speed Insights (Lighthouse) went through an upgrade on 1st June 2021 - what changed and how will it affect you?

Page Speed Insights is now running Lighthouse 8.0 and let me tell you, the changes that have been made to the scoring are going to really ruin some of your scores!

With that being said, if you aren't building a site with JavaScript in the browser you will probably actually benefit!

In a nutshell: It is time to ditch those heavy front-end frameworks for sites that you want to rank well!

Who is this post for?

People building websites that need to rank well in Google.

With the upcoming Web Vitals update to Google Search Algorithm starting to be rolled out, and being rolled out fully by the end of August, it is essential you start working on fixing these things now if you rely on SEO for traffic.

And unlike other articles on the subject I am going to assume you have at least heard of and used Page Speed Insights or a similar speed checking service before.

With that being said I will refer to all of these services under the term "Lighthouse" so I better give you a super quick bit of info:

Lighthouse in 20 seconds

For those of you who don't know, Lighthouse is the engine that powers page speed insights, web.dev/measure, GT Metrix etc.

It is probably the most widely used testing utility for website load speed.

OK so what have they changed this time?

The score weightings have been updated once again.

V6 / V7 scoring

First Contentful Paint        15%
Speed Index                   15%
Largest Contentful Paint      25%
Time to Interactive           15%
Total Blocking Time           25%
Cumulative Layout Shift        5%

V8 scoring (new scoring)

First Contentful Paint        10% -
Speed Index                   10% -
Largest Contentful Paint      25% 
Time to Interactive           10% -
Total Blocking Time           30% +
Cumulative Layout Shift       15% +

Comparison

metric	v6 + v7 weight	v8 weight	change
First Contentful Paint (FCP)	15	10	-5
Speed Index (SI)	15	10	-5
Largest Contentful Paint (LCP)	25	25	0
Time To Interactive (TTI)	15	10	-5
Total Blocking Time (TBT)	25	30	5
Cumulative Layout Shift (CLS)	5	15	10

In English please, these metrics mean nothing to me!

In short, the focus has shifted to when the page is actually ready to use, rather than when things first start appearing.

It is actually a little more complex than that and is beyond the scope of this post but here is a summary of what you need to know:

JavaScript heavy sites are going to take a hit.

If you are downloading 100kb of JS just to render the above the fold content (the initial content you can see without scrolling) then your score is likely going to go down (again! It is time to take the hint! Stop using React for brochure sites unless you know how to tree shake and code split!).

This is linked to the "Total Blocking Time (TBT)" metric. It measures how many tasks within your JS take longer than 50ms, then it adds up any tasks that take longer minus the original 50ms allowance.

To make that more clear:

Task A: 30ms (less than 50ms so 0ms added to TBT)

Task B: 55ms (55ms - 50ms, so 5ms added to TBT)

Task C: 10ms (less than 50ms again so TBT is still 5ms)

Task D: 95ms (95ms - 50ms, so 45ms added making TBT 50ms total).

So the TBT would be 50ms in the above scenario.

Important note: This may seem super easy to pass, but consider that "mobile first" is Google's policy. So when you run a report on Page Speed Insights, the Lighthouse tab in Chrome etc. look at the mobile scores.

For mobile there is throttling applied to simulate a mid-tier mobile phone (a 4x CPU slowdown) and a slow 4G connection.

You can find out more info about throttling in Lighthouse here

This is why I do not recommend looking at pingdom.com and GT Metrix (unless you have a PRO account), they both monitor desktop speeds and it is really easy to get a decent score there.

Inlining critical CSS is even more important

The critical CSS is all the CSS required to render the above the fold content.

You need to inline this in a <style> tag within the document so that the page can load and display the page without needing a second network request to have completed.

This helps improve Largest Contentful Paint and minimise Layout Shifts.

Make sure you stop layout shifts

People tend to get confused by this one. Basically if you see something load on the page, it should not move, get larger or smaller, unless it is a direct result of pressing a button etc.

For this reason I would suggest you read this post on how to stop images causing a Layout Shift:

Quick Tips: How to fix "Image elements do not have explicit width and height" in Page Speed Insights / Lighthouse

InHuOfficial ・ Jun 6 '21 ・ 6 min read

#webdev #html #css #beginners

If you are using JS to fetch data then make sure you have a correctly sized placeholder for it...but if you are doing that for above the fold content you are already in trouble, as for the fastest rendering all above the fold content should be served within the initial HTML.

In fact the above the fold content should fit into 14kb for insane speeds, 42kb for super fast speeds or 98kb for good speeds (kind of). It is all to do with how TCP works and something called TCP slow start...but that is for another post.

You still need to ensure your Largest Contentful Paint is good

Largest Contentful Paint (LCP) is actually quite straight forward.

Say you have a page with 4 elements that appear above the fold. If one of those elements takes up 40% of the space (element A) and the other 3 each take up 20% (elements B,C and D) then element A would be the element that is the Largest Paint element.

The score is based on how quickly that element is rendered to the page. The quicker that element appears the better your score.

Now we have covered inlining critical CSS within the HTML so we don't need to wait for an additional network request before we can render the page, but what if that element is an image?

One technique is to use a Low Quality Image Placeholder (LQIP). Yet again the detail of how to do that is for another post but in essence you use a small very low quality image (say 32px by 18px for a 16:9 aspect ratio) and then inline that using a data URI.

<img src= "data:image/jpg;base64,[data encoded with base64]" alt="your alt" width="1600" height="900">

You then swap in the actual image using JS once the core page content has loaded.

There are loads of different ways to achieve this and so it deserves its own post as I said, the idea of this post is to give you things to research yourself and suggestions.

Things that don't affect your score but to be mindful of

Nearly every major update that has been released in the last few months has had an update to do with Content Security Policies (CSP).

This update is no exception.

They have introduced an audit called "csp-xss" under "Best practices" (which isn't on Page Speed Insights but is available in Lighthouse in developer tools etc.).

This still has no scoring weight associated with it but you should start thinking about it now as they keep putting more and more effort into this.

If you want to see the state of your sites security headers may I suggest using https://observatory.mozilla.org/ to test your site and start learning about headers that protect your clients from malicious actions.

Conclusion

The idea of this post was not to tell you how to fix everything, but rather to let you know what has changed and what it means for you, even if you don't understand everything about Page Speed Insights.

Lighthouse is trying to steer you away from using heavy JS frameworks for brochure sites or even e-commerce sites where page speed is essential and search rankings are important.