The Core Web Vitals checklist every developer should run before launch

We've already written about what Core Web Vitals mean in plain English for business owners. This one is different — it's the technical checklist we actually run through before shipping any project, written for developers who already know what LCP, INP, and CLS stand for and want the specific fixes, not the definitions.

Before you start: set your measurement baseline

Run Lighthouse in incognito mode before touching anything, and note lab scores for LCP, INP, and CLS. Lab data (Lighthouse, WebPageTest) tells you what's fixable in code. Field data (Chrome UX Report, Search Console) tells you what real users on real networks and devices actually experience. Optimize against both — a site that scores perfectly in the lab but poorly in the field usually has a device or network gap you haven't tested for.

LCP checklist

1. 1.Identify the actual LCP element with DevTools Performance panel or PageSpeed Insights — don't assume it's the hero image, it's sometimes a headline or background element
2. 2.Preload the LCP image with link rel='preload' so the browser discovers it immediately instead of waiting for CSS to resolve
3. 3.Set fetchpriority='high' on the LCP image and loading='eager' — never lazy-load the element that defines your LCP score
4. 4.Serve responsive images with srcset and sizes so mobile devices don't download a desktop-resolution asset
5. 5.Convert to modern formats (WebP or AVIF) — typically 30–50% smaller than JPG at equivalent visual quality
6. 6.Remove render-blocking CSS and JS above the fold; inline only what's needed to paint the initial viewport
7. 7.Serve static assets through a CDN so LCP isn't bottlenecked by geographic distance to your origin server

Server response time / TTFB

LCP can't happen faster than the HTML that describes it arrives. Target TTFB under 200ms. On WordPress specifically: enable full-page caching (WP Rocket, LiteSpeed Cache, or server-level), avoid uncached database queries on every request, and confirm you're on PHP 8.2+ with a hosting tier that isn't oversold. If TTFB is over 600ms, fix that before touching anything else on this list — nothing downstream matters until the server responds quickly.

INP checklist

1. 1.Break long JavaScript tasks into smaller chunks so the main thread can respond to input between them — anything over 50ms blocks interaction
2. 2.Avoid layout thrashing: don't read and write to the DOM in alternating calls inside the same function; batch reads, then batch writes
3. 3.Defer non-critical JavaScript with requestIdleCallback or a similar scheduling approach rather than running it all on load
4. 4.Debounce or throttle expensive event handlers — scroll listeners, resize handlers, keystroke handlers on search inputs
5. 5.Move genuinely heavy computation (parsing, sorting large datasets, image processing) off the main thread with a Web Worker
6. 6.In component frameworks, audit hydration cost — over-hydrating static content is one of the most common hidden INP killers on marketing sites

Auditing third-party scripts

Third-party scripts are the single most common cause of poor INP on otherwise well-built sites, because they run code you don't control on your users' devices.

• ✓List every third-party script currently loaded and justify each one's presence — chat widgets, tag managers, A/B testing tools, and social embeds are the usual offenders
• ✓Load non-essential third-party scripts with defer or after user interaction (e.g. load a chat widget on scroll or after a delay, not on initial page load)
• ✓Self-host what you reasonably can (fonts, analytics scripts) to avoid extra DNS lookups and reduce reliance on third-party uptime
• ✓Check each script's own long-task footprint in the Performance panel — some analytics and heatmap tools are disproportionately expensive for the value they add

CLS checklist

1. 1.Set explicit width and height (or aspect-ratio in CSS) on every image, video, and iframe so the browser reserves space before the asset loads
2. 2.Reserve space for ads, embeds, and dynamically injected banners before they load — never let content push existing content downward after the initial render
3. 3.Never insert new content above existing content without a direct user action (e.g. a 'load more' button is fine; an automatic banner insertion is not)
4. 4.Use font-display: swap and preload critical web fonts; where possible, use a font with closely matched fallback metrics to avoid visible reflow when the web font swaps in
5. 5.Avoid CSS animations that trigger layout (animating width, height, or top/left) — animate transform and opacity instead, which don't cause reflow

JS bundle and code-splitting checklist

• ✓Split bundles by route so users only download the JavaScript needed for the page they're on
• ✓Tree-shake aggressively and confirm your bundler is actually eliminating dead code, not just minifying it
• ✓Analyze your production bundle with webpack-bundle-analyzer or source-map-explorer at least once per major release — bundles bloat silently over time
• ✓Lazy-load below-the-fold interactive components (tabs, modals, carousels) instead of shipping them in the initial bundle
• ✓Audit polyfills — many projects still ship polyfills for browser support they no longer need to target

Critical CSS and render path

Extract and inline the CSS required to render the initial viewport, and defer the rest with a non-blocking load pattern. Avoid chained @import statements in CSS, which serialize requests and delay first paint. Keep the critical CSS payload small — inlining your entire stylesheet defeats the purpose.

Lazy loading strategy

Use native loading='lazy' on every image and iframe below the fold — but never on the LCP element itself. A common mistake is lazy-loading everything uniformly through a plugin or default setting, which quietly delays your hero image and tanks LCP. Use IntersectionObserver for lazy-mounting heavier components (maps, embedded video, comment widgets) that aren't visible on initial load.

Final pre-launch pass

1. 1.Run Lighthouse in incognito mode with no browser extensions active, on both mobile and desktop presets
2. 2.Throttle to simulated slow 4G and re-test — this reveals problems a fast office connection hides
3. 3.Run WebPageTest from at least one location geographically distant from your server or CDN edge
4. 4.If the site has traffic history, check the Chrome UX Report / Search Console Core Web Vitals report for real-user field data, not just lab scores
5. 5.Set up ongoing monitoring (Search Console alerts, or a synthetic monitoring tool) so a future plugin or dependency update doesn't silently regress scores

Core Web Vitals are a moving target, not a one-time launch task. A theme update, a new tracking pixel, or an added embed can silently push a green score back into the red. Re-run this checklist after any meaningful change, not just before the initial launch.