Search code examples
pagespeedpagespeed-insights

What are causes of the differece between CoreWebVitals assessment and PageSpeen Insights performance grade?


While testing different sites with PageSpeed Insights test I experience same phenomenon, which I can't explain by myself:

There are multiple URLs passing Core Web Vitals assessment, but having all red metrics and low Performance grade, like on the screenshot:

enter image description here

Yes, I know, Core Web Vitals assessment is calculated by aggregating of loading times of Chrome users in the last 28 days. But this remains unexplained for me: how can it be, that loading metrics have such a huge difference between Core Web Vitasl assessment and performance diagnose?

  • LCP: diagnose is around seven times higher
  • FCP: diagnose is nearly three times higher
  • CLS: diagnose is more than five times higher

And: it is not a single case or single URL. I see this behavior often, too often to think it could be an accident.

Could somebody explain me these differences?

PS: there is a meaning about this difference, which would excellently explain it, but I very doubt in it. The meaning is:

  • Core Web Vitals assessment checks only above-the-fold area, the first, initial viewport of the page,
  • PageSpeed Insigts performance test displays data for the whole page until onLoad event.

Solution

  • There are a number of possible differences, much of which is covered in the Goggle Chrome team's guidance, for example in out Core Web Vitals workflows with Google tools doc and in each of our Optimize guides (LCP, CLS). Full disclosure, I helped write these.

    First up, as Rick alluded to in the comments make sure you are comparing like for like. Often real-user data is not available for specific URLs so the top section may be for the origin as a whole rather than just that URL.

    Next, Lighthouse does a simiulated load, under specific conditions. It also does a cold load of the above the fold content only, without interaction.

    Looking at this example specifically (and assuming it is URL-level data, or at least representative of that URL):

    LCP and FCP can be a lot faster (or slower) for real users than for Lighthouse depending on:

    • How representative the Lighthouse conditions are to your users environments. Lighthouse uses a fairly represenatitive set up on a global scale, but you users may all come based on faster or slower devices.
    • Cold load visits versus repeat visits/partially cached visits. It a user revisits a page then it will typically load a lot faster as assets are cached (particularly if going back, when the page is in memory). Or if a visitor visits the home page, and then a secondary page they might have many of the assets cached if they are reused from the home page.
    • If a page is cached in your infrastructure (e.g. in a CDN) so it's served quickly on repeated Lighthouse runs, but slower to users who only visit it once infrequently.
    • How users come to your site. If clicking on an add or a bit.ly link they may go through redirects which may slow it down. Lighthouse typically is tested against the actual URL.
    • How far users are away. PSI tries to test from your location with data centres in America, Europe, and Asia. If your servers are in Europe and PSI uses a Europe data centre, but a large proportion of your users are in Australia then the real users may get a very different (slower) experience than the Lighthouse test.
    • Are users getting different content? For example is Lighthouse showing a slow-loading cookie banner as the LCP element but many users do not see that as have accepted it?

    For CLS differences here typically indicate post-load CLS as discussed in our guidance. CLS is measured throughout the life of the page and while it's true CLS is often bad during page load (which is all that Lighthouse measures), some can happen later. For example, if you scroll and lazy-loaded images or ads pop in without reserved spaces. I often see scroll issues with poorly implemented sticky headers too. Interacting with a page can also cause CLS if it happens after the 500 ms grace period for an interaction.

    So in summary Lighthouse may or may not be representative of how real users experience your site.

    Does this mean Lighthouse is useless? Absolutely not! Lighthouse is incredibly useful to identify potential performance issues. For loading issues (FCP and LCP) these can be worse than real life since it does a simple, cold load of the page. But optimizing the worse case scenario will benefit your site!

    For CLS (and similarly for INP), this is more a limitation of what a simple page load does. So where this matches you can use its advice to improve the real life metrics. Where it doesn't, you at least have eliminated load issues as the likely cause and can look where else these might be slow.