3 ms·

Lighthouse is a lab-metric system while Web Vitals is a "real-user-metric" system. Both approaches are valid, and have their pros and cons. Generally, lab metr

Lighthouse is a lab-metric system while Web Vitals is a "real-user-metric" system. Both approaches are valid, and have their pros and cons. Generally, lab metrics are convenient because you can run them whenever you'd like including before deploying to prod. But they can never tell you the ground-truth of what is really happening out there that real-user-metrics provide. E.g. the FID metrics only make sense when someone actually interacts with your site. Lighthouse cannot know when people would interact and thus cannot calculate the metric.

kaycebasques 6y ago
In Google documentation you'll hear this distinction described as "lab data" versus "field data": https://web.dev/how-to-measure-speed/#lab-data-vs-field-data https://web.dev/how-to-measure-speed/#lab-data-vs-field-data
henriquez 6y ago
Thanks for the clarification, that makes sense. It is ironic that the vast majority of these performance issues are caused by render-blocking and CPU-sucking JavaScript, and so the recommended approach is to install yet another client side JS library (https://github.com/GoogleChrome/web-vitals/ https://github.com/GoogleChrome/web-vitals/), which appears to only work in Chrome, and then use the library to post client side performance data to Google Analytics (though to be fair it could be any analytics). "How badly are all your JS libraries slowing down your page? Find out with this one weird JS library!" This seems like one of those things where if you get to the point where you need this, you're already in too deep.
- igrigorik 6y ago
  @cramforce nailed it. One thing I'll add.. I would strongly encourage everyone to collect "field" (real user measurement) data for each of these metrics via their own analytics, as that'll give you the most depth and flexibility in doing root cause analysis on where to improve, etc. The mentions of CrUX and other Google-powered tools are not to create any dependencies, but to help lower the entry bar for those that may not have RUM monitoring already, or will need some time to get that in place.. For those users, we offer aggregated insights and lab-simulations (Lighthouse) to get a quick pulse for these vitals.

kaycebasques 6y ago

In Google documentation you'll hear this distinction described as "lab data" versus "field data": https://web.dev/how-to-measure-speed/#lab-data-vs-field-data https://web.dev/how-to-measure-speed/#lab-data-vs-field-data

henriquez 6y ago

Thanks for the clarification, that makes sense. It is ironic that the vast majority of these performance issues are caused by render-blocking and CPU-sucking JavaScript, and so the recommended approach is to install yet another client side JS library (https://github.com/GoogleChrome/web-vitals/ https://github.com/GoogleChrome/web-vitals/), which appears to only work in Chrome, and then use the library to post client side performance data to Google Analytics (though to be fair it could be any analytics). "How badly are all your JS libraries slowing down your page? Find out with this one weird JS library!" This seems like one of those things where if you get to the point where you need this, you're already in too deep.

igrigorik 6y ago
@cramforce nailed it. One thing I'll add.. I would strongly encourage everyone to collect "field" (real user measurement) data for each of these metrics via their own analytics, as that'll give you the most depth and flexibility in doing root cause analysis on where to improve, etc. The mentions of CrUX and other Google-powered tools are not to create any dependencies, but to help lower the entry bar for those that may not have RUM monitoring already, or will need some time to get that in place.. For those users, we offer aggregated insights and lab-simulations (Lighthouse) to get a quick pulse for these vitals.