I was thinking recently about the weights used to produce the final Lighthouse score. If you hop over to https://googlechrome.github.io/lighthouse/scorecalc/ you can see that these are
From my observation FCP and LCP are often identical. I struggled to find a solid basis for the heuristic that places much more value on LCP. But, I assume these weights are coming from the HTTP Archive as suggested in their documentation. But on https://httparchive.org/reports/loading-speed I don't see LCP even mentioned. So where is the data on it coming from that then drives the weight or crafts the heuristic.
Full disclosure: I work on the Google Chrome team on Core Web Vitals and closely with the Lighthouse team.
If you hop over to https://googlechrome.github.io/lighthouse/scorecalc/ you can see that these are
- 0.1 : FCP, SI, TTI
- 0.15 : CLS
- 0.25 : LCP
- 0.3 : TBT
That is incorrect. Those is the v8-v9 Lighthouse weightings, we're now on v12 and use the following:
Now let's explain why:
We have lots of docs on the Core Web Vitals:
We think the 3 CWVs are the best measures of measuring actual user experience and if you were to only look at 3 metrics, then those are the ones to concentrate on!
So in an ideal world, Lighthouse would reflect than and be weighted 0.333/0.333/0.333 for those. And the v12 weightings are not far off this to be honest! And certainly closer than the v8/v9 weightings you showed where CLS (fairly new at that time) was under weighted.
However, while LCP is important (and if only measuring one loading metric, then measure that!), FCP and Speed Index are also of value. Hence they get a small percentage in the weighting too. Not as much as LCP, but not nothing either.
From my observation FCP and LCP are often identical.
That may be the case for some sites, but in MANY cases it is not true.
I struggled to find a solid basis for the heuristic that places much more value on LCP
We wanted to chose one metric to represent "loading" speed and in our opinion LCP does that. When the "main content" is loaded, the user can start interacting with the page. The "main content" is often the largest piece of content — not always, but often. On the other hand, when the first paint happens (FP), or even the First Contentful Paint (FCP) the page may still not be that useful. And similarly waiting of everything to finish, would measure many perfectly useful pages as being slower then their user-perceived speed.
Now the above weightings, while close to the Core Web Vitals, do have a slight imbalance compared to the Core Web Vitals, it's true:
Though it's arguable that SI could be considered Loading and partially Visual Stability so maybe should be split between them balancing it up a little but still biased towards Loading.
Anyway, Lighthouse, like many (if not all!) lab performance measuring tools, is primarily good at measuring loading performance. This is partially a reflection on history (that was what we used to concentrate on, in the past, so a lot of tooling has grown around that over the years, while the other two are newer!), and partially a reflection of what those tools ever can be good at.
Post-load CLS is a real thing where content loads late as you scroll and interact with the site, but Lighthouse doesn't measure that.
Similarly INP is not possible to measure fully in the lab and TBT is proxy for that, that can be useful, but also sometimes can't. See this Twitter thread I posted recently for more details.
So Lighthouse concentrating more on what it's good at (loading metrics), again makes sense. This explains why the score is a little biased towards Loading.
Don't over fret about the Lighthouse score
So hopefully that explains the relational of the current weighting. But I'd also like to say that people often over-index on the Lighthouse performance score.
A green 100 is a lovely thing to get but the score is just a summary indicator of possible page performance issues, because of the limitations of lab tooling. Measuring the Core Web Vitals in the field is MUCH more important as it reflects how users are actually experiencing your site.
Who cares if you have a perfect, green Lighthouse 100 score, if the field measures show the users have a much worse experience?
On the other hand if users are having great experiences, despite a Lighthouse score of 60, then you've less to worry about. There's things you can improve, but overall you're doing great already.
This is why PageSpeed Insights shows the field metrics FIRST, and the Lighthouse Lab metrics beneath are used to give further insights into how to improve those.
So it's good to be inquisitive about the decisions tooling authors make, and was happy to give my insights into those decisions, but try to remember the ultimate reason why we're looking at things like the Lighthouse Performance score and make sure you're not losing sight of that.