Core Web Vitals guide: LCP, INP and CLS explained and fixed

What Core Web Vitals are

Core Web Vitals are a set of measurements, defined by Google, that describe how a page feels to a real visitor: how quickly the main content appears, how quickly the page responds when someone taps or clicks, and how stable the layout is while it loads. They are part of what Google calls page experience, and they are reported for your site in Google Search Console and in tools such as PageSpeed Insights.

There are three metrics, and each one has a published threshold that separates "good" from "needs improvement" and "poor":

Google assesses a page against these thresholds at the 75th percentile of real visits, separately for mobile and desktop. In plain terms, a page passes a metric only when at least three out of four real visits meet the good threshold. INP replaced an older metric, First Input Delay, in March 2024, so older articles that mention FID are out of date. As with all of Google's guidance, check the current documentation on web.dev and in Search Central, because thresholds and metrics can be revised.

This article explains what the numbers mean, how much they matter for search, how to measure them properly and how to fix the most common causes of poor scores. It is aimed at business owners and marketers, with enough technical detail that you can brief a developer and judge whether the work was done.

Do they affect rankings?

Yes, but modestly, and it is important to be accurate about how. Google has said that page experience, including Core Web Vitals, is one of many signals used in ranking, and that it does not override relevance. A fast page with weak content will not beat a slower page that answers the query much better. Google also says that a great page experience does not guarantee top rankings, and that when many pages are similarly relevant, page experience can matter more.

So treat Core Web Vitals as two things at once:

• A tie-breaker in search. In competitive results where several pages are about equally relevant, a better experience may help. You should not expect a leap in rankings from fixing scores alone.
• A conversion factor on your own site. Slow, jumpy pages frustrate visitors, and frustrated visitors leave before they call, fill in a form or buy. The business case for speed rests on this at least as much as on ranking.

This means the right priority for most businesses is to get out of the "poor" range on key pages and then move on to content and authority work, rather than polishing a score from 90 to 100. Our guide to the technical SEO audit checklist shows where speed fits among other technical checks.

Field data and lab data: the difference that matters

The most common source of confusion is that there are two kinds of measurement, and they often disagree.

Field data

Field data comes from real visitors using real devices on real networks. Google collects it from Chrome users who have opted in, in a dataset called the Chrome User Experience Report (CrUX). It is what the Core Web Vitals report in Search Console uses, and it is the version Google uses for page experience. It reflects your actual audience, including people on older phones and slow connections.

Lab data

Lab data comes from a simulated test, such as Lighthouse, run on a controlled device and network setting. It is repeatable and useful for diagnosing problems, because you can run it again after each change. But it is a single simulated visit, so it can differ widely from what your visitors experience. A Lighthouse score is not what Google uses to judge your page.

The practical rule: use field data to decide whether you have a problem and where, and use lab data to find causes and test fixes. If PageSpeed Insights shows a "Core Web Vitals Assessment" at the top, that is field data. The performance score and the list of "opportunities" below it are lab data.

A caution about field data: it needs enough traffic. Small sites may not have enough Chrome visits to appear in CrUX at all, in which case PageSpeed Insights shows only lab data and Search Console shows no Core Web Vitals report. That is not a problem to fix. It means you rely on lab tests and sensible practice.

The tools to use, and what each is for

• Google Search Console, Core Web Vitals report. Groups your URLs into good, needs improvement and poor, for mobile and desktop, using field data. It is the best way to see which groups of pages have problems. It reports groups of similar pages, not every URL, which fits the fact that problems usually come from templates.
• PageSpeed Insights. Shows field data for a page or origin where available, plus a lab test and specific recommendations. Use it to inspect individual page types.
• Lighthouse in Chrome DevTools. A repeatable lab audit that lets you test local changes before they go live.
• Chrome DevTools Performance panel. The detailed view of what the browser does, useful for finding long tasks that hurt INP.
• The web-vitals library and real-user monitoring. If you need your own field data, a small script can report metrics from your visitors to your analytics. Some performance monitoring services do this for you.
• WebPageTest. A detailed lab tool with filmstrips and waterfall charts, useful for diagnosing load order problems on specific network conditions.

Test the pages that matter most: the home page, your main service or category template, a typical product or article page and the page where the conversion happens. A fast home page with a slow checkout still loses sales.

Fixing Largest Contentful Paint

LCP is about how soon the main content appears. On most pages the largest element is a hero image, a banner or a large block of text. A slow LCP usually comes from one of four causes, and diagnosing which one saves time.

1. A slow server response

