Core Web Vitals checklist 2026: LCP, INP, CLS

Core Web Vitals are a set of user-centered performance metrics that Google uses as ranking signals. They measure loading performance (LCP), interactivity (INP), and visual stability (CLS). Since the Page Experience update made them official ranking factors, maintaining "Passed" status across all three has become a baseline requirement for competitive search performance.

What are Core Web Vitals?

Core Web Vitals were introduced by Google to give developers and site owners a standardised way to measure real-user experience — as opposed to synthetic lab metrics that do not reflect how actual users experience a page on real devices and network conditions. The metrics are field-measured using Chrome User Experience Report (CrUX) data collected from real users, which means your scores reflect the actual performance your visitors experience, not the performance of a simulated test.

This matters because a page can pass a Lighthouse test in a controlled environment and still fail Core Web Vitals in field data if real-world conditions — slower devices, variable network speeds, third-party script interference — degrade the experience. Both lab and field data are useful; field data (CrUX) is what Google uses for ranking.

Each metric has three ranges: Good (green), Needs Improvement (yellow), and Poor (red). For ranking benefit, you need "Good" at the 75th percentile — meaning at least 75% of real users experience the metric within the Good threshold.

LCP: Largest Contentful Paint

LCP measures the time from when the page starts loading to when the largest visible content element is rendered. For most pages this is the hero image, a large text block, or a video poster frame. The threshold: Good is under 2.5 seconds, Poor is over 4.0 seconds.

The most common LCP problems and fixes:

Unoptimised hero image. Use WebP or AVIF format, compress to the minimum acceptable quality, serve at the correct rendered size (not 3x larger), and use the fetchpriority="high" attribute on the LCP image element to ensure the browser prioritises it.
Hero image loaded via CSS background. CSS background images are lower-priority than <img> elements and are not LCP candidates. Render the hero image as an <img> with fetchpriority="high".
Slow server response (TTFB). If Time to First Byte is over 800ms, LCP will struggle to pass. Check hosting, CDN configuration, and server-side rendering performance.
Render-blocking resources. Large CSS files or synchronous JavaScript in the <head> delay rendering. Move non-critical CSS inline or defer, and use defer or async on non-critical scripts.

INP: Interaction to Next Paint

INP replaced FID (First Input Delay) as a Core Web Vital in March 2024. While FID only measured the delay before the browser began handling an interaction, INP measures the full time from interaction to the next visual update — a more demanding and representative measure of interactivity throughout the page lifecycle. The threshold: Good is under 200ms, Poor is over 500ms.

INP problems are most common on JavaScript-heavy pages with significant main thread work:

Long tasks blocking the main thread. JavaScript tasks over 50ms block the browser from responding to user input. Use the Performance panel in Chrome DevTools to identify long tasks. Break long tasks using scheduler.yield() or setTimeout(0) to yield to the browser.
Large DOM size. Pages with DOM sizes over 1,400 nodes increase rendering and layout work per interaction. Reduce DOM depth and avoid rendering off-screen content unnecessarily.
Inefficient event handlers. Heavy event handlers that trigger synchronous style recalculation or layout (forced reflow) add directly to INP. Profile and optimise handlers that run on click, scroll, or input events.
Third-party scripts running on the main thread. Analytics, chat widgets, and ad scripts can contribute significant main thread work. Audit with the Third-party Summary in Lighthouse and defer non-critical scripts.

CLS: Cumulative Layout Shift

CLS measures unexpected visual movement of page content during loading. A score of 0 means no layout shift; 0.1 or under is Good; over 0.25 is Poor. Layout shift that occurs after a user interaction is excluded from the score.

The most common CLS causes and fixes:

