Core Web Vitals are the three metrics Google uses to judge how a page feels to a real visitor: how fast the main content shows up, how quickly the page reacts to input, and how much the layout jumps around. They influence rankings, but the deeper reason to care is simpler: slow, janky pages lose visitors, and the metrics point directly at what is annoying them.
This guide explains each metric in plain language, shows you how to measure them properly, and works through the fixes that deliver the biggest improvements, roughly in order of effort versus payoff.
The Three Metrics, in Plain Language
LCP: Largest Contentful Paint
LCP measures how long it takes for the largest visible element, usually a hero image or a main heading, to appear after a visitor starts loading the page. It answers: "How long until this page looks loaded?"
- Good: under 2.5 seconds
- Needs improvement: 2.5 to 4 seconds
- Poor: over 4 seconds
INP: Interaction to Next Paint
INP measures responsiveness. When someone clicks a button, taps a menu, or types in a field, INP tracks how long until the screen visibly reacts. It replaced the older FID metric because FID only measured the first interaction; INP looks at all of them and reports one of the worst.
- Good: under 200 milliseconds
- Needs improvement: 200 to 500 milliseconds
- Poor: over 500 milliseconds
CLS: Cumulative Layout Shift
CLS measures visual stability. Every time content moves after it was already displayed, like text jumping down because an ad loaded above it, the shift adds to the score. It answers: "Did the page yank things around while I was trying to read or click?"
- Good: under 0.1
- Needs improvement: 0.1 to 0.25
- Poor: over 0.25
Step 1: Measure Before You Touch Anything
There are two kinds of data, and confusing them wastes weeks.
Field data is what real visitors experienced, collected by Chrome and reported in the Chrome UX Report (CrUX). This is what Google actually uses for ranking. You see it in PageSpeed Insights (the top section), and in Search Console's Core Web Vitals report.
Lab data is a simulated load on a controlled machine, produced by Lighthouse or the Performance panel in DevTools. It is reproducible and detailed, perfect for debugging, but it is not what Google ranks with, and it frequently disagrees with field data. A common trap: your lab test on a fast laptop looks great while your field data from real phone users is failing.
The workflow: use field data to decide what to fix and whether it worked, and lab data to figure out why it is slow. Run PageSpeed Insights on your key templates (home page, article page, product page), note which metric fails, and prioritize the template with the most traffic.
Fixing LCP
LCP problems break down into four delays, and DevTools shows you which dominates.
Make the LCP element load early
The most common failure: the hero image is discovered late. If it is a CSS background image or injected by JavaScript, the browser cannot start downloading it until it has parsed the CSS or run the script. Fixes:
- Use a plain
<img>tag in the HTML rather than a CSS background where possible - Add
fetchpriority="high"to the hero image - Preload it:
<link rel="preload" as="image" href="hero.webp"> - Never lazy-load the LCP image.
loading="lazy"on above-the-fold images is one of the most common self-inflicted LCP wounds on the web.
Shrink the image itself
Serve modern formats (WebP or AVIF cut 30 to 60 percent versus JPEG), size images to their displayed dimensions with srcset, and compress at quality 75 to 85, which is visually indistinguishable from 100 for photos.
Cut server response time
The image cannot start until the HTML arrives. If your time-to-first-byte exceeds 800 milliseconds, look at caching (a CDN in front of the site, page caching in your CMS) before anything else. For WordPress specifically, a caching plugin usually improves LCP more than any image work.
Stop render-blocking resources
Every stylesheet in the head blocks rendering until downloaded. Combine and minify CSS files with a tool like our CSS Minifier, inline the small amount of CSS needed for above-the-fold content, and load the rest asynchronously. For JavaScript, add defer to scripts that do not need to run before render, which is nearly all of them.
Fixing INP
INP failures mean the main thread is busy when the user interacts. The browser can only do one thing at a time on the main thread; if it is running a 400-millisecond JavaScript task when someone taps a button, that tap waits.
Find and split long tasks
In DevTools Performance panel, record an interaction and look for red-flagged "long tasks" over 50 milliseconds. The fix is to break big synchronous chunks of work into smaller pieces, yielding to the browser between them so it can handle input. Modern code can use scheduler.yield() or setTimeout chunking; frameworks increasingly do this automatically if you use their recommended patterns.
Ship less JavaScript
The cheapest task to optimize is one you delete. Audit your bundles: third-party scripts (analytics, chat widgets, A/B testing tools, social embeds) are usually the worst INP offenders, and each one deserves the question "is this worth what it costs?" Load unavoidable third parties with defer or after first interaction. Minify what remains with our JS Minifier; smaller files parse faster too.
Avoid re-rendering the world on every keystroke
A classic INP killer: a search field that filters a 2,000-row list synchronously on every keypress. Debounce the input (wait 150 to 300 milliseconds after typing stops), virtualize long lists, and keep state updates scoped to the component that needs them.
Fixing CLS
Layout shift has a short list of causes, and all of them are fixable at the source.
Give images and embeds dimensions
An <img> without width and height attributes has zero height until the file arrives, and then it shoves everything below it down. Set explicit width and height attributes (the browser reserves the space using their ratio), or use the CSS aspect-ratio property. Same for videos, iframes, and ad slots: reserve the space in advance with a min-height, even if the ad might not fill it.
Handle web fonts carefully
When a custom font loads, text set in the fallback font gets remeasured and can reflow the whole page. Use font-display: swap combined with a size-adjusted fallback font, and preload the one or two font files used above the fold. Better yet, consider whether a system font stack serves you fine; it costs zero bytes and zero shift.
Never insert content above existing content
Banners, cookie notices, and "app install" bars that push the page down after load are pure CLS. Reserve their space in the initial layout, or overlay them so they do not displace content.
Animate with transform, not layout properties
Animating height, top, or margin triggers layout and counts as shift. Animating transform and opacity does not. This one change fixes most animation-related CLS.
A Realistic Priority Order
If your site fails everything and you have limited time, this sequence gets the most improvement per hour:
- Turn on page caching / put a CDN in front. Improves LCP everywhere at once.
- Fix the hero image: proper format, right size,
fetchpriority="high", never lazy. - Add width and height to every image. Usually fixes most of CLS in one pass.
- Add
deferto every script that allows it and delete third-party scripts you cannot justify. - Minify and consolidate CSS and JS. Our HTML Minifier, CSS Minifier, and JS Minifier handle the file-level work.
- Fix fonts:
font-display: swap, preload, or move to system fonts. - Only then dig into long-task profiling for INP, which is the most engineering-intensive fix.
Verifying the Fix
After deploying changes, lab-test immediately to confirm the mechanics improved, but remember field data is a 28-day rolling window. Search Console's report will take up to a month to fully reflect your fixes, and pages move from "Poor" to "Needs improvement" to "Good" as the window rolls over. Do not panic-revert after a week because the dashboard has not moved.
Keep monitoring after you pass. New marketing scripts, a redesigned hero, or one unsized banner image can quietly undo months of work. Some teams add a performance budget to CI, failing the build if bundle sizes or Lighthouse scores regress past a threshold. Even a monthly manual check on your top templates prevents most regressions.
Final Perspective
Core Web Vitals are a means, not an end. Passing thresholds matters for the ranking checkbox, but the actual prize is a site that feels instant, and users reward that with lower bounce rates and more conversions on every traffic source, not just Google. Measure with field data, fix the biggest offender first, verify, and keep the discipline going after you pass.