Section 1
The three metrics, in plain English
Strip away the acronyms and Core Web Vitals measure three things a human visitor actually feels: Is it fast to appear? Is it quick to respond? Is it stable? (3) LCP, Largest Contentful Paint, measures loading. It's the time until the main content of your page appears. A visitor staring at a blank or half-loaded page is experiencing poor LCP. Good is under 2.5 seconds. INP, Interaction to Next Paint, measures responsiveness. This is the new one. It measures how quickly your page responds when a visitor interacts, clicks a button, opens a menu, fills a field. A page that visibly lags after you tap something has poor INP. Good is under 200 milliseconds (1). CLS, Cumulative Layout Shift, measures visual stability. It captures how much your page jumps around as it loads, the annoying experience of going to tap a button and having it leap somewhere else as an image loads in. Good is a low score (under 0.1). Together they grade the felt quality of your site: appears fast, responds fast, holds still. A visitor doesn't know the acronyms, but they feel all three, and they leave when any one fails.
Section 2
What changed: from FID to INP, and why it's harder
The metric INP replaced was called First Input Delay (FID), and the difference explains why so many sites suddenly started failing. FID only measured the delay before your page responded to the first interaction, and only the input delay, not the full response (1). So a site could feel sluggish on every click after the first and still score well on FID. INP closed that loophole: it measures every interaction across the visit and the full time until the page visually responds (1). It's a far more honest measure of how responsive your site actually feels, and because it's honest, it's harder to pass. The switch caused roughly a 5-percentage-point drop in mobile sites passing Core Web Vitals, because INP exposed the laggy interactions FID had been hiding (1). FID asked "did the page answer the first knock quickly?" INP asks "does the page answer every knock quickly, all the way through?" Most sites could fake the first; far fewer can fake all of them. That's why INP is the metric your site is probably failing.
Section 3
Why INP fails, and why it's probably your marketing tools
Here's the part with a sting for service businesses. Poor INP is almost always caused by one thing: excessive JavaScript running on the page's main thread, competing with your visitor's clicks for processing time (2). And the single most common source of that JavaScript? Third-party scripts, analytics tools, chat widgets, marketing pixels, embedded forms, ad tags (2). Every tool you bolt onto your site to track or convert visitors adds JavaScript that can make the page slower to respond, which hurts the very conversion those tools were meant to improve. This is a genuine irony worth confronting: the marketing and analytics stack a growth-minded founder loads onto their site can be the thing dragging its INP into the failing range, quietly suppressing conversion and rankings. The fix is not to abandon your tools but to be disciplined about them, audit which scripts you truly need, remove the dead ones, and load heavy ones after the page is interactive rather than blocking it during load (2). The highest-return performance intervention for most service sites is script discipline, not a rebuild. (The "your marketing tools are the culprit" emphasis is my framing of the cited INP-cause data.)
Section 4
Core Web Vitals, in one view
Why care, beyond the grades? Because Core Web Vitals sit at the intersection of the two things a service site lives on: search visibility (they're a ranking signal) and conversion (they measure the felt experience that determines whether a visitor stays and acts). The performance research is unambiguous that speed drives conversion, and INP, by measuring responsiveness across the whole visit, is the metric most directly tied to whether your site feels good to use. A failing INP isn't an abstract technical demerit; it's a visitor experiencing lag at the exact moments they're trying to interact with you. Fixing it, usually by taming your scripts, is among the highest-leverage, least-glamorous work available.
Section 5
Execute This With AI
Here is a workflow to understand and improve your Core Web Vitals with any capable AI model, paired with Google's free tools. Step 1, Get your scores. Run your homepage and a key page through Google PageSpeed Insights (free). Note your LCP, INP, and CLS, and whether each passes. List every third-party script/tool on your site (analytics, chat, pixels, embeds). Step 2, Run the diagnosis prompt: You are a web-performance advisor translating Core Web Vitals for a non-technical service-business owner. The three metrics: LCP (loading, good <2.5s), INP (responsiveness, good <200ms, the new metric that replaced FID in 2024, now the most-failed CWV), CLS (visual stability, good <0.1). Poor INP is almost always excessive JavaScript, and third-party scripts (analytics, chat, pixels) are the most common cause. My PageSpeed results: LCP [X], INP [X], CLS [X], pass/fail each: [X]. My third-party scripts/tools: [LIST]. Do five things: 1. Explain in plain terms which metrics I'm failing and what a visitor experiences. 2. For INP specifically, tell me which of my third-party scripts are most likely hurting it and which I could remove or defer. 3. Give me the highest-return fix for each failing metric, in non-technical terms. 4. Write a brief I can hand a developer to fix these. 5. Tell me which fixes I (or a freelancer) can do without a full rebuild. Be practical; prioritize script discipline before big rebuilds. Step 3, Script audit. "List every third-party script on my site, what it does, whether I genuinely need it, and the conversion-vs-speed tradeoff of keeping each." Tools and expected output. Any frontier chat model, plus Google PageSpeed Insights (free). Expect a plain-English diagnosis, a script-by-script INP assessment, prioritized fixes, and a developer brief. The QA discipline: PageSpeed gives you both "field" data (real users) and "lab" data (a simulated test), the field data is the truth that affects rankings, so prioritize it, and re-measure after changes rather than trusting that a fix worked. The model interprets the report and prioritizes; the real scores are your ground truth. Google changed how it grades your site in 2024, made the responsiveness metric honest, and most sites have been quietly failing it ever since, often because of the very marketing tools their owners added to grow. Core Web Vitals aren't an abstract technical scorecard; they measure whether your site appears fast, responds fast, and holds still, which is exactly what determines whether a visitor stays and converts. Learn the three, find your failing one (it's probably INP), tame the scripts that cause it, and you improve both your rankings and the felt experience that books calls, usually without rebuilding anything.
Section 6
Keep reading
Keep reading in the Performance & Core Web Vitals cluster and across the library: [The Revenue Math of a Faster Website (With Real Numbers)](/blog/the-revenue-math-of-a-faster-website-with-real-numbers), [Loading States and Perceived Speed: Making Your Site Feel Fast While It Works](/blog/loading-states-and-perceived-speed-making-your-site-feel-fast-while-it-works), [Speed-to-Lead: Why Page Speed and Reply Speed Are the Same Conversion Lever](/blog/speed-to-lead-why-page-speed-and-reply-speed-are-the-same-conversion-lever). Also relevant: [The Service-Business Website Priority Stack: What to Fix First When Everything Needs Work](/blog/the-service-business-website-priority-stack-what-to-fix-first-when-everything-needs-work), [Core Web Vitals in Business Terms: What a Slow Website Costs You](/blog/core-web-vitals-in-business-terms-what-a-slow-website-costs-you).