Core Web Vitals.

Core Web Vitals entered Google's ranking algorithm in 2021 and most business owners still don't know what they measure, how their site scores, or what a failing score actually costs them. That's not a criticism — the terminology is opaque by design. "Largest Contentful Paint" is not a phrase that explains itself to a dentist, a contractor, or a restaurant owner who just wants a website that works.

This guide strips out the jargon. We'll explain what each metric measures, what a good score looks like, what causes a poor score, and how to fix it. If your site is on a page builder, some of this will be uncomfortable reading. That's intentional — the performance gap between builder-built and custom-coded sites is measurable, and it shows up directly in rankings and lead flow.

01What Core Web Vitals actually measure.

1.1What are the three Core Web Vitals, in plain language?

LCP (Largest Contentful Paint) measures how long it takes for the main content of a page — typically the hero image or a large text block — to appear on screen. It's the "when does the page feel loaded" metric. CLS (Cumulative Layout Shift) measures how much the page jumps around as it loads — images that cause text to shift, buttons that move before you tap them. It's the "does this page feel stable" metric. INP (Interaction to Next Paint) replaced FID in 2024 and measures how quickly a page responds to user input — a tap, a click, a keypress. It's the "does this page feel responsive" metric.

1.2What are the "good" score thresholds for each metric?

Google's current thresholds: LCP should be 2.5 seconds or under for a "good" score, between 2.5 and 4.0 seconds is "needs improvement," above 4.0 seconds is "poor." CLS should be 0.1 or under for good, 0.1 to 0.25 needs improvement, above 0.25 is poor. INP should be 200 milliseconds or under for good, 200–500ms needs improvement, above 500ms is poor. These thresholds are measured at the 75th percentile of real user experiences — meaning 75% of your visitors need to have a good experience, not just the average visitor on a fast connection.

1.3Where can I check my site's Core Web Vitals scores?

Three reliable sources: Google Search Console (Core Web Vitals report — shows real-user data from Chrome users visiting your site, grouped by mobile and desktop); PageSpeed Insights (pagespeed.web.dev — enter your URL, shows both lab data and real-user data if your site has enough traffic); Google Chrome DevTools (for developers — shows live scores during a page load). Search Console is the most authoritative because it reflects what Google actually sees from real users. Lab tools are useful for diagnosis but may differ from real-user data.

1.4My scores look fine on desktop but poor on mobile. Why?

Mobile and desktop are scored separately — and mobile almost always scores lower. The reasons: mobile devices have slower processors (affecting INP), cellular connections are less consistent than broadband (affecting LCP), and page builders that load large JavaScript bundles hurt mobile disproportionately because less powerful chips parse JS more slowly. Google's ranking algorithm uses mobile scores as the primary input — not desktop. If your mobile LCP is 5 seconds and your desktop LCP is 1.8 seconds, your ranking signal is based on 5 seconds.

1.5Are Core Web Vitals the same as page speed?

Related, but not the same. Page speed tools typically measure a single metric — time-to-first-byte, time-to-interactive, total page size — in a lab environment. Core Web Vitals measure three specific user-experience signals collected from real users in the Chrome browser. A site can have a fast page speed score and still fail Core Web Vitals if, for example, the main image loads quickly but the layout shifts significantly during load (CLS failure). Both matter, but Core Web Vitals are the direct ranking signal.

02How they affect rankings and leads.

2.1How much do Core Web Vitals actually affect Google rankings?

The ranking weight of Core Web Vitals is a "tiebreaker" in Google's framing — meaning content relevance and authority still dominate, but when two pages are similarly relevant, the one with better performance wins. In practice, for local service businesses competing on the same geographic and service terms, performance is often the differentiation. If you and your competitor both have decent content about "Tucson roof repair," the one with better Core Web Vitals scores — especially on mobile — has a measurable ranking edge.

2.2Do Core Web Vitals affect the Google Local Pack (Maps results)?