If the server takes a long time to send the first byte, everything after it is late. Causes include cheap or overloaded hosting, uncached dynamic pages and heavy database queries. Fixes include better hosting, page caching, a content delivery network that serves pages from locations near your visitors and trimming slow plugins or queries. Hosting providers often include caching and a CDN, so check what you already have before buying more.

2. Render-blocking resources

Stylesheets and scripts in the head of the page can stop the browser from drawing anything until they download. Reduce the amount of CSS and JavaScript the first view needs, inline the small amount of critical CSS, load the rest later and add the defer attribute to scripts that do not need to run immediately.

3. A heavy or late-discovered hero image

The most common LCP problem on marketing sites. The image may be far larger than needed, saved in an old format, or loaded in a way that makes the browser find it late. Fixes:

• Resize the image to the largest size it is actually displayed, and serve smaller versions to smaller screens using srcset and sizes.
• Use modern formats such as WebP or AVIF where your platform supports them, with a fallback if needed.
• Compress sensibly. Many hero images can be reduced by more than half without a visible difference.
• Do not lazy-load the main hero image. Lazy loading helps images below the fold, but on the LCP image it delays the very thing you are measuring. Use fetchpriority="high" on it instead, and preload it if it is referenced by CSS.

4. Content that appears only after JavaScript runs

If the main content is built in the browser by a large script, the page cannot show it until that script has downloaded and executed. Server-side rendering, static generation or at least rendering the main content in the initial HTML makes the content appear sooner. It also helps search engines read the page reliably.

Fixing Interaction to Next Paint

INP measures responsiveness across the whole visit. It looks at how long it takes from a tap, click or key press until the screen updates, and reports one of the slowest interactions. A poor INP usually means the browser's main thread is busy and cannot respond to the person.

Common causes and remedies:

• Too much JavaScript. Every script costs time to download, parse and run. Remove what you do not use, and be especially critical of chat widgets, heatmaps, social feeds, pop-up tools and multiple analytics tags.
• Long tasks. A task that blocks the main thread for more than about 50 milliseconds can make interactions feel sticky. Developers can break long tasks into smaller pieces, or defer work until the browser is idle.
• Heavy event handlers. A click that triggers a large amount of work before updating the screen feels slow. Show feedback immediately, such as a button state change, and do the heavy work afterwards.
• Large page structures. Very big pages with thousands of elements take longer to update. Simplify where you can.
• Third-party scripts. Tag managers, ad scripts and embedded widgets often cause the worst delays and are outside your direct control. Audit them, remove what is not delivering value and load the rest after the page is usable.

INP is measured only with real interaction, so lab tools cannot fully reproduce it. In the lab, Total Blocking Time is a proxy that often moves with INP, but the real answer comes from field data.

Fixing Cumulative Layout Shift

CLS measures how much visible content jumps around while the page loads. Everyone knows the experience: you go to tap a link, an advertisement loads above it, and you tap the wrong thing. Layout shifts are mostly avoidable, because they have a short list of causes.

• Images and videos without dimensions. If the browser does not know how much space an image needs, it reserves none, and text jumps when the image arrives. Always set width and height attributes, or use the CSS aspect-ratio property, so the space is reserved in advance.
• Ads, embeds and iframes. Reserve a fixed container for each one, with a minimum height, so the page does not move when the content loads.
• Late-loading web fonts. When a fallback font is replaced by the custom font, text can reflow. Use font-display settings carefully, preload key fonts and choose fallback fonts with similar metrics.
• Banners and notices injected above content. Cookie banners, promotions and sticky bars that push the page down after it has rendered are a classic source. Place them in reserved space or overlay them rather than inserting them into the flow.
• Content inserted by scripts. Avoid adding elements above existing content after load unless the visitor triggered it.

Layout shift caused by a user's own action, such as expanding a menu, within a short time after the interaction, is not counted against you. The goal is to prevent surprises.

Images, video and fonts: the biggest wins for most sites

On typical business sites, media makes up most of a page's weight, so the most reliable gains come from handling it well.

Images

• Right size. Do not upload a 4,000-pixel camera photo to display at 800 pixels. Resize before upload.
• Right format. JPEG for photographs where you cannot use a modern format, PNG only when you need transparency, SVG for logos and icons, WebP or AVIF where possible.
• Responsive. Offer more than one size using srcset, so phones download smaller files.
• Lazy loading. Apply loading="lazy" to images below the first screen, and never to the main LCP image.
• Descriptive alt text and file names. This helps accessibility and image search, and costs nothing.

Video

Do not autoplay large videos in the hero area on mobile. Use a small poster image, load the player only when the visitor chooses to play, and use a lightweight facade for embedded videos from third-party platforms instead of loading their full players on page load.

Fonts

