What Core Web Vitals are
Core Web Vitals are part of Google's page experience signals. Each metric captures one aspect of how a page feels to a real visitor:
- Largest Contentful Paint (LCP) measures when the largest visible element, often a hero image or headline, finishes rendering. A good LCP is 2.5 seconds or less.
- Interaction to Next Paint (INP) measures how long the page takes to visibly respond after a tap, click or key press, across the whole visit. A good INP is 200 milliseconds or less. INP replaced First Input Delay as a Core Web Vital in March 2024.
- Cumulative Layout Shift (CLS) measures how much content moves unexpectedly while the page loads and is used. A good CLS is 0.1 or less.
A page passes when at least 75 percent of real visits meet the "good" threshold for each metric.
Field data versus lab data
There are two kinds of performance data, and they answer different questions.
| Field data | Lab data | |
|---|---|---|
| Source | Real Chrome users, via the Chrome UX Report | A simulated load in a test tool |
| Where you see it | Search Console's Core Web Vitals report, PageSpeed Insights | Lighthouse, PageSpeed Insights lab section |
| Reflects | Real devices, networks and behavior | One controlled test |
| Used by Google for page experience | Yes | No |
| Best for | Knowing whether you pass | Diagnosing why |
Field data tells you whether real users experience a problem. Lab data helps find the cause. Low-traffic pages may not have enough field data, in which case Google groups them with similar pages or the whole site.
How much Core Web Vitals affect rankings
Google has said that page experience is one of many signals, and that great content relevant to the search can still rank well with average page experience. In practice, Core Web Vitals rarely decide rankings on their own, but they can make a difference between pages of similar quality. Their bigger impact is often on visitors: slow, jumpy, unresponsive pages lose people before they call.
Fixing Largest Contentful Paint
Common causes of slow LCP on local business sites:
- A large, uncompressed hero image. Fix: resize to the display size, compress, use modern formats such as WebP or AVIF, and preload the image if it is the LCP element.
- A slow server response. Fix: better hosting, server caching and a content delivery network.
- Render-blocking CSS and JavaScript. Fix: inline critical CSS, defer non-essential scripts, remove unused code.
- Lazy-loading the hero image. Lazy-loading is useful for images further down, but applying it to the main image delays LCP.
- Web fonts that delay text. Fix: limit font files, use font-display settings that show text quickly.
Fixing Interaction to Next Paint
Poor INP usually comes from too much JavaScript running when the visitor interacts. Typical culprits:
- Chat widgets, pop-ups and tracking scripts loading on every page.
- Heavy page builders and sliders.
- Large scripts that run on every tap, such as complex menus.
Fixes include removing scripts that add little value, loading third-party tools only when needed, breaking long tasks into smaller ones, and simplifying interactive elements such as menus and forms.
Fixing Cumulative Layout Shift
Layout shifts happen when content moves after the page starts displaying. Causes and fixes:
- Images without dimensions. Set width and height, or an aspect ratio, so space is reserved.
- Ads, embeds and maps that load late. Reserve space for them.
- Banners inserted at the top, such as cookie notices or promotions. Overlay them, or reserve space.
- Fonts that swap and change text size. Choose fallback fonts with similar metrics.
Mobile first
Most local searches happen on phones, often on mobile networks. Field data is reported separately for mobile and desktop, and mobile is usually where problems appear. We test on mid-range phones and slower connections, not only on fast office computers, because that is how many customers actually experience your site.
Our Core Web Vitals process
- Review field data in Search Console to find which page groups fail and on which metric.
- Pick representative pages from each failing group.
- Diagnose with lab tools and browser performance profiling.
- Prioritize fixes by impact and effort, starting with templates that affect many pages.
- Implement or brief your developer with specific changes.
- Validate in Search Console once enough new field data accumulates, usually over the following 28 days.
Why fixes take time to show
Field data in the Chrome UX Report covers a rolling 28-day window. After a fix goes live, the reported numbers improve gradually as new visits replace old ones. Search Console's validation process tracks this. Lab tests show improvement immediately; field data catches up over the following weeks.
Platform-specific considerations
Different website platforms create different performance problems:
- WordPress: heavy themes, page builders and plugin overload. Fixes often involve reducing plugins, using a lighter theme and adding caching.
- Website builders: limited control over code. Fixes focus on images, embeds, third-party scripts and app add-ons.
- Custom sites: full control, often the best potential results, but changes need developer time.
We work within your platform and tell you clearly when a limitation is holding you back.
Reading the Search Console report
The Core Web Vitals report in Search Console groups pages with similar experiences and labels each group as good, needs improvement or poor, separately for mobile and desktop. Each group lists an example URL and the metric causing the problem. A few tips for reading it:
- Groups are based on similar pages, so fixing the template behind one example usually fixes the whole group.
- A group marked poor for INP points to scripts and interactivity; poor LCP points to images, server speed or render-blocking files; poor CLS points to layout shifts.
- If a site has too little traffic, the report may show no data. In that case, PageSpeed Insights and lab tests guide the work.
Common Core Web Vitals problems by page type
| Page type | Most common failing metric | Usual cause |
|---|---|---|
| Homepage | LCP | Large hero image or background video |
| Service pages | CLS | Images and embeds without reserved space |
| Contact page | LCP and INP | Embedded map and form scripts |
| Gallery or portfolio | LCP | Many large, uncompressed photos |
| Blog posts | CLS | Ads or late-loading embeds |
Knowing the likely cause by page type speeds up diagnosis, although each site still needs testing to confirm.
Core Web Vitals and conversions
Faster, more stable pages usually produce more calls and form submissions, because fewer visitors leave and forms are easier to complete. That is why we pair performance work with conversion rate optimization when the goal is more leads, not just better scores.
Third-party tools and responsiveness
Many local business sites rely on outside tools: chat widgets, review badges, booking systems, call tracking and several analytics tags. Each one adds JavaScript that competes for the phone's processor when a visitor taps a button. We measure the cost of each tool, keep the ones that earn their place and load them as late as possible, so the page responds quickly to the first tap.
What you receive
- A summary of which page groups pass and fail, on mobile and desktop.
- A diagnosis for each failing metric with the specific causes found.
- A prioritized fix list with clear instructions.
- Validation tracking until the fixes are confirmed in field data.
For broader speed work beyond the three metrics, see our page speed optimization service. Core Web Vitals are also reviewed as part of every technical SEO audit.