Wire Core Web Vitals into CI or stop pretending you care about them

Lighthouse in the browser after launch is not a Core Web Vitals strategy. It is a Core Web Vitals audit — and audits, by definition, come after the damage is done. On every Next.js engagement I run, LCP, INP, and CLS budgets are enforced in CI before a pull request can merge.

Here is the exact shape of what I wire up.

Lighthouse CI on every pull request

Lighthouse CI runs against a Vercel preview URL for every PR. The budget is expressed in a lighthouserc.json committed to the repo, with hard thresholds: LCP under 2.5s, CLS under 0.1, TBT under 200ms. The job fails the pull request if any threshold is breached — same as a failing unit test.

Real-user monitoring — not just synthetic

Synthetic Lighthouse scores are directionally useful but do not reflect real users on real networks. I pair the CI budget with a lightweight RUM library that reports LCP, INP, and CLS to a collector — Vercel Speed Insights on hosted projects, or a self-hosted Cloudflare Worker on more restrictive stacks.

The three fixes that pay for themselves

1. Font strategy up front. Every custom font is preloaded with the correct font-display and the exact character subset. Nine times out of ten this is the largest single LCP win.
2. Hero images without layout shift. Every above the fold image ships with explicit width and height and lives on the CDN in AVIF plus WebP. This is what CLS budgets actually protect.
3. Third-party scripts on the leash. Every analytics or A/B tag is loaded through Next.js next/script with the right strategy — lazyOnload or afterInteractive — never in the head.

Why this changes the conversation

When Core Web Vitals are a CI gate, the performance conversation stops being a launch-week fire drill. It becomes part of the pull-request review, same as type safety or accessibility. That is the only version of a Web Vitals strategy that survives real product pressure.