Limit the number of font families and weights. Each extra weight is an extra file. Serve fonts in the WOFF2 format, self-host them where practical to avoid additional connections, and preload the one or two used above the fold. Many sites can use a good system font stack and lose nothing.

Notes by platform

The details of fixing depend on how your site is built, but the principles are the same.

• WordPress. Choose a lightweight theme, limit plugins to those you truly need, use a caching plugin or host-level caching, compress images on upload and remove unused page-builder widgets. A stack of overlapping plugins is the most common cause of slow WordPress sites.
• Shopify. Themes and installed apps are the main levers. Remove apps you no longer use, because many leave scripts behind, choose a well-built theme and compress product images. Our guide to Shopify SEO problems and fixes covers this in more detail.
• WooCommerce, Magento and BigCommerce. Hosting quality, caching and extension discipline matter, along with image handling and efficient category templates. See WooCommerce SEO and Magento SEO.
• Static and custom sites. Fast by default if you avoid heavy scripts. Watch image sizes and third-party tags, which are the usual culprits.

The cost of third-party scripts

Almost every business site eventually accumulates third-party code: analytics, tag managers, chat, call tracking, reviews widgets, retargeting pixels, heatmaps and font services. Each looks small by itself, and together they often account for much of a page's delay. They also sit outside your control, so a vendor's change can slow your site overnight.

A sensible approach is to treat every script as a cost that needs a reason:

1. List them all. Use the Network panel in DevTools or a tool such as WebPageTest to see every external request.
2. Ask who uses the data. If nobody has opened a tool's reports in six months, remove the script.
3. Load only on pages that need it. A chat widget on every page is rarely necessary. A reviews widget needed only on a testimonials page should not be on the home page.
4. Delay what is not essential. Load non-critical scripts after the page is interactive, or after the visitor first interacts.
5. Respect consent. Tracking scripts that need consent should not load until it is given, which also removes their cost for visitors who decline. Our own site loads analytics only after a visitor accepts.

A practical process: audit, fix, verify

1. Check Search Console. Open the Core Web Vitals report for mobile first, since that is where most scores are weakest. Note which groups of URLs are poor and which metric is the problem.
2. Pick representative pages. For each affected group, test one page in PageSpeed Insights. Record the field and lab values and the main opportunities.
3. Find the cause. Use DevTools and WebPageTest to see what the largest element is, what blocks rendering, which scripts run long and what shifts.
4. Fix the template. Because problems tend to come from shared templates, fix the template, not individual pages.
5. Re-test in the lab. Confirm the change helped in a repeatable test.
6. Validate and wait. Use the validation option in Search Console, and allow time, because field data is collected over a rolling window of about 28 days. You will not see the effect of a fix immediately.
7. Monitor. Re-check after every redesign, plugin update or new script. Performance regresses easily.

A performance budget is a simple tool that keeps gains from slipping: agree limits for page weight, number of scripts and image sizes, and check new work against them before it goes live.

Common mistakes

1. Chasing a Lighthouse score of 100. A perfect lab score does not mean your real visitors have a good experience, and it is not what Google uses.
2. Optimizing the home page only. The template that serves most visits and most conversions is usually deeper in the site.
3. Lazy-loading the hero image. It delays the metric you want to improve.
4. Adding a speed plugin on top of a heavy theme. It treats symptoms and rarely fixes the cause.
5. Ignoring third-party scripts. They are often the biggest slowdown and the easiest saving.
6. Testing only on a fast office connection. Your visitors may be on older phones and mobile data.
7. Expecting instant movement in rankings. The effect is modest, and field data takes weeks to update.
8. Forgetting to re-test. New features and tags quietly undo earlier work.

Why mobile scores usually come first

Google predominantly uses the mobile version of a site for indexing and ranking, and most sites score worse on mobile than on desktop. The reasons are physical, not mysterious. Phones have less processing power than laptops, often connect over slower and less stable networks and have smaller screens, so a page designed on a large monitor can feel heavy on a mid-range phone.

When you test, therefore, start with the mobile report in Search Console and the mobile tab in PageSpeed Insights, which simulates a mid-range phone on a throttled connection. If you only ever check on your own fast computer, you will probably miss the problem your customers see. Test on a real phone too, ideally an older model, on mobile data rather than office Wi-Fi.

Design decisions matter here. A hero video that looks impressive on desktop, a carousel of six large images or a menu that loads a large script before it opens are all luxuries that phones pay for. Ask of every element above the fold: does this help a visitor on a phone do what they came to do? If not, remove it or load it later.

Hosting, caching and content delivery in plain English

Behind the front-end techniques is a simpler foundation: how quickly your server can deliver the page, and how often it has to build it from scratch.