Indirectly. The Local Pack ranking is primarily driven by proximity, relevance, and prominence (reviews, citations, authority). Core Web Vitals don't directly rank Local Pack results. But when a user clicks from the Local Pack to your website, the experience they encounter — including your site's performance — affects whether they convert. A slow site after a Local Pack click loses the visitor even after Google delivered them. Performance affects the conversion side of local traffic, not the listing rank directly.

2.3Is there data connecting Core Web Vitals to conversion rate?

Yes, and it's substantial. Google's own research found that sites moving from poor to good LCP scores see an average bounce rate reduction of 24%. Vodafone found that a 31% improvement in LCP corresponded to an 8% increase in sales. In our own audits on Tucson client sites, moving from a failing LCP (4+ seconds) to a passing one (under 2.5 seconds) consistently produces a 15–30% improvement in pages-per-session and a reduction in bounce rate on mobile. The correlation is consistent enough to treat performance as a conversion lever, not just an SEO concern.

2.4Do page builders consistently fail Core Web Vitals?

As a category, yes — though specific performance varies by implementation. The structural problem is that page builders load JavaScript and CSS for every feature the plugin includes, whether that feature is used on a given page or not. Elementor, for example, has historically loaded 500KB–1MB of JavaScript on a page that uses ten percent of its features. That load hits the INP score (JS parsing delay) and the LCP score (render-blocking resources). Custom-coded themes can ship under 50KB of total JavaScript for a comparable page. The gap is structural, not incidental.

2.5If my competitor's site also fails Core Web Vitals, does it matter?

It matters less for the ranking differential — if you're both failing, neither gets the advantage. But it matters enormously for the conversion differential. A failing Core Web Vitals score doesn't just affect Google rankings; it affects every user who visits from any source — direct, referral, social, email. If you fix your scores and your competitor doesn't, you win the performance advantage across all channels, not just search. And as more competitors do fix their scores over time, being behind becomes a disadvantage that compounds.

03LCP — Largest Contentful Paint.

3.1What causes a high (slow) LCP score?

The most common causes on service business sites: (1) An unoptimized hero image — a full-size JPG or PNG served at original resolution without compression or a next-gen format like WebP or AVIF. (2) Render-blocking resources — JavaScript or CSS that must load and execute before the browser can paint the largest element. (3) Slow server response time — cheap shared hosting with time-to-first-byte over 600ms. (4) No content delivery network (CDN) — serving files from a single server location when your visitors are spread across Tucson and Arizona. (5) No preloading of the LCP element — the browser discovers the hero image late in the load sequence.

3.2How do I optimize my hero image to improve LCP?

Five specific steps: (1) Convert the image to WebP format — typically 30–50% smaller than an equivalent JPEG with similar visual quality. (2) Serve the correct size — a 2400px-wide image displayed at 800px wide wastes bandwidth. Use srcset to serve device-appropriate sizes. (3) Use a CDN to serve the image from a location closer to the user. (4) Add <link rel="preload"> in the document head specifically for the LCP image — this tells the browser to prioritize it early. (5) Set explicit width and height attributes on the image element to prevent layout shifts during load.

3.3How much does hosting affect LCP?

Significantly. Time to First Byte (TTFB) — the server's response latency — is the foundation of LCP. If your server takes 1.2 seconds to respond before sending any content, your LCP can't be under 2.5 seconds no matter how well-optimized your images are. Shared hosting plans under $10/month often have TTFB over 800ms. Managed WordPress hosting (WP Engine, Kinsta, Cloudways) typically runs 150–400ms TTFB. That's a 600–1,000ms headstart on every page load — for $30–$50/month, it's the highest-return hosting upgrade a small business can make.

3.4What is "render-blocking" and how do I fix it?

