Core Web Vitals as a budget, not a score
LCP, INP and CLS, what each actually measures, and why the lab number and the field number disagree.
Largest contentful paint is when the biggest thing above the fold has rendered, usually an image or a heading, and usually delayed by server think time, a render-blocking resource or an unoptimised image. Interaction to next paint measures the worst realistic delay between a user acting and the screen updating, which is main-thread contention, most often hydration or an oversized event handler. Cumulative layout shift is content moving after paint: images without dimensions, fonts swapping with different metrics, banners injected above existing content.
Lab data is one run on synthetic hardware and it is repeatable, which makes it good for catching regressions in CI. Field data is what your actual users on actual devices experienced, and it is the only thing that reflects reality, including the ones on a five-year-old Android on a bad connection who are already at the ninety-fifth percentile. Optimising the lab score until it is green while field data stays poor is a well-trodden way to spend a quarter achieving nothing.
A metric with no threshold and no owner is a chart. Write the budget as a number at a percentile on a named page, put it in the build, and decide in advance who is called when it breaks. That converts performance from something everyone agrees is important into something that blocks a merge, which is the only version that survives a deadline.
You should now be able to
- Say what each vital measures and what typically causes a bad one
- Explain the difference between lab and field data
- Turn a metric into a threshold someone owns
Loading…