• Hosting. Entry-level shared hosting can be perfectly adequate for a small brochure site, and a poor choice for a busy store. If your time to first byte is consistently slow even for cached pages, the hosting plan may be the bottleneck. Compare plans on real performance, not only on price and storage.
• Page caching. A dynamic site builds each page by running code and querying a database. Page caching stores the finished HTML and serves the stored copy to the next visitor, which is far quicker. Most content management systems offer it through a plugin or a host-level setting.
• Browser caching. Headers that tell visitors' browsers to keep static files such as images, styles and scripts for a long time mean repeat visits are quick. Set long cache lifetimes and use versioned file names so updates still arrive.
• Content delivery networks. A CDN keeps copies of your files on servers around the world and serves each visitor from a nearby one. It helps most when your audience is spread over a large area or when your origin server is far from them.
• Compression. Gzip or Brotli compression shrinks text files in transit. It is usually a one-line server setting and worth confirming.

When you change something on a cached site, remember to clear caches so visitors see the new version. A surprising number of "my change did not work" problems are just old copies being served.

How to brief a developer so the work gets done

Vague requests such as "make the site faster" produce vague results. A good brief names the pages, the metric, the evidence and the acceptance test. Here is a structure you can copy.

1. The problem: "The mobile LCP for product pages is 4.1 seconds at the 75th percentile in Search Console, which is in the poor range."
2. The evidence: a link to the report, and a PageSpeed Insights result for one example URL.
3. The likely cause: "The largest element is the product image. It is a 2,400-pixel JPEG, lazy-loaded, and discovered late."
4. The requested change: "Serve a responsive WebP image, set fetchpriority=high on the first product image, remove lazy loading from it and set explicit width and height."
5. The acceptance test: "In a Lighthouse mobile test of the example page, LCP is under 2.5 seconds, and no new layout shift appears. After release, the field value moves to good over the following month."
6. The constraints: "Do not change the tracking tags or consent behavior. Test the checkout."

That level of detail lets the developer start straight away, lets you check the result and lets you hold a conversation about trade-offs. It also helps if the developer is external, because you are specifying an outcome rather than a technique.

Speed, accessibility and SEO overlap

Many fixes that improve performance also improve accessibility and search. Properly sized images with alt text help users on slow connections and screen reader users. Clear, stable layouts help everyone, including people with motor or cognitive difficulties who find moving targets hard. Semantic HTML loads faster than elaborate scripted widgets and is easier for assistive technology and search engines to interpret.

That overlap is useful when you decide what to prioritize. A change that helps speed, accessibility and crawlability together is almost always worth doing first. A change that makes a page prettier but slower and harder to use deserves a second look.

A worked example: a service business home page

Imagine a regional heating and cooling company whose site was built with a page builder. Search Console shows mobile LCP in the poor range and CLS in the needs-improvement range on most pages.

Investigation shows that the home page loads a large slider with five full-width images, a video background, three font families in six weights, a chat widget and four tracking scripts. The first slide image is lazy-loaded, and the cookie notice is inserted at the top after a delay, pushing the page down.

The plan, in order of expected benefit:

1. Replace the slider with a single static hero image, correctly sized, in a modern format, with explicit dimensions and high fetch priority.
2. Remove the background video on mobile, keeping a poster image.
3. Reduce fonts to one family in two weights, self-hosted and preloaded.
4. Delay the chat widget until the visitor interacts, and remove two tracking scripts nobody was using.
5. Reserve space for the cookie notice so it no longer pushes content.
6. Enable page caching and compression at the host.

None of this requires a rebuild. It is a few days of careful work, and the result is a faster and cleaner first impression, a more stable layout and fewer lost visitors. Several weeks later, the field data in Search Console begins to move to good. The company does not leap up the rankings, but its pages convert better, and it has removed a weakness that competitors with similar content might have used against it.

How we help

At AH SEO Agency we treat speed as a business metric first and a ranking signal second. A technical review looks at your field data in Search Console, identifies the templates that hold your scores back, finds the specific causes and gives your developers a short, prioritized list with the expected impact of each change. We also check that fixes do not break tracking or consent, and we re-test after release. You can read more on our technical SEO page, see what a review costs in how much SEO services cost or request a free SEO audit to see where you stand.

Summary

• Core Web Vitals are three measures of real-visitor experience: LCP for loading, INP for responsiveness and CLS for visual stability.
• They are a modest ranking signal and a significant factor for conversions, so aim to get out of "poor" on your important pages.
• Field data from real visitors decides whether you pass, while lab tools help you diagnose and test fixes.
• Most problems come from heavy images, too much JavaScript, third-party scripts and missing space for content, and are fixed at the template level.
• Re-test after every change and allow around a month for field data to reflect it.