Core Web Vitals Checklist for Next.js and React Sites

Core Web Vitals are Google’s measurements of how a page feels to real visitors: how fast the main content appears, how quickly it responds to input, and how stable the layout is. They are part of Google’s page experience signals, and they correlate strongly with whether visitors stay or leave. This checklist is the one we use when auditing React and Next.js sites.

The three metrics and their thresholds

A page passes when the 75th percentile of real visits, measured separately for mobile and desktop, falls in the “good” range. That is why a fast laptop on office Wi-Fi tells you very little. Test on mid-range phones and throttled networks.

How to measure

• PageSpeed Insights shows real-user field data (where enough traffic exists) next to a lab test.
• Search Console’s Core Web Vitals report groups your URLs by status so you can fix whole templates at once.
• Chrome DevTools Performance panel shows exactly what blocks rendering and which tasks make interactions slow.
• The `web-vitals` JavaScript library lets you send real measurements from your own visitors to your analytics.

Fixing LCP

1. Find the LCP element. It is usually the hero heading, hero image or a large block of text. DevTools and PageSpeed Insights both name it.
2. Never hide it behind an animation. A hero that starts at zero opacity and fades in over a second cannot paint its largest element until the animation finishes. Render the main heading and text visible immediately and animate decorative elements only.
3. Prioritise the hero image. Give it explicit dimensions, serve a right-sized modern format, and mark it high priority (the priority or preload option on next/image, depending on your version, or fetchpriority="high" on a plain image). Never lazy-load the LCP image.
4. Self-host fonts. next/font downloads fonts at build time, serves them from your own domain and applies a size-matched fallback to reduce layout shift. Subset to the characters you need and load only the weights you use.
5. Cut render-blocking work. Inline critical CSS where possible, avoid large blocking scripts in the head, and ship less JavaScript so the main thread is free to paint.
6. Serve from a fast edge. Enable compression (Brotli or gzip), long cache lifetimes for fingerprinted assets, and a CDN. Slow server response (TTFB) caps how good LCP can be.

Fixing INP

INP replaced First Input Delay as a Core Web Vital in March 2024. It looks at the worst interaction during a visit, so one slow menu or modal is enough to fail. Slow interactions are almost always caused by too much JavaScript running on the main thread.

• Ship less JavaScript. Use Server Components for content that does not need interactivity, and split code so each route loads only what it needs. Audit your bundle with a bundle analyser.
• Replace heavy animation libraries for simple effects with CSS transitions, or load only the features you use (for example, the lazy-loaded feature bundle in Framer Motion).
• Break up long tasks. Anything running over 50 ms blocks input. Move heavy computation into a Web Worker, or yield to the browser between chunks of work.
• Keep event handlers light. Do the minimum synchronously (update the UI), and defer analytics and non-essential work.
• Limit third-party scripts. Tag managers, chat widgets and A/B testing tools are frequent INP offenders. Load them after interaction or when idle, using next/script with an appropriate strategy.
• Avoid giant DOMs. Thousands of nodes make every update slow. Virtualise long lists.

Fixing CLS

• Reserve space for images, video, embeds and ads with explicit width and height or an aspect ratio.
• Avoid inserting content above existing content after load, such as banners and cookie notices. Reserve their space or overlay them.
• Animate with `transform` and `opacity` rather than properties that change layout such as height, top or margin.
• Control font swapping. Use font-display: swap with a metrics-matched fallback so text does not jump when the web font loads.
• Use `100svh` or `100dvh` instead of 100vh for full-height sections on mobile, where browser toolbars appear and disappear.

Mobile-specific cost: paint and battery

Visual effects that look fine on a developer laptop can be expensive on a phone. Large blurred gradient layers, stacked backdrop filters and always-running animations force the GPU and CPU to work constantly, which hurts responsiveness and drains battery. Use static gradients instead of live blur on small screens, apply backdrop-filter sparingly, and respect prefers-reduced-motion so people who ask for less motion get it.

A pre-launch checklist

1. Run PageSpeed Insights on the home page and your top three templates, mobile first.
2. Confirm the LCP element on each template and that it is not lazy-loaded or animated in.
3. Check total JavaScript per route and remove unused libraries.
4. Test interactions (menu, forms, modals) with CPU throttling in DevTools.
5. Verify all images and embeds have reserved dimensions.
6. Add real-user monitoring so regressions show up after launch.
7. Add a performance budget to your CI pipeline so a heavy change fails the build.

If your scores are stuck, a short engineering review usually finds the two or three changes responsible for most of the gap. That is what our technical audit provides, and it pairs well with our technical SEO checklist.