The Core Web Vitals Checklist We Use Before Every Launch

We run the same checklist against every site before it ships, whether it is a brand-new build or a redesign. It is built around the three field metrics Google actually measures - Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift - because lab scores that do not translate to real user data are not worth much.

1. Fix Largest Contentful Paint first

LCP measures how quickly the largest visible element - usually a hero image or heading - renders. We check that the LCP image is served in a modern format (WebP or AVIF), sized correctly for the viewport, preloaded with fetchpriority="high", and never lazy-loaded above the fold. We also confirm the server response itself is fast, since a slow time-to-first-byte caps every other optimization.

2. Get Interaction to Next Paint under control

INP measures how quickly the page responds after a user clicks, taps, or types. The most common culprit is long JavaScript tasks blocking the main thread - usually from third-party scripts, unoptimized event handlers, or components that re-render more than they need to. We audit every third-party script for necessity, defer what is not critical, and break up long tasks so the browser can respond to input between them.

3. Eliminate Cumulative Layout Shift

CLS measures how much visible content jumps around while a page loads. We reserve explicit width and height (or aspect-ratio) for every image and embed, load web fonts with a matched fallback to avoid text reflow, and never inject banners, ads, or cookie notices above existing content without reserved space.

4. Audit every third-party script

Chat widgets, analytics tags, ad pixels, and A/B testing scripts are common hidden causes of poor Core Web Vitals. For each one we ask: does this need to load before the page is interactive, and does it need to run on every page? Scripts that fail both questions get deferred, lazy-loaded on interaction, or removed.

5. Test field data, not just lab data

Lighthouse and PageSpeed Insights lab scores are useful for diagnosis but do not reflect real user experience across devices and network conditions. Before calling a launch complete, we check Chrome User Experience Report (CrUX) data where available and monitor Search Console's Core Web Vitals report for the first several weeks to confirm the improvement holds up in the field.

6. Bake it into the architecture, not just the launch checklist

The checklist above catches problems before launch, but the real fix is architectural: build on a framework like Next.js that renders on the server by default, keep third-party scripts to a minimum from day one, and treat performance budgets as a requirement in code review, not an afterthought. That is how Core Web Vitals stay good six months after launch instead of quietly degrading.

7. Set a performance budget and enforce it

A checklist run once at launch only prevents regressions for as long as no one adds anything new. We set explicit performance budgets - maximum JavaScript bundle size, maximum image weight per page, a hard limit on third-party script count - and check them automatically as part of the build pipeline. When a new feature would break the budget, the team has to make a conscious tradeoff instead of accidentally shipping a regression that only shows up in a Search Console report weeks later.

8. Do not ignore mobile field data

Desktop Core Web Vitals scores are frequently good even on sites that fail badly on mobile, because mobile devices have less processing power and often slower network connections. Since most Core Web Vitals field data is weighted toward real user devices, and mobile traffic dominates for most US businesses, we always check mobile field data separately rather than assuming a good desktop score means the site passes overall.

If your current site is failing these checks, our Core Web Vitals optimization service runs this exact audit and ships the fixes, and any new build we deliver through our web development service starts from this checklist rather than retrofitting it later.