Images without dimensions. Images without explicit width and height attributes cause layout shift when they load because the browser does not reserve space for them. Always set width and height on <img> elements. Use aspect-ratio in CSS for responsive images.
Late-loading ads or embeds. Dynamically inserted content (ads, iframes, embeds) that pushes page content down after initial render. Reserve space with fixed-height containers or use a defined aspect ratio wrapper.
Custom font loading causing text shift. When a web font loads after initial render, the shift from system font to web font causes layout shift. Use font-display: optional or preload the font file to minimise FOIT/FOUT.
Dynamically injected banners or notifications. Cookie consent bars, notification banners, or promotional elements injected at the top of the page push content down. Reserve height in the layout or inject from the bottom of the viewport.

How to measure Core Web Vitals

For field data (real users), use Google Search Console's Core Web Vitals report, PageSpeed Insights (field section), or the CrUX Dashboard. Field data lags current performance by 28 days and requires sufficient traffic to generate a stable sample.

For lab data and debugging, use Lighthouse in Chrome DevTools, PageSpeed Insights (lab section), or WebPageTest. Lab data provides immediate feedback but does not perfectly predict field scores.

For INP debugging specifically, use the Web Vitals Chrome Extension with interaction logging enabled, or the Interaction section of Chrome DevTools Performance panel.

Priority optimisation checklist

Use this checklist for a systematic pass through Core Web Vitals optimisation:

[ ] Hero image served as <img> with fetchpriority="high"
[ ] Hero image in WebP or AVIF, compressed, at correct rendered size
[ ] TTFB under 800ms (check with WebPageTest or PageSpeed Insights)
[ ] No render-blocking CSS or synchronous JS in <head>
[ ] All <img> elements have explicit width and height attributes
[ ] Custom fonts preloaded or using font-display: optional
[ ] No layout shift from dynamic content insertion above the fold
[ ] No long tasks (50ms+) on main thread during page load or interaction
[ ] Third-party scripts deferred or loaded asynchronously
[ ] DOM size under 1,400 nodes
[ ] Verified in PageSpeed Insights field data: all three vitals in "Good"

Skylabs implements Core Web Vitals optimisation as part of the standard [technical SEO foundation](/en/seo-technical-foundation) on every website build — targeting Passed status across LCP, INP, and CLS before launch.

If you are running paid campaigns, Core Web Vitals also affect Google Ads quality scores. A slow landing page with poor CWV scores will pay higher CPCs for the same position. For campaign-focused performance, see [landing page design](/en/landing-page-design).

For a broader understanding of how technical SEO signals — including CWV — contribute to Google's quality evaluation framework, [EEAT explained](/blog/en/what-is-eeat-google) covers the full picture.

Related services

Technical SEO foundation Landing page design EEAT explained

Frequently asked

Do Core Web Vitals affect SEO rankings directly?

Yes. Core Web Vitals are a confirmed Google ranking signal as part of the Page Experience update. However, they are one of many signals — content relevance, authority, and topical depth still carry more weight. Poor CWV scores will not cause a high-authority site to disappear from rankings, but they create a ceiling on competitive ranking performance.

My lab score is good but field data is poor — why?

Field data reflects real users on real devices and connections, which are often slower than the simulated conditions in Lighthouse or PageSpeed Insights lab tests. Third-party scripts, larger JavaScript bundles, and mobile device limitations commonly cause field data to lag lab scores. Focus optimisation on the field data, as that is what Google uses.

How often should we check Core Web Vitals?

Check after any significant site change (new page sections, added scripts, imagery updates) and quarterly as a routine audit. CrUX data is on a 28-day rolling window, so post-deployment improvements take time to appear in field data.

Ready to upgrade your website?

Talk to us about professional website design for your business.

Chat Zalo

Thiết kế website chuyên nghiệp giá bao nhiêu?

Chi phí thiết kế website chuyên nghiệp phụ thuộc vào phạm vi dự án, số trang, mức độ UI/UX tùy biến, tính năng kỹ thuật và yêu cầu SEO — không có một con số cố định áp dụng cho mọi trường hợp.

Read

Website mới làm bao lâu thì lên Google?

Website mới có thể được index sau vài ngày đến vài tuần, nhưng để có thứ hạng ổn định cần nền tảng kỹ thuật, nội dung phù hợp intent và tín hiệu tin cậy.