Core Web Vitals: The Practical Checklist for Faster Websites

A slow website costs you in quiet ways. Visitors leave before the page loads, buttons feel unresponsive, and content jumps around just as someone tries to tap it. Google's Core Web Vitals turn these frustrations into three measurable metrics. This guide explains what each metric means in plain language, how to measure it correctly, and a practical checklist to fix the most common problems, in the order that usually gives the best results.

What are Core Web Vitals?

Core Web Vitals are a set of metrics Google uses to measure real user experience on a web page. There are currently three:

Metric	What it measures	Good	Needs improvement	Poor
LCP (Largest Contentful Paint)	Loading: how fast the main content appears	≤ 2.5 s	2.5 s – 4.0 s	> 4.0 s
INP (Interaction to Next Paint)	Responsiveness: how fast the page reacts to clicks, taps and key presses	≤ 200 ms	200 ms – 500 ms	> 500 ms
CLS (Cumulative Layout Shift)	Visual stability: how much content moves unexpectedly	≤ 0.1	0.1 – 0.25	> 0.25

Google assesses these at the 75th percentile of real page visits, split by mobile and desktop. In simple terms, a page passes when at least three out of four visits have a good experience for each metric.

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. If you still see advice about FID, it is out of date.

Why they matter

Core Web Vitals are part of Google's page experience signals, so they can influence search rankings, although relevant, helpful content remains far more important. The bigger reason to care is people: faster, more stable pages are simply easier and more pleasant to use, and that usually helps conversions and engagement.

Step 1: Measure the right way

Before changing anything, understand the two types of performance data.

Field data (real users)

Field data comes from real visitors on real devices and networks. This is what Google uses for Core Web Vitals assessment.

• Google Search Console — the Core Web Vitals report groups your URLs into good, needs improvement and poor.
• PageSpeed Insights — shows field data from the Chrome User Experience Report (CrUX) when your page or site has enough traffic.
• Your own real-user monitoring (RUM) — the open-source web-vitals JavaScript library lets you collect LCP, INP and CLS from your own visitors and send them to your analytics.

Lab data (controlled tests)

Lab data comes from a test run in a controlled environment, for example Lighthouse in Chrome DevTools or PageSpeed Insights' lab section. It is great for debugging, but it does not always match real users. Lab tests cannot fully measure INP, because INP depends on real interactions; use Total Blocking Time (TBT) in the lab as a rough indicator instead.

Measurement checklist

• Check Search Console to see which page groups fail, and on which device type
• Use PageSpeed Insights on representative pages (home, category, product, article, landing page)
• Set up real-user monitoring if you have enough traffic
• Test on a mid-range mobile phone, not only a fast laptop
• Record a baseline before you change anything

Tip: fix templates, not individual URLs. If all your product pages share one template, one fix can improve thousands of pages.

Step 2: Improve LCP (loading)

The LCP element is usually a hero image, a large heading, or a banner. First, find out which element it is. PageSpeed Insights and Chrome DevTools both show it.

LCP time can be broken into four parts: server response time (TTFB), resource load delay, resource load time and element render delay. Find the biggest part and fix that first.

LCP checklist

• Reduce server response time. Use caching, a content delivery network (CDN), and efficient database queries. Serve static or pre-rendered pages where possible.
• Make the LCP image discoverable early. Put it in the HTML as a normal <img> tag, not hidden in CSS backgrounds or loaded later by JavaScript.
• Do not lazy-load the LCP image. Lazy loading is great for images further down the page, but it delays the main one.
• Prioritise it. Add fetchpriority="high" to the LCP image, and consider a preload hint if it is discovered late.
• Optimise images. Use modern formats such as WebP or AVIF, compress them, and serve responsive sizes with srcset and sizes.
• Remove render-blocking resources. Inline critical CSS, defer non-critical JavaScript, and remove unused CSS.
• Load fonts efficiently. Self-host fonts where possible, preload the most important ones, use font-display: swap or optional, and limit the number of weights.
• Avoid client-side rendering for main content. If the main content only appears after a large JavaScript bundle runs, use server-side rendering or static generation instead.
• Reduce redirects. Each redirect adds a round trip before the page even starts loading.

