Core Web Vitals Explained
Your Miami business website can have the best content, the strongest backlinks, plus the cleanest schema markup on the internet. If it loads slowly, jumps around as the user scrolls, or takes 600 milliseconds to respond when someone taps a button, Google still demotes it. Core Web Vitals are the part of SEO that decides whether the rest of your SEO work pays off.
This guide explains what Core Web Vitals are, how Google measures them in 2026, plus exactly how to fix each metric when your site fails. Everything is current as of the May 2026 algorithm state, including INP (which replaced FID in March 2024).
- Core Web Vitals are three Google-defined metrics that measure real user experience: LCP (loading speed), INP (interaction responsiveness), plus CLS (visual stability).
- To pass Core Web Vitals, a page needs LCP under 2.5 seconds, INP under 200 milliseconds, plus CLS under 0.1, measured at the 75th percentile of real user sessions.
- Core Web Vitals are part of Google's Page Experience ranking signals, contributing to rankings as a tiebreaker between otherwise-equivalent pages.
- Field data (real user data from Chrome User Experience Report) is what Google uses for ranking, not Lighthouse lab scores.
- Most Miami WordPress sites fail Core Web Vitals because of unoptimized images, render-blocking JavaScript, plus heavy page builder code, all of which are fixable.
What are Core Web Vitals?
Core Web Vitals are three Google-defined metrics that measure real user experience on a webpage: Largest Contentful Paint (LCP) measures loading speed, Interaction to Next Paint (INP) measures responsiveness to user input, plus Cumulative Layout Shift (CLS) measures visual stability during page load. Google uses these three metrics as part of its Page Experience ranking signals, with thresholds set at the 75th percentile of real user sessions.
The three metrics replaced older performance metrics in 2020 (LCP plus CLS) plus 2024 (INP replaced FID, First Input Delay). Each metric maps to a specific user complaint: LCP catches "this page is slow," INP catches "this page is unresponsive," plus CLS catches "stuff is moving around as I try to read." For the full breakdown of how these tie into the broader page experience signal set, see our technical SEO Miami service page.
What are the three Core Web Vitals metrics?
The three Core Web Vitals metrics in 2026 are Largest Contentful Paint (LCP) measuring loading performance, Interaction to Next Paint (INP) measuring interactivity, plus Cumulative Layout Shift (CLS) measuring visual stability. Each metric has three threshold bands: Good, Needs Improvement, plus Poor. A page passes Core Web Vitals only when all three metrics fall into the Good band at the 75th percentile of real user data.
How long it takes for the largest visible element (usually a hero image or H1 text block) to render after the user requests the page. Catches slow-loading pages.
How long the page takes to visually respond when the user taps, clicks, or types. Replaced FID in March 2024 because it captures the full lifetime of all interactions, not just the first.
How much visible content moves around unexpectedly during page load. Score is a unitless number based on the impact fraction multiplied by the distance fraction of every shift.
A passing Core Web Vitals score requires all three metrics in the Good band, measured at the 75th percentile. The 75th percentile means 75 percent of your real users must experience Good-level performance. Optimizing for the median is not enough because Google explicitly grades the tail of the distribution.
Do Core Web Vitals affect SEO rankings?
Core Web Vitals affect SEO rankings as part of Google's Page Experience signal group, contributing to rankings primarily as a tiebreaker between pages with otherwise-equivalent content quality plus authority. Failing Core Web Vitals does not block ranking entirely, but it caps how high a page can climb against competitors who pass. For Miami businesses competing in tight verticals, a Core Web Vitals win can be the difference between page one plus page three.
How Google weights Core Web Vitals in ranking
- Tiebreaker signal. When two pages have similar content quality plus authority, the one passing Core Web Vitals ranks higher. In competitive Miami verticals where dozens of pages match on content, this tiebreaker decides position.
- Mobile-first weighting. Google uses mobile Core Web Vitals data for ranking, not desktop. A site passing on desktop but failing on mobile is treated as failing.
- Page-level signal. Each URL gets its own Core Web Vitals score. A site can have some passing pages plus some failing pages. The failing pages are individually penalized.
- Site-wide pattern. Sites with most pages failing Core Web Vitals also see indirect impact on user satisfaction signals (pogo-sticking, bounce rate) that compound the ranking effect.
Beyond ranking: the conversion impact
Even if Core Web Vitals were not a ranking factor, they still affect Miami business revenue through conversion rate. Industry data consistently shows pages loading in under 2.5 seconds convert 1.5x to 3x better than pages loading in 4+ seconds. INP failures cause users to think the form is broken, then abandon. CLS failures cause mis-tapped buttons, leading to friction plus drop-off. Speed is not just an SEO metric, it is a revenue metric.
For the related diagnostic on what causes ranking drops beyond CWV, see our companion guide on why did my rankings drop.
How do you measure Core Web Vitals?
Measure Core Web Vitals using Google PageSpeed Insights (free, combines field plus lab data), Google Search Console Core Web Vitals report (site-wide field data view), Chrome DevTools Performance panel (lab data with detailed waterfall), Lighthouse (lab data with audit recommendations), plus the Chrome User Experience Report (CrUX, the raw field data Google uses for ranking). PageSpeed Insights at pagespeed.web.dev is the fastest way to check any URL.
The five primary measurement tools
- PageSpeed Insights at pagespeed.web.dev. Free Google tool that combines field data (real user metrics from CrUX) plus lab data (synthetic Lighthouse run). Best starting point for any URL.
- Google Search Console Core Web Vitals report. Site-wide view of how many of your URLs pass, fail, or fall in the Needs Improvement band, broken down by mobile plus desktop. Found under Experience > Core Web Vitals.
- Chrome DevTools Performance panel. Lab data with detailed waterfall, layout shift visualization, plus long task identification. Press F12 in Chrome plus open the Performance tab.
- Lighthouse. Built into Chrome DevTools or available as a standalone CLI tool. Provides lab data plus specific audit recommendations.
- Chrome User Experience Report (CrUX). The raw field data Google uses for ranking decisions. Accessible through the CrUX API or the public BigQuery dataset.
What to check first
- Open Google Search Console. Go to Experience > Core Web Vitals. This shows site-wide pass/fail status for your indexed URLs across mobile plus desktop.
- Identify the URL groups failing. Search Console groups similar URLs (homepage, blog posts, service pages) plus shows pass/fail by group.
- Pull a representative URL from each failing group. Run it through PageSpeed Insights to see specific metric failures plus recommended fixes.
- Cross-check with field data. Make sure the lab data warnings match real-user field data. Lab failures without field failures are less urgent than lab plus field together.
What is the difference between field data and lab data?
Field data is real user performance data collected from Chrome users who opted into anonymous reporting (Chrome User Experience Report), measuring actual page loads on real devices across real networks. Lab data is synthetic performance data generated by tools like Lighthouse running a single page load in a controlled environment. Google uses field data for ranking decisions because it reflects real user experience. Lab data is useful for diagnostic work plus pre-launch testing.
When to trust each data type
- Field data wins for ranking decisions. Google ranks based on what real users actually experience, not synthetic tests. Always check Search Console field data first.
- Lab data wins for diagnosis. Lab data gives you the detailed waterfall, identifies specific resources slowing the page, plus shows the exact JavaScript causing INP failures.
- Both wins for new pages. New pages without enough traffic have no field data. Lab data is the only signal available until CrUX accumulates enough samples (usually 28 days at minimum traffic levels).
- Disagreements happen. A page can pass lab tests but fail field data, or vice versa. Field data reflects real network conditions, real device variability, plus real third-party script delays. Lab data uses a fixed device profile plus simulated network.
Optimizing for the Lighthouse score instead of field data. Many Miami developers chase a 100/100 Lighthouse score plus celebrate when they get there. Google does not rank based on Lighthouse scores. If field data in Search Console still shows failures, the site is still penalized regardless of what Lighthouse says.
How do you fix Largest Contentful Paint failures?
Fix LCP failures by optimizing the largest visible element on the page (usually a hero image), reducing server response time, eliminating render-blocking JavaScript plus CSS, preloading critical resources, using a content delivery network (CDN), plus removing unnecessary third-party scripts. Most Miami WordPress sites fail LCP because of unoptimized images plus heavy page builder code, both of which are fixable without rebuilding the site.
The seven highest-impact LCP fixes
Optimize hero images plus use modern formats
Convert hero images to WebP or AVIF format, compress to under 200KB for above-fold images, plus size them correctly for mobile (no 4000px wide images on a 400px phone screen). Use srcset plus sizes attributes for responsive serving. This single fix often cuts LCP by 1 to 3 seconds on image-heavy Miami sites.
Preload the LCP element
Add <link rel="preload" as="image"> for the hero image in the document head so the browser starts downloading it immediately rather than waiting for the parser to discover it. Critical for image-based LCP elements that lazy-load by default.
Eliminate render-blocking JavaScript plus CSS
Move non-critical CSS into a deferred load, inline critical above-fold CSS, plus add async or defer to JavaScript tags. Many WordPress themes load 200KB+ of CSS before the page can render. Aggressive cleanup here often saves 800ms to 1.5s of LCP.
Reduce server response time (TTFB)
Time to First Byte should be under 200ms for good LCP. Slow shared hosting, unoptimized database queries, plus missing page caching all inflate TTFB. Upgrading from shared hosting to managed WordPress hosting (Kinsta, WP Engine, Cloudways) often drops TTFB from 800ms to 150ms instantly.
Add a content delivery network (CDN)
Cloudflare (free tier works), BunnyCDN, or Fastly serves static assets from servers physically close to the user. Critical for Miami sites whose users are scattered across Miami-Dade, Broward, plus Palm Beach plus need assets served from local edges, not a single distant origin server.
Remove or defer third-party scripts
Chat widgets, analytics, retargeting pixels, plus social media embeds all delay LCP. Audit every third-party script: is it actually needed on every page? Can it load after the LCP element renders? Defer or remove what you can.
Avoid lazy-loading the LCP image
Many WordPress themes apply loading="lazy" to every image including the hero. The LCP image must load eagerly. Set loading="eager" plus fetchpriority="high" on the hero image specifically. This is a 5-minute fix that often saves 500ms to 1.2s.
How do you fix Interaction to Next Paint failures?
Fix INP failures by reducing JavaScript execution time, breaking up long tasks (anything over 50ms), removing or deferring third-party scripts that block the main thread, using web workers for heavy computation, plus optimizing event handlers to do less work synchronously. INP failures are almost always caused by heavy JavaScript blocking the main thread while the user tries to interact. The fix is reducing JavaScript work, not adding more.
The five highest-impact INP fixes
Break up long JavaScript tasks
Any single task over 50ms blocks the main thread plus delays interaction response. Split long-running functions using setTimeout, requestIdleCallback, or the newer scheduler.yield() API. Heavy DOM operations are the most common culprit on WordPress sites.
Remove heavy third-party scripts
Live chat widgets, A/B test tools, plus heat-mapping scripts (Hotjar, FullStory) often add 300ms+ to INP. Audit which are essential plus remove or defer the rest. Many can load only on specific pages instead of site-wide.
Optimize event handlers
Click, scroll, plus input event handlers running heavy logic block the next paint. Debounce scroll handlers, defer non-critical work in click handlers, plus avoid synchronous DOM measurements that trigger layout. React plus Vue components with heavy re-renders on input are common offenders.
Reduce page builder bloat on WordPress
Elementor, Divi, plus WPBakery generate 200KB to 500KB of JavaScript per page. Each interaction triggers their full event system. Switching to Gutenberg blocks or a lightweight theme typically cuts INP by 100ms to 400ms. Often the single biggest INP fix available on a WordPress site.
Move expensive work to web workers
For sites with heavy client-side computation (search filters, sort operations, image processing), move the work to a web worker so it runs off the main thread plus does not block user interactions. Most marketing sites do not need this, but ecommerce plus dashboard sites often do.
How do you fix Cumulative Layout Shift failures?
Fix CLS failures by setting explicit width plus height attributes on all images plus videos, reserving space for ads plus embedded content before they load, avoiding inserting content above existing content after page load, using font-display: optional or font-display: swap with matched fallback fonts, plus avoiding animations that change layout instead of using transform. CLS is usually the easiest of the three metrics to fix because most causes are diagnosable plus addressable in CSS.
The six highest-impact CLS fixes
Set width plus height on every image
Always include width plus height HTML attributes on <img> tags so the browser reserves space before the image loads. Modern browsers calculate aspect ratio from these attributes plus prevent the page from jumping when images arrive. Most WordPress themes do this automatically. Custom-coded sites often miss it.
Reserve space for ads plus embeds
YouTube embeds, Google Ads, plus Facebook plugins inject content after page load. Wrap each in a sized container so the space is reserved before the third-party content arrives. Use aspect-ratio CSS or fixed min-height values matching the expected content size.
Avoid inserting content above existing content
Cookie banners, newsletter popups, plus notification bars that push existing content down create layout shift. Position these as overlays (position: fixed or position: absolute) instead of pushing layout. The user still sees the banner, but the page content does not move.
Match fallback fonts to web fonts
Web fonts loading mid-render cause a flash of unstyled text followed by a layout shift when the real font arrives (the FOIT plus FOUT problem). Use font-display: optional for non-critical fonts, or use size-adjust CSS plus ascent-override to make fallback fonts match the web font's metrics.
Animate with transform instead of layout properties
Animating width, height, top, or left triggers layout shift on every frame. Use transform: translate() plus transform: scale() instead. These properties trigger only paint, not layout, so they do not count toward CLS.
Preload critical fonts
Add <link rel="preload" as="font" crossorigin> for fonts used above the fold so they download in parallel with HTML parsing instead of waiting for CSS to discover them. Combined with proper fallback matching, this prevents most font-related layout shifts.
How do Core Web Vitals differ across website platforms?
Core Web Vitals difficulty varies significantly by website platform. WordPress sites with page builders (Elementor, Divi, WPBakery) typically struggle hardest because of heavy CSS plus JavaScript injected by the builder. Shopify sites generally pass LCP plus CLS but struggle with INP because of app-driven JavaScript bloat. Squarespace sites pass more often by default but lose flexibility for custom optimization. Static site generators (Hugo, Astro, Next.js with static export) almost always pass with minimal effort.
WordPress (most common Miami platform)
- Common failures. Heavy page builder code, unoptimized images plus videos, render-blocking CSS plugins, slow shared hosting, plus excessive plugin count.
- Quick wins. Switch from page builder to native Gutenberg blocks, install a caching plugin (WP Rocket, FlyingPress, or LiteSpeed Cache), move to managed WordPress hosting, plus deploy a CDN.
- Hard fixes. Refactoring custom theme code, replacing essential plugins with lighter alternatives, plus rebuilding pages without the page builder.
Shopify (Miami ecommerce)
- Common failures. Third-party app JavaScript bloat (review apps, upsell apps, currency converters), heavy theme code, plus liquid template inefficiencies.
- Quick wins. Audit installed apps plus remove anything non-essential, switch to a performance-focused theme (Dawn, Sense), plus disable apps on pages where they are not needed.
- Hard fixes. Custom theme development to remove built-in bloat plus optimize Liquid templates.
Squarespace (Miami service businesses)
- Common failures. Image heaviness in gallery sections, third-party embed CLS, plus font loading patterns.
- Quick wins. Compress images before upload, use Squarespace's native image handling rather than third-party galleries, plus reserve space for embeds.
- Hard fixes. Limited because Squarespace handles most rendering. Custom Code Injection can address specific issues but requires CSS expertise.
Webflow, Wix, plus other platforms
- Webflow. Generally passes with default settings if you avoid heavy custom animations plus unoptimized images. Strong out-of-the-box CWV performance.
- Wix. Historically poor CWV scores but improved significantly through 2024-2025. Modern Wix sites can pass with proper image optimization plus app discipline.
- Static site generators (Hugo, Astro, Next.js static export, Eleventy). Almost always pass CWV with minimal effort because they ship pre-rendered HTML plus minimal JavaScript.
Related considerations
Are Core Web Vitals a Google ranking factor?
Yes, Core Web Vitals are a Google ranking factor as part of the Page Experience signal group. Google has confirmed multiple times since 2021 that CWV contribute to rankings, primarily as a tiebreaker between pages with otherwise-equivalent content quality. Failing CWV does not block ranking entirely, but it caps how high a page can compete against passing competitors.
What is the difference between FID and INP?
FID (First Input Delay) measured only the delay before the browser could begin processing the first user interaction. INP (Interaction to Next Paint) measures the full lifetime of every interaction including processing time plus the time until the next visible frame, then reports the highest value (excluding outliers). INP replaced FID as a Core Web Vital in March 2024 because it catches problems FID missed, like slow event handlers or sluggish click responses.
Can I pass Core Web Vitals on a cheap hosting plan?
Passing Core Web Vitals on cheap shared hosting is possible for small static sites but difficult for Miami WordPress sites with normal traffic. Shared hosting typically delivers Time to First Byte of 600ms to 1500ms, which makes LCP under 2.5 seconds nearly impossible to hit consistently. Managed WordPress hosting (Kinsta, WP Engine, Cloudways) at $30 to $100 per month is often the single biggest CWV improvement available.
How long does it take Google Search Console to update Core Web Vitals data?
Google Search Console Core Web Vitals data updates with a 28-day rolling window, meaning improvements you make today take up to 28 days to fully appear in your Search Console report. The CrUX dataset feeding Search Console updates daily, but the displayed metrics aggregate the trailing 28-day window. Patience is required after making fixes.
Do Core Web Vitals affect local SEO rankings?
Core Web Vitals affect local pack rankings less than organic rankings because Google's local algorithm weighs Google Business Profile signals (proximity, reviews, citations) more heavily than page experience signals. CWV still matter for the website visit experience plus indirectly for organic rankings of city-specific landing pages, but they are not the primary lever for local pack visibility.
Frequently asked questions about Core Web Vitals
Core Web Vitals are three metrics Google uses to measure user experience on a webpage: LCP (how fast the page loads), INP (how fast the page responds to taps plus clicks), plus CLS (how much the page jumps around as it loads). A page passes Core Web Vitals when all three metrics fall into the Good band at the 75th percentile of real user sessions.
The current Core Web Vitals thresholds in 2026 are: LCP under 2.5 seconds, INP under 200 milliseconds, plus CLS under 0.1. Each metric also has a Needs Improvement band (LCP up to 4 seconds, INP up to 500 milliseconds, CLS up to 0.25) plus a Poor band beyond those values. All three metrics must hit the Good band at the 75th percentile to pass.
Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024. INP measures the full lifetime of every interaction (processing plus paint time) rather than just the delay before processing begins, which makes it a more accurate reflection of perceived responsiveness.
Check Core Web Vitals using Google PageSpeed Insights at pagespeed.web.dev (free tool for any URL), Google Search Console under Experience > Core Web Vitals (site-wide view), Chrome DevTools Performance panel (detailed lab data), or the Web Vitals Chrome extension (real-time metrics on any page you visit).
Yes, Core Web Vitals remain a Google ranking factor in 2026 as part of the Page Experience signal group. They contribute to rankings primarily as a tiebreaker between pages with otherwise-equivalent content quality plus authority. Failing CWV does not block ranking entirely but caps how high a page can compete against passing competitors.
Pages commonly pass on desktop but fail on mobile because mobile devices have slower CPUs (typically 4 to 6 times slower than mid-range desktops), slower network connections (especially on 4G), plus less RAM. Google uses mobile field data for ranking, not desktop, so a desktop-only pass still counts as a fail for SEO purposes.
Fixing Core Web Vitals takes 1 to 4 weeks of technical work for most Miami WordPress sites, depending on the specific failures plus how much theme or plugin refactoring is required. Field data in Google Search Console then takes another 28 days to reflect the improvements because of the rolling window calculation.
A good Core Web Vitals score requires LCP under 2.5 seconds, INP under 200 milliseconds, plus CLS under 0.1, measured at the 75th percentile of real user sessions. All three metrics must hit the Good band to pass. Hitting only two out of three is still a failing score in Google's system.
The most common Core Web Vitals failure on Miami business sites is LCP, usually caused by unoptimized hero images, slow server response time, render-blocking JavaScript or CSS, plus heavy WordPress page builders. INP failures are second most common, caused by JavaScript bloat. CLS failures are least common because they are usually obvious to spot plus fix.
The Lighthouse score itself does not directly affect SEO rankings. Google uses field data from real Chrome users (the CrUX dataset) for ranking decisions, not synthetic Lighthouse runs. Lighthouse is useful for diagnostic work plus pre-launch testing, but optimizing for the score without verifying field data improvements is wasted effort for SEO purposes.
Get a free technical SEO audit
We will run your site through field data plus lab analysis, identify every Core Web Vitals failure across LCP, INP, plus CLS, then give you a prioritized fix list with realistic effort estimates. Includes a 30-minute strategy call.
