Hacker News Reader

Comment by henriquez | Hacker News Reader

These are useful performance indicators for sure, but I don't understand how these are different than the metrics already built into Chromium's "Lighthouse" page speed audit (the "Audits" tab in the inspector).

Is the difference now that they will be more heavily weighed in search engine ranking? The article wasn't super clear on this, and the explanatory links seemed to push towards drinking a lot of Google kool-aid (eg. to measure the Core Web Vitals you must use Chrome UX report, and to do that you must use Google BigQuery, and to do that you must create a Google Account _and_ a Google Cloud Project. Wow.)

On closer inspection this whole thing is just a thinly veiled advertisement for GCP. No thanks.

View on HN

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.

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/), 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.

@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.

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

> to measure the Core Web Vitals you must use Chrome UX report

No, you just need this bit of javascript: https://github.com/GoogleChrome/web-vitals

Reply on news.ycombinator.com