Render-blocking happens when the browser encounters a CSS or JavaScript file in the document head that it must fully download and process before it can display any content. Every second of render-blocking delay is a second added to your LCP. Fixes: move non-critical JavaScript to the document footer (or use the defer attribute); inline critical CSS directly in the document head so above-the-fold content loads without waiting for a separate file; and use asynchronous loading for third-party scripts (analytics, chat widgets, social sharing buttons) that don't affect the initial page render.

04CLS and INP — stability and interactivity.

4.1What causes layout shift (CLS), and why does it frustrate users?

Layout shift happens when elements move after they've initially rendered — usually because their final size wasn't known when the browser first laid out the page. Common causes: images without explicit width and height attributes (browser reserves no space, then jumps when the image loads); web fonts loading and swapping (text briefly renders in a fallback font, then jumps to the web font); late-loading ads or embeds that push content down; and cookie consent banners that appear above content without reserved space. The user experience: you're reading a paragraph, the text suddenly jumps down four inches, you've lost your place and your trust in the site.

4.2How do I fix layout shift on images?

Always specify width and height attributes on img elements in HTML — this tells the browser to reserve the correct space before the image loads, eliminating the shift. Use the CSS aspect-ratio property for responsive images to maintain the reserved space at different viewport sizes. For background images used as hero sections, reserve the space explicitly with a min-height or aspect-ratio on the container. These are simple, zero-cost fixes that eliminate the most common source of CLS on service business sites.

4.3What is INP and how is it different from the old FID metric?

FID (First Input Delay) measured only the first interaction a user had with a page — and only measured the delay before the browser started processing it, not whether the visual update was fast. INP (Interaction to Next Paint) measures all interactions throughout a page visit, and measures the full response time including the visual update. It's a stricter, more comprehensive measure of interactivity. A page that responds quickly to a first click but bogs down when a user scrolls through content and taps a button lower on the page — FID would pass it; INP would catch the failure.

4.4What causes poor INP scores?

INP failures are almost always caused by JavaScript doing too much work on the main thread — preventing the browser from painting a visual response to user input. Common causes: heavy page builder JavaScript that runs continuously; unoptimized event listeners that trigger expensive calculations on every click or scroll; third-party scripts (chat widgets, heatmap tools, social embeds) that block the main thread; and large JavaScript bundles that take long to parse on lower-powered mobile devices. The fix is almost always JavaScript reduction — either by removing scripts, deferring them, or breaking long tasks into smaller asynchronous chunks.

4.5Is there a quick way to check which scripts are hurting my INP?

Yes. Open Chrome DevTools, go to the Performance tab, and run a profile while interacting with your page. The "Long Tasks" visualization shows which JavaScript tasks are blocking the main thread for more than 50ms — those are your INP culprits. The "Bottom-Up" and "Call Tree" views show which specific functions or scripts are responsible. If you see your page builder's JavaScript dominating the Long Tasks — which is common in Elementor and similar tools — that's structural, not easily fixable without a rebuild. If you see a third-party script responsible, that's often removable or replaceable with a lighter alternative.

05How to diagnose and fix poor scores.

5.1What's the right sequence for fixing Core Web Vitals on a poor-performing site?

Start with diagnosis, not fixes. Run PageSpeed Insights on your top five pages — home, primary service pages, contact. Identify which metrics are failing and by how much. Then address in this order: (1) Server/hosting if TTFB is over 600ms — no front-end fix compensates for a slow server. (2) LCP image optimization — usually the highest-impact, lowest-effort fix. (3) Render-blocking resources — defer JavaScript, inline critical CSS. (4) CLS — add dimensions to images and fonts. (5) INP — audit and reduce JavaScript. This sequence is ordered by impact-to-effort ratio.

5.2Can WordPress plugins fix Core Web Vitals, or do I need a developer?

Plugins can help with some issues but not others. Caching plugins (WP Rocket, LiteSpeed Cache) improve TTFB and can defer JavaScript, reducing LCP and INP. Image optimization plugins (Imagify, ShortPixel) convert images to WebP and generate srcset. CDN plugins distribute assets geographically. What plugins can't fix: the structural JavaScript overhead of a page builder itself; a server that's simply too slow for the traffic load; or deep CLS caused by theme architecture. Plugins are band-aids on performance problems caused by the theme; a custom-coded theme avoids most of the underlying issues.

