Home › Website SEO › Core Web Vitals
WEBSITE SEO / CORE WEB VITALS
Core Web Vitals: Complete Guide to LCP, INP, CLS & Website Performance
Understand the three Core Web Vitals, how LCP, INP and CLS measure loading, responsiveness and visual stability, how to test them, and how to diagnose and improve real-world website performance.
No invented measurements, no score-chasing and no ranking promises.
- LCP, INP and CLS explained with current thresholds
- Field data versus lab data, and why they differ
- Diagnosis workflows for WordPress, Elementor and WooCommerce
These are the recommended “good” thresholds published for each metric, not measurements of any website.
THE THREE METRICS
What Are Core Web Vitals?
Core Web Vitals are a small set of user-centred metrics measuring aspects of web experience that people actually notice: how quickly the main content appears, how quickly the page responds when they interact, and whether things stay where they expect.
There are currently three. INP replaced FID as the responsiveness metric — First Input Delay measured only the delay before the first interaction was processed, which turned out to be a poor proxy for how responsive a page feels over a whole visit. INP measures interaction latency throughout.
LCP
Largest Contentful Paint measures loading performance — when the largest relevant content element in the viewport finishes rendering.
Good: 2.5 seconds or less
Needs improvement: over 2.5s up to 4.0s
Poor: over 4.0 seconds
INP
Interaction to Next Paint measures responsiveness — the latency from a user interaction through processing until the next visual update, across the whole page visit.
Good: 200 milliseconds or less
Needs improvement: over 200ms up to 500ms
Poor: over 500 milliseconds
CLS
Cumulative Layout Shift measures visual stability — how much content moves unexpectedly during the page lifecycle.
Good: 0.1 or less
Needs improvement: over 0.1 up to 0.25
Poor: over 0.25
The thresholds above are assessment thresholds, not ranking guarantees. Google does use Core Web Vitals in its ranking systems, but they sit alongside relevance, content quality, technical accessibility and many other systems. Passing them does not produce rankings, and failing them does not make a page unrankable. Their real value is measuring whether your site is pleasant to use — which is worth doing regardless of search.
MEASUREMENT
Field Data, Lab Data and the 75th Percentile
Core Web Vitals are assessed at the 75th percentile of page views, segmented by mobile and desktop. That means a value at or below which roughly three-quarters of measured experiences fall. Using the 75th percentile rather than an average means a good result can’t be produced by fast visits masking a slow tail — most people need a decent experience, not just the lucky ones.
Field data comes from real users on real devices and networks. It answers “is this actually a problem?” Lab data comes from a controlled test. It answers “why?” Both matter, and they are not interchangeable — a developer testing on a fast machine over broadband will consistently see results better than their visitors experience.
CrUX (the Chrome User Experience Report) is a public dataset of real-user measurements from Chrome users who meet its collection criteria. It’s what powers the field section of PageSpeed Insights and the Search Console report. A page without enough traffic may have no field data at all, which is a common and legitimate reason the field section appears empty.
Search Console’s Core Web Vitals report groups URLs by similar performance rather than testing each one individually, which is why it reports on groups of pages and why a template-level problem shows up across many URLs at once.
TOOLS
Testing Tools and What Each One Tells You
A persistent confusion worth clearing up: the Lighthouse performance score is not your Core Web Vitals. It’s a composite lab score weighted across several metrics under simulated conditions. A page can score poorly in Lighthouse and pass Core Web Vitals in the field, or the reverse. Chasing 100 is not the goal — no threshold requires it, and the effort past a certain point buys nothing users notice.
The practical order: start with field data to find out whether a real problem exists and where, then use lab tools to diagnose the cause, then verify the fix in lab and confirm it in field data over the following weeks. Field data moves slowly because it reflects a rolling window of real visits — expecting it to change the day after a deploy leads to a lot of unnecessary worry.
Google Search Console
The Core Web Vitals report shows field-data status for groups of URLs, split by mobile and desktop. The best starting point because it tells you which templates actually have problems.
PageSpeed Insights
Combines a Lighthouse lab run with CrUX field data where available. The field section is the one that reflects real users; the lab section explains what to investigate.
Lighthouse
An automated lab audit covering performance, accessibility, best practices and SEO. Produces a composite score that is a diagnostic signal, not a Core Web Vitals assessment.
Chrome DevTools
The Performance panel for main-thread and long-task analysis, Network for waterfalls and resource sizes, Elements for layout shifts, and CPU and network throttling to approximate weaker devices.
CrUX
The public real-user dataset behind field reporting, available through its own tools and APIs for origin and page-level analysis where data exists.
web-vitals Library
A small JavaScript library for measuring LCP, INP and CLS from your own visitors, which is how you get real-user data on your own terms rather than waiting for a public dataset.
<!-- The LCP image should NOT be lazy-loaded -->
<img src="hero-1200.webp"
srcset="hero-600.webp 600w, hero-1200.webp 1200w, hero-1800.webp 1800w"
sizes="(max-width: 768px) 100vw, 60vw"
width="1200" height="675"
alt="Descriptive alt text for the hero image"
fetchpriority="high"
decoding="async">
<!-- Below the fold, lazy loading is appropriate -->
<img src="section-image.webp" width="800" height="450"
alt="Supporting illustration" loading="lazy">
<!-- Preload a genuinely critical resource — sparingly. -->
<!-- Every preload competes for bandwidth with the others. -->
<link rel="preload" as="font" type="font/woff2"
href="/fonts/body.woff2" crossorigin>
<!-- Connect early to a required third-party origin -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>LOADING
LCP: Largest Contentful Paint
LCP records when the largest relevant content element in the viewport renders. That element is usually a hero image, sometimes a large text block, sometimes a video poster — and it can differ between mobile and desktop, which is why you identify it rather than assume it.
Find it first. PageSpeed Insights and Lighthouse both name the LCP element; Chrome DevTools shows it in the Performance panel. Optimising the wrong image is the most common wasted effort in LCP work.
TTFB (Time to First Byte) measures how long until the first byte of the response arrives. It is not a Core Web Vital, but it’s a component of LCP — nothing can render before the HTML arrives, so a slow server puts a floor under your LCP that no image optimisation will lift.
For an image LCP: correct dimensions, sensible compression, a modern format, responsive srcset, and high fetch priority. Critically, do not lazy-load the LCP image. Blanket lazy-loading applied across a site is a common and self-defeating optimisation — it delays the very element being measured.
RESPONSIVENESS
INP: Interaction to Next Paint
INP measures how quickly a page responds when someone interacts — clicks, taps, keyboard input. It captures latency from the interaction, through event handling, to the next visual update, and reports a representative value across the whole visit rather than only the first interaction.
Almost every INP problem traces back to the main thread. Browsers run JavaScript, style calculation, layout and paint on a single thread. If that thread is busy with a long task when someone taps a button, the browser cannot respond until it’s free. The user experiences a dead interface, which is the thing INP is designed to catch.
Long tasks are the usual culprits. Rather than treating any particular duration as a threshold, the practical approach is to look at what occupies the main thread during interactions and break large work into smaller pieces so the browser can respond between them.
The fixes follow: ship less JavaScript, break up long tasks, keep event handlers light by deferring non-urgent work, reduce DOM complexity, and audit third-party scripts by measured impact. Third-party scripts are not automatically bad — analytics you actually use is worth its cost. Scripts nobody remembers adding, loaded on every page, usually are not.
Long JavaScript Tasks
A task occupying the main thread means the browser cannot process an interaction until it finishes.
Heavy Event Handlers
Handlers doing substantial work synchronously delay the response to every click or keypress.
Large or Complex DOM
More elements mean more style, layout and paint work for each update. Page builders can generate deep nesting.
Third-Party Scripts
Analytics, chat widgets, tag managers and A/B testing tools all compete for the same main thread.
Expensive Rendering
Large visual updates, layout-triggering changes and complex CSS delay the next paint.
Too Much JavaScript
Shipping more code than the page needs costs parse time, execution time and memory.
The click arrives while a long task holds the main thread. The browser cannot respond until that task ends — the gap between the click and the paint is what INP measures.
The button moves after the reader has already aimed at it. That is what CLS measures — and why it causes mis-taps.
<!-- width and height let the browser reserve space -->
<img src="photo.webp" width="1200" height="800"
alt="Descriptive alt text">
/* CSS keeps it responsive while preserving the ratio */
img { max-width: 100%; height: auto; }
/* Reserve space for a slot filled later */
.ad-slot { min-height: 250px; }
/* Reserve space for content loaded after render */
.recommendations { min-height: 320px; }
/* Fonts: swap shows text immediately, but metric */
/* differences can still shift layout. size-adjust and */
/* the metric overrides below reduce that. */
@font-face {
font-family: "ExampleFont";
src: url("/fonts/example.woff2") format("woff2");
font-display: swap;
}
@font-face {
font-family: "ExampleFallback";
src: local("Arial");
size-adjust: 104%;
ascent-override: 92%;
}
/* Animate transform and opacity — they do not trigger layout */
.card { transition: transform 200ms ease, opacity 200ms ease; }
/* Not this — animating layout properties causes shifts */
/* .card { transition: height 200ms, margin-top 200ms; } */
@media (prefers-reduced-motion: reduce) {
.card { transition: none; }
}VISUAL STABILITY
CLS: Cumulative Layout Shift
CLS measures unexpected movement of visible content. The classic failure: someone goes to tap a button, an image finishes loading above it, the button moves, and they tap an advert instead. Annoying on desktop, genuinely costly on mobile.
It’s scored differently from the other two — an unitless value based on how much of the viewport moved and how far, accumulated across the page lifecycle rather than a single moment.
CLS is usually the most fixable of the three, because the causes are concrete. Set width and height on images so the browser can reserve space from the start. Give ad slots and late-loading components a minimum height. Insert dynamic content below existing content, or reserve room for it. Animate transform and opacity, which composite without triggering layout, rather than height or margin, which don’t.
Fonts are the subtle one. font-display: swap shows text immediately in a fallback, which helps LCP — but if the web font has different metrics, the swap reflows the text. Matching fallback metrics with size-adjust and the ascent and descent overrides reduces that shift considerably.
Shifts following a user interaction within a short window are excluded, since a panel opening because someone clicked is expected. Unexpected movement is what counts.
DELIVERY
Images, Fonts, CSS, JavaScript and Caching
Images are usually the largest thing on a page. Serve them at the dimensions actually used, compress sensibly, choose a format suited to the content (AVIF and WebP compress well for photographs, SVG suits icons and diagrams, PNG still has its place for transparency), provide srcset so browsers can pick, and always set dimensions. No format is best for everything. See our image SEO guide.
Fonts cost more than people expect. Each family and weight is another file. Subset to the characters you need, use woff2, preload only genuinely critical fonts, and set font-display deliberately. Two families at two weights each is usually plenty.
CSS blocks rendering by design — the browser needs it before it can paint. Removing unused rules helps, but do it carefully: stylesheets generated by builders and themes often contain rules that only apply on certain pages or breakpoints, and aggressive automated removal breaks layouts. See our CSS guide.
JavaScript affects all three metrics: bundle size delays LCP, execution blocks the main thread and hurts INP, and content inserted after render causes CLS. Defer what isn’t needed for the initial render, split bundles by route, and audit what third parties are actually costing. See our JavaScript guide.
Caching, compression (Brotli or Gzip), a CDN and modern protocols (HTTP/2, HTTP/3) all reduce delivery time — though none of them automatically fixes Core Web Vitals. A CDN doesn’t help if the bottleneck is a 400KB JavaScript bundle blocking the main thread. Diagnose first. See our hosting guides.
A waterfall shows what starts when, what blocks what, and which resources are largest. Shapes are illustrative only.
Elementor checklist
- Avoid unnecessary nested containers
- Keep the DOM as shallow as the design allows
- Optimise the hero image and never lazy-load it
- Avoid large background videos
- Limit font families and weights
- Remove widgets no longer used on the page
- Minimise custom JavaScript
- Defer or remove heavy third-party embeds
- Lazy-load below-the-fold images only
- Set dimensions on every image
- Prefer transform and opacity animations
- Test mobile separately from desktop
- Check LCP, INP and CLS individually
- Confirm improvements in field data
WordPress checklist
- Choose a theme that suits the site, not one bundling everything
- Audit plugins and remove what is unused
- Optimise and correctly size images
- Limit font families and weights
- Enable page caching
- Consider object caching where the database is the bottleneck
- Use a CDN where the audience is geographically spread
- Reduce unnecessary JavaScript
- Review CSS from themes and plugins
- Keep the database maintained
- Test Elementor pages individually
- Test WooCommerce pages separately
ELEMENTOR [ ] Avoid unnecessary nested containers [ ] Keep the DOM as shallow as the design allows [ ] Optimise the hero image and never lazy-load it [ ] Avoid large background videos [ ] Limit font families and weights [ ] Remove widgets no longer used on the page [ ] Minimise custom JavaScript [ ] Defer or remove heavy third-party embeds [ ] Lazy-load below-the-fold images only [ ] Set dimensions on every image [ ] Prefer transform and opacity animations [ ] Test mobile separately from desktop [ ] Check LCP, INP and CLS individually [ ] Confirm improvements in field data WORDPRESS [ ] Choose a theme that suits the site, not one bundling everything [ ] Audit plugins and remove what is unused [ ] Optimise and correctly size images [ ] Limit font families and weights [ ] Enable page caching [ ] Consider object caching where the database is the bottleneck [ ] Use a CDN where the audience is geographically spread [ ] Reduce unnecessary JavaScript [ ] Review CSS from themes and plugins [ ] Keep the database maintained [ ] Test Elementor pages individually [ ] Test WooCommerce pages separately
PLATFORMS
WordPress, Elementor and WooCommerce
WordPress is not inherently slow. Performance depends on the theme, the plugins, the hosting, the images and how pages are built. A lean WordPress site outperforms a bloated custom one comfortably.
Elementor deserves an honest answer, since this site uses it. Elementor does not automatically fail Core Web Vitals. What it does is make it easy to build pages that struggle: deeply nested containers producing large DOM trees, animation effects on everything, background videos, multiple font families, heavy widgets, and third-party embeds added because they were one click away. The builder isn’t the problem — the complexity it permits is. A restrained Elementor page performs perfectly well.
The most valuable habits: keep nesting as shallow as the design allows, use animation sparingly, optimise the hero image, limit fonts, and check the mobile layout separately rather than assuming a desktop result transfers.
WooCommerce pages carry more moving parts — product galleries, variation scripts, cart fragments, filters, reviews, recommendations and payment provider scripts. That makes them worth measuring individually rather than assuming the homepage result represents the shop. Product and checkout pages often behave quite differently from everything else on the site.
CONTEXT
Mobile, Desktop and How This Fits Into SEO
Mobile and desktop are assessed separately, and mobile is usually harder. JavaScript that executes instantly on a laptop can take many times longer on a mid-range phone, which is why INP problems often appear on mobile first. Testing only on your own machine over your own connection will consistently mislead you.
Core Web Vitals are one part of page experience, alongside HTTPS, mobile usability, avoiding intrusive interstitials and generally being usable. There’s no single page experience score to optimise.
On SEO: Google uses Core Web Vitals in its ranking systems. That’s real, and it’s also frequently overstated. They do not outweigh relevance or content quality, good scores don’t produce rankings, and a perfect Lighthouse score guarantees nothing at all. The honest case for this work is that slow, unstable pages frustrate people — which matters whether or not any search engine is counting. See our technical SEO and on-page SEO guides.
React and Frontend Frameworks
Client-side rendering delays LCP because content waits for the bundle; hydration costs main-thread time affecting INP. Server or static rendering, code splitting and smaller bundles help. React is not inherently slow — architecture decides. See our React guide.
APIs and Data Loading
Slow API responses delay content that depends on them, and too many sequential requests compound. Caching, pagination and fetching in parallel all help. Content needed for LCP should not wait on a slow request.
Responsive design interacts with all three metrics: image sizing affects LCP, layout behaviour affects CLS, and mobile-specific components affect INP. See our responsive design guide.
Accessibility overlaps but is separate. Core Web Vitals do not measure accessibility, and a fast page can be unusable with a keyboard or screen reader. See our website accessibility guide.
DIAGNOSIS
Debugging Each Metric
Each metric has a different investigation path, and mixing them up wastes time. The table below lists possible causes — every site differs, and the point of diagnosis is finding out which apply rather than working through all of them.
Measure
Start from field data. Is this a real problem, and where?
Identify
Which metric, which templates, which device type.
Reproduce
Test a representative URL under realistic throttling.
Diagnose
Use lab tools to find the actual cause, not a symptom.
Prioritise
Weigh affected pages, severity, effort and risk.
Optimise
Fix the cause. Change one thing at a time where you can.
Validate
Retest in lab conditions and confirm nothing broke.
Monitor
Watch field data over the following weeks.
MYTHS & MISTAKES
Common Myths and Mistakes
“You need a 100 score”
A perfect Lighthouse score is not a threshold anywhere and not the goal. Effort past a point buys nothing users notice.
“Passing guarantees rankings”
Core Web Vitals are one input among many. Relevance and content quality are not displaced by performance.
“Lighthouse shows real users”
Lighthouse is lab data from one simulated device. Field data is what reflects actual visitors.
“One test represents everyone”
Results vary by device, network, location and page. A single run on one URL proves very little.
“Lazy-load everything”
Lazy-loading the LCP image actively harms LCP. Critical resources need priority, not deferral.
“More optimisation plugins help”
Stacked optimisation plugins conflict, duplicate work and add their own overhead.
Common Core Web Vitals mistakes
Chasing the Score
Optimising a number instead of the experience.
Ignoring Field Data
Lab results treated as the truth about real users.
Testing Desktop Only
Where mobile is usually the harder case.
Lazy-Loading the LCP Image
A blanket setting undermining the metric being measured.
Preloading Everything
Preloads competing for the same bandwidth.
Stacking Plugins
Several optimisation plugins fighting each other.
Ignoring Third Parties
Scripts nobody remembers adding, on every page.
Ignoring Fonts
Many families and weights loaded by default.
Ignoring Server Response
Image work that cannot lift a TTFB floor.
Ignoring CLS
The most fixable metric, left alone.
Optimising One Metric
LCP improved while INP quietly degrades.
Testing One URL
A homepage result assumed to represent every template.
Ignoring Dynamic Pages
Product and checkout pages never measured.
Breaking Functionality
Removing scripts or CSS without checking what depended on them.
Never Monitoring
Regressions arriving with the next plugin or redesign.
CHECKLIST
Core Web Vitals Master Checklist
A working checklist for an audit. Not every item applies to every site, and the order matters less than starting from field data rather than assumptions.
LCP
- Identify the LCP element on mobile and desktop
- Measure server response time
- Optimise and correctly size the LCP image
- Confirm the LCP image is not lazy-loaded
- Review render-blocking CSS and JavaScript
- Review font loading strategy
- Check caching and CDN coverage
INP
- Identify which interactions feel slow
- Profile the main thread during those interactions
- Reduce JavaScript shipped to the page
- Break up long tasks
- Keep event handlers light
- Audit third-party scripts by measured impact
- Reduce unnecessary DOM complexity
CLS
- Set width and height on every image
- Reserve space for ads and late-loading slots
- Insert dynamic content below existing content
- Review font metric differences
- Animate transform and opacity only
- Check the mobile layout specifically
Field data
- Review the Search Console report
- Check CrUX where available
- Use real-user monitoring if in place
- Review mobile and desktop separately
Lab data
- Run PageSpeed Insights on representative URLs
- Run Lighthouse with realistic throttling
- Profile in Chrome DevTools
Monitoring
- Record a baseline before changes
- Retest after each fix
- Confirm improvement in field data
- Watch for regressions after plugin, theme or design changes
LCP [ ] Identify the LCP element on mobile and desktop [ ] Measure server response time [ ] Optimise and correctly size the LCP image [ ] Confirm the LCP image is not lazy-loaded [ ] Review render-blocking CSS and JavaScript [ ] Review font loading strategy [ ] Check caching and CDN coverage INP [ ] Identify which interactions feel slow [ ] Profile the main thread during those interactions [ ] Reduce JavaScript shipped to the page [ ] Break up long tasks [ ] Keep event handlers light [ ] Audit third-party scripts by measured impact [ ] Reduce unnecessary DOM complexity CLS [ ] Set width and height on every image [ ] Reserve space for ads and late-loading slots [ ] Insert dynamic content below existing content [ ] Review font metric differences [ ] Animate transform and opacity only [ ] Check the mobile layout specifically FIELD DATA [ ] Review the Search Console report [ ] Check CrUX where available [ ] Use real-user monitoring if in place [ ] Review mobile and desktop separately LAB DATA [ ] Run PageSpeed Insights on representative URLs [ ] Run Lighthouse with realistic throttling [ ] Profile in Chrome DevTools MONITORING [ ] Record a baseline before changes [ ] Retest after each fix [ ] Confirm improvement in field data [ ] Watch for regressions after plugin, theme or design changes
A blank template for recording findings. Fill it from your own measurements — the values above are placeholders.
REFERENCE
Cheat Sheet, Roadmap and Who Does What
A quick reference, a sensible learning order, and a note on what each role actually needs from this.
LCPLargest Contentful Paint — loading, good at 2.5s or lessINPInteraction to Next Paint — responsiveness, good at 200ms or lessCLSCumulative Layout Shift — stability, good at 0.1 or lessp7575th percentile, how the metrics are assessedFieldReal-user data from actual visitsLabControlled testing for diagnosisCrUXChrome User Experience Report datasetPSIPageSpeed Insights — lab plus field where availableLighthouseLab audit producing a composite scoreGSCSearch Console Core Web Vitals reportTTFBTime to First Byte — part of LCP, not a Core Web VitalLong taskMain-thread work that blocks interactionExplaining it simply
For clients and non-technical stakeholders, the three metrics reduce to plain questions:
- LCP — how quickly does the main content appear?
- INP — how quickly does the page respond when you tap something?
- CLS — does the page stay still while it loads?
By role
- Website owners — check Search Console, note which templates are affected, and pass the detail to whoever maintains the site.
- SEO professionals — work from field data and URL groups, identify template-level patterns, and separate mobile from desktop.
- Developers — profile the main thread, inspect the waterfall, and fix causes rather than symptoms.
FAQ
Core Web Vitals: Frequently Asked Questions
Short answers to the questions people ask most about LCP, INP, CLS and performance measurement.
NEXT TOPICS
Continue Learning Website SEO
Technical SEO
Learn about crawling, indexing, URLs, redirects and site architecture.
On-Page SEO
Learn how content, keywords and page structure affect optimisation.
Schema Markup
Learn how structured data helps search engines understand content.
Image SEO
Learn how image optimisation affects search and performance.
Local SEO
Explore local search optimisation.
SEO Tools
Explore tools for SEO analysis and performance testing.
Website Speed
Learn broader website performance optimisation.
Responsive Design
Learn how layout behaviour affects performance across devices.
Improve Your Website's Core Web Vitals
Measure real-world performance, identify the causes of slow loading, delayed interactions and layout shifts, then improve the experience with a structured performance workflow.