For years, Pagespeed has been the standard of speed/performance.
But after the launch of the Core Web Vitals metrics back in 2020, and Google later announcing that it would be used as part of the page experience algorithm, it was confusing to determine what you should defer for.
Core Web Vitals has evolved and has now been launched on browsers other than Chrome, due to its importance.
But Pagespeed(Lighthouse) is still almost unanimously used as the main goal for everyone, especially non-developers.
Why are folks still focused on getting good scores even as Lighthouse isn’t directly used as a benchmark and has critical issues?
One of the reasons is that Pagespeed is still marketed and pushed as game-changing by some popular tools, because they rely on it still being the benchmark as their main appeal.
For example, many WordPress plugins offer features such as Delay JavaScript, which can improve a site to the Pagespeed mobile green range, not just theory, but in practice.
But, under the hood, they aren’t doing exactly what you think they are doing.
Delay JavaScript is a feature that delays all your JavaScript, getting you a virtually 0 TBT(Total Blocking Time), which hold 30% of Lighthouse’s total scoring. And because of Lighthouse’s current issue with identifying every request that loads before the LCP/FCP as render-blocking, this feature will have an even greater positive impact on the LCP and FCP metrics(hold 35% of scoring).
Does it improve your TBT? Unlikely, because the potential longer than 50ms render-blocking tasks will simply load after the initial cold-loading. The tasks aren’t being improved, yielded, or using any other performance technique.
Does it improve LCP/FCP as much as it shows on Pagespeed? No.
Does it give the perception that everything is solved after enabling it? Yes.
This is not an assumption; it’s real.
Lighthouse calculates faster LCP metrics when the TTFB(Time to First Byte) is high, which leads to significantly faster LCP metrics than the real metrics. TTFB is the main bottleneck of every site, and even so on WordPress, with only 24% of all in the “good” range(mobile).
Because a lot of sites reach great improvements after enabling this feature, and their poor TTFB is ignored(or not displayed correctly), they simply disregard the “needs improvement” or “poor” Core Web Vitals metrics.
This scenario doesn’t only apply to WordPress, but it’s mostly seen there for the reasons above.
It is also worth noting that these issues are quite new, one from late 2024 and the other from 2025. Many folks aren’t aware of how they influence their pagespeed tests.
Can a site have a legit +90 score but still have a subpar experience?
Yes, especially for WordPress sites as explained above.
Does this explain why some technologies have a lower median Lighthouse score yet much better Core Web Vitals median metrics?
Likely. In one of the Lighthouse issue, Ivan Kulov, Framer’s Staff Perf Engineer, says:
“Developers are forced to pick between doing deep research (and convincing stakeholders that Lighthouse isn’t accurate) – or making the site slower for real users just to get the score higher.”
There is an incentive to degrade real performance.
Shopify is one of the examples of this divergence, with a poor median Lighthouse score but industry-leading Core Web Vitals metrics.
Will Lighthouse and Core Web Vitals converge and have the same standards?
As of today, they have completely different standards, even setting aside their perceived use(lab data vs field data). For example, Lighthouse considers desktop LCP above 1.2 seconds as “need improvement”, while Core Web Vitals considers 2.5 seconds “good” metrics.