5.3How do I know if my hosting is the bottleneck?

Check your TTFB (Time to First Byte) in PageSpeed Insights under "Server response time." A good TTFB is under 200ms. Anything over 600ms is a significant bottleneck. You can also test TTFB directly at tools like GTmetrix or WebPageTest. If your TTFB is high, try enabling server-side caching (most managed hosts include this) before moving to a new host — caching can reduce TTFB dramatically. If TTFB is still over 400ms with caching enabled, the hosting tier is likely insufficient for the site's traffic.

5.4My site is on a page builder and failing Core Web Vitals. What are my options?

Honest answer: three paths, in order of effectiveness. (1) Add a caching plugin and image optimization plugin — this can move you from "failing" to "needs improvement" on LCP and sometimes CLS, but rarely to "good" on INP. (2) Reduce third-party scripts aggressively — remove any plugin or embed you don't have hard evidence is earning its performance cost. (3) Rebuild on a custom-coded theme — the only fix for structural page-builder JavaScript overhead. Option 3 is the only one that consistently reaches "good" across all three metrics. Options 1 and 2 are triage.

5.5After fixing Core Web Vitals, how long until my rankings improve?

Google's CrUX (Chrome User Experience Report) data — which feeds Core Web Vitals rankings — updates monthly. After fixing performance issues, you should see the improvements reflected in Search Console's Core Web Vitals report within 28 days. Ranking changes typically follow within four to eight weeks of the data update, though other ranking factors mean the effect isn't always cleanly isolated. Sites moving from "poor" to "good" on LCP in competitive local markets routinely see a 2–5 position improvement on mobile search within 60–90 days of the fix.

06Hiring signals — who builds for performance.

6.1What questions should I ask an agency about performance before hiring?

Ask: "What PageSpeed Insights scores do your recent sites achieve on mobile?" Ask for specific URLs — not claimed scores, but verifiable ones you can run yourself. Ask: "What stack do you build on, and how does it handle Core Web Vitals?" An agency building on a custom-coded WordPress theme should be able to answer this specifically. Ask: "Do you include performance testing as part of your launch process?" If the answer is yes, ask what tools they use and what threshold they build to. Vague answers mean they're not measuring.

6.2How can I verify an agency's performance claims?

Run their portfolio sites through PageSpeed Insights yourself. Look at mobile scores specifically. Look at the actual Core Web Vitals data (real-user data, not just lab scores) — if a site has enough traffic, PageSpeed Insights will show field data. An agency that builds performant sites will have portfolio sites that pass Core Web Vitals. An agency that builds on Elementor or Divi will often have portfolio sites in the "needs improvement" or "poor" range. The portfolio is the truth — not the proposal.

6.3Is Core Web Vitals performance something I should require in my contract?

Yes — specify it as a launch criterion. "The delivered site will pass Core Web Vitals (LCP under 2.5s, CLS under 0.1, INP under 200ms) on mobile as measured by PageSpeed Insights field data or, for new sites without field data, by the PageSpeed Insights lab score." Agencies who can meet this threshold will agree to it without hesitation. Agencies who can't will push back or add vague language about "best efforts." The pushback tells you something important about what you're being sold.

6.4If a new agency inherits my underperforming site, can they fix it without a rebuild?

Sometimes. If the core performance problem is hosting, image optimization, or third-party scripts, those can be addressed without rebuilding. If the core problem is a page builder's structural JavaScript overhead, a partial fix is possible (caching, JS deferral) but the site will remain in "needs improvement" territory at best. Any agency that inherits a page-builder site and promises a full "good" Core Web Vitals score on mobile without a rebuild is either optimistic or inaccurate. Get specific: what scores do they expect to achieve, on what timeline, and how will they measure and report it?