Core Web Vitals became a standing quality bar for web teams, and 2026's mature practice runs them in CI: not as a one-off audit, but as a per-pull-request regression check with thresholds derived from real user data. Lab metrics catch the big swings; field data remains the score that matters.

Measure the real metrics

Track largest contentful paint, interaction to next paint, and cumulative layout shift against thresholds on representative pages. Lab measurements in CI are not field data, but they reliably catch regressions introduced by a specific change.

Control the environment

Noisy shared runners produce variance that drowns real regressions. Run performance jobs on consistent hardware, with warm caches where appropriate, and compare against a rolling baseline rather than absolute numbers.

Testing illustration
Illustration: Testing — photo via Unsplash

Budget, then enforce

Set performance budgets per page type and fail the build when a change exceeds them. Budgets without enforcement become documentation; budgets in the pipeline become design constraints that prevent regressions from being written.

Building the CI check

Run Lighthouse or an equivalent headless measurement against a production-like build on every pull request that touches rendering paths, comparing against a rolling baseline rather than absolute numbers — lab environments drift, and relative regressions are the signal. Focus budgets on the three vitals (LCP, INP, CLS) with a small tolerance band to absorb noise, and fail the build only on meaningful regressions so the gate retains credibility. Pair it with bundle-size and third-party-script budgets, which catch most regressions before rendering.

From lab to field

Lab runs predict; field data (CrUX, real user monitoring) adjudicates. After release, compare field vitals per route and per device class — the mobile long tail is where the averages hide failures. When lab and field disagree, treat it as a discovery prompt: unmeasured interactions, A/B variants or third-party scripts often explain the gap. The loop closes when field regressions become new CI test cases.

Testing illustration
Illustration: Testing — photo via Unsplash

Key takeaways

  • Compare against a rolling baseline; band tolerances absorb lab noise.
  • Add bundle and third-party budgets to catch regressions earlier.
  • Adjudicate with field data per route and device class.

Final thoughts

Performance in CI works when it behaves like any other regression suite — relative comparisons, meaningful thresholds and a feedback loop from field data back into the checks that failed to catch it.

Sources & further reading