Step 3: Improve INP (responsiveness)

INP measures the delay between a user interaction and the next time the screen updates. Poor INP usually means the browser's main thread is busy, often with too much JavaScript.

Each interaction has three parts: input delay (waiting for the main thread), processing time (running your event handlers) and presentation delay (the browser drawing the update).

INP checklist

• Reduce JavaScript. Remove unused code and libraries, and split bundles so each page only loads what it needs.
• Audit third-party scripts. Chat widgets, tag managers, A/B testing tools and ad scripts often block the main thread. Remove what you do not need and load the rest later.
• Break up long tasks. Any task longer than 50 ms blocks interaction. Split heavy work into smaller pieces and yield to the main thread between them, for example with scheduler.yield() where supported or setTimeout as a fallback.
• Keep event handlers light. Update the screen first (for example, show a loading state), then do the heavy work after.
• Avoid large DOM updates. Very large pages and complex layouts take longer to render. Keep the DOM size reasonable and use virtualisation for long lists.
• Avoid layout thrashing. Do not repeatedly read layout values (like element height) and then write styles in the same loop.
• Use web workers for heavy calculations that do not need the DOM.
• Watch framework hydration. In frameworks like React, large hydration work can block early interactions. Consider partial hydration, server components or lazy-loading interactive parts.

To find slow interactions, use the Performance panel in Chrome DevTools, record yourself using the page, and look for long tasks around your clicks and taps.

Step 4: Improve CLS (visual stability)

Layout shift happens when visible content moves without the user causing it. The classic example: you go to tap a button, an image loads above it, and you tap an ad instead.

CLS checklist

• Set dimensions on images and videos. Always include width and height attributes, or use CSS aspect-ratio, so the browser reserves space.
• Reserve space for ads, embeds and banners. Give containers a minimum height before the content loads.
• Do not insert content above existing content, unless it is a response to a user action. Cookie banners and promotions should overlay or sit in reserved space.
• Handle web fonts carefully. Fallback fonts with very different sizes cause text to jump. Use font metric overrides (such as size-adjust) or font-display: optional to reduce the shift.
• Animate with transforms. Use CSS transform and opacity for animations instead of changing top, left, width or height.
• Allow the back/forward cache. Pages restored from the bfcache appear instantly with no shifts. Avoid things that block it, such as unload event handlers.

Step 5: Prioritise your fixes

You will probably find more issues than you can fix at once. Use this simple order:

1. Fix what fails in field data first. A lab warning on a page that already passes for real users is lower priority.
2. Start with high-traffic templates. Home, category, product and key landing pages usually matter most.
3. Pick quick wins. Image dimensions, removing lazy loading from the LCP image and deleting unused third-party scripts are often fast to do.
4. Plan deeper work. Rendering strategy changes, JavaScript refactoring and infrastructure upgrades take longer but often have the biggest impact.

Remember that field data in Search Console and CrUX is based on a rolling 28-day window, so improvements take a few weeks to show fully.

Step 6: Keep it fast

Performance is not a one-time project. New features, new scripts and new content can slowly make a fast site slow again.

• Set performance budgets (for example, a maximum JavaScript size per page) and check them in your build pipeline.
• Run Lighthouse in continuous integration to catch regressions before they go live.
• Review real-user data monthly and after every major release.
• Require a performance check for every new third-party script.
• Make performance part of design reviews: large hero videos and heavy animations have a cost.

Key takeaways

• Core Web Vitals measure loading (LCP ≤ 2.5 s), responsiveness (INP ≤ 200 ms) and visual stability (CLS ≤ 0.1).
• Google uses real-user field data at the 75th percentile, so measure with Search Console, CrUX or your own RUM.
• For LCP, make the main image or text load early and fast.
• For INP, reduce and break up JavaScript, especially third-party scripts.
• For CLS, reserve space for everything that loads late.
• Fix templates, prioritise by real traffic, and protect your gains with performance budgets.

Need a faster website?

Core Web Vitals reward the same thing your visitors want: a site that loads quickly, responds instantly and stays stable. If you would like an expert performance audit or a rebuild with speed in mind, VYZEON's web development and SEO teams can help. Tell us about your site to get started.