L5 · Non-functional depth
L5Go deeper4 min read

Frontend performance and Core Web Vitals

What a real user experiences before the page is usable. LCP, INP, CLS, and how to measure them in a way that reflects real devices rather than your laptop on office wifi.

Core Web Vitals are the three metrics Google uses to judge whether a page feels fast and stable to a real visitor. For a QA engineer, they turn a vague complaint like "the site feels slow" into three numbers you can test, track, and gate a release on.

They matter for two blunt reasons: Google folds them into search ranking, and they correlate directly with whether users stick around or bounce. Skipping them means shipping a page that passes every functional test while still frustrating everyone who loads it.

What each metric actually measures

Largest Contentful Paint (LCP) times how long it takes the biggest visible element, usually a hero image or heading, to render. A good score is under 2.5 seconds. Anything past 4 seconds is classed as poor.

Interaction to Next Paint (INP) replaced First Input Delay (FID) in 2024. It measures the latency between a user's click, tap, or keypress and the next visual update. It is sampled across the whole page visit rather than just the first interaction. Under 200ms is good; over 500ms is poor.

Cumulative Layout Shift (CLS) scores how much visible content jumps around unexpectedly as a page loads. A late-loading banner that pushes a button down after the user has already aimed for it is exactly what CLS penalizes. A score under 0.1 is good; above 0.25 is poor.

How a QA engineer actually tests these

Core Web Vitals show up in two flavors, and mixing them up leads to false confidence:

  • Lab data (synthetic): Lighthouse, WebPageTest, or Chrome DevTools run a scripted page load in a controlled environment and report LCP and CLS instantly. INP needs real interaction, so lab tools simulate it or estimate it via Total Blocking Time as a proxy.
  • Field data (real user monitoring): the Chrome UX Report (CrUX) and Google's PageSpeed Insights aggregate what actual visitors experienced, across real devices and real network conditions. This is the data Google's ranking system uses.
  • In-app instrumentation: the web-vitals JS library can be dropped into a page to capture LCP, INP, and CLS directly in the browser and ship them to your own analytics or a monitoring dashboard.

A QA engineer should run Lighthouse in CI on every pull request to catch obvious regressions before merge. Field data in production should be watched separately, since lab results on a fast CI runner routinely look better than what a real visitor on a mid-range phone gets.

Building this kind of gate into a pipeline pairs well with a broader CI/CD strategy for test suites.

track-vitals.js
import { onLCP, onINP, onCLS } from 'web-vitals'

onLCP((metric) => sendToAnalytics('LCP', metric.value))
onINP((metric) => sendToAnalytics('INP', metric.value))
onCLS((metric) => sendToAnalytics('CLS', metric.value))

A worked example

Consider a checkout team that shipped a new "recommended add-ons" carousel above the payment form. Functional tests passed and the page looked fine in a quick manual check. Two weeks later, support tickets mentioned people accidentally clicking the wrong button on mobile.

Field data in PageSpeed Insights showed CLS had jumped from 0.04 to 0.31 on the checkout page. The carousel's images loaded without reserved dimensions, which shifted the payment button down mid-tap. The fix was a one-line width/height attribute on the carousel container. QA then locked that in with a Lighthouse CI budget so any future regression would fail the build automatically.

That kind of regression is easy to miss because it never throws an error. It only shows up as a shift in a percentile of real user data, which is why comparing percentiles rather than averages matters just as much for performance metrics as it does for response times.

Where this fits in a QA process

Core Web Vitals sit alongside functional and load testing, not instead of them. A page can be functionally correct and still fail users through slow paint or jumpy layout. A page can also be fast in isolation but degrade under concurrent load, which is where load profile work and dedicated performance testing tools come in. Treat Vitals as one more assertion in the pipeline, not a separate concern owned by a different team.

FAQ

Questions people ask

Can Core Web Vitals be tested in a staging environment?

Lab metrics like LCP and CLS, yes, since they only need a scripted page load. INP is best validated with real interaction, so staging results should always be cross-checked against field data once the change ships.

Does a good Lighthouse score guarantee good field data?

No. Lighthouse runs on a single simulated device and network profile. Field data reflects the full spread of real users' hardware and connections. A page can score 100 in Lighthouse and still show poor CLS in CrUX if real users hit a slow third-party script.

How often should Core Web Vitals be checked?

On every pull request via a CI budget for lab metrics, and continuously in production via field data, since real-world regressions can appear from a third-party script change with no code change on your side at all.