Core Web Vitals in 2026: INP, and Why Your PageSpeed Score Lies

You ran your site through PageSpeed Insights, saw a number in red, and now you’re wondering whether you need a new website, a new host, or just a stiff drink. Before you spend a dollar fixing anything, it’s worth knowing what that number is actually measuring, because the tool most owners trust the most is also the one most likely to be misread.

We build garage door websites for a living, so we’re not a neutral referee here. We have an obvious interest in you thinking your current site could be better. With that said, this piece is not a pitch. It’s a plain explanation of the three numbers Google actually grades you on, why your score and your customer’s real experience can tell two different stories, and which of the two is worth acting on.

The quick answer

Google grades your site on three things: how fast the main content shows up (LCP), how fast the page responds when someone taps something (INP), and whether things jump around while a visitor is trying to read or tap (CLS). Good targets are LCP at 2.5 seconds or under, INP at 200 milliseconds or under, and CLS at 0.1 or under, measured at the 75th percentile of your real visitors.

If you ran PageSpeed Insights and saw a low lab score but a page that “passes” on the real-world Core Web Vitals assessment, or the reverse, that’s not a bug. They’re two different tests, and the field data (the one built from your actual visitors) is the one that matters. If your site gets little traffic, you may not have field data at all yet, and that’s normal, not a red flag.

The most common real causes on a garage door site, roughly in order, are oversized photos uploaded straight off a phone, an overloaded page builder, third-party scripts like chat widgets and tracking pixels, and only after all of that, a weak host. Fix in that order and you’ll fix most of what’s actually wrong. Chasing a perfect 100 past that point is mostly vanity.

The three numbers, in plain English

Google calls them Core Web Vitals, and they measure three separate things about how a page feels to use, per its own documentation on web.dev.

• LCP, Largest Contentful Paint. How long it takes for the biggest visible thing on the page, usually your hero photo or headline, to actually show up. This is the “did anything load yet” number. Good is 2.5 seconds or faster.
• INP, Interaction to Next Paint. How long the page takes to respond after someone taps a button, opens a menu, or fills in a field. This is the “does the page feel stuck” number. Good is 200 milliseconds or faster.
• CLS, Cumulative Layout Shift. Whether things move around while a visitor is reading or about to tap something, like a photo that loads late and shoves the phone number two inches down the screen right as someone’s thumb lands on it. Good is 0.1 or lower, and the scale isn’t seconds, it’s a shift score with no unit.

All three get measured at the 75th percentile of real visits, across mobile and desktop, over a rolling window. That detail matters more than it sounds like it should, and we’ll come back to it.

If someone’s still telling you to fix “FID,” that’s a useful filter

For years, the third metric in this group was First Input Delay, or FID, which measured the delay before a page responded to the very first tap. In March 2024, Google fully retired FID and replaced it with INP as the official interactivity metric. INP is not experimental or in beta. It has been the standard for a while now.

The practical use of that fact: if a plugin, a blog post, an SEO vendor, or anyone else is still talking about “fixing your FID,” you’re looking at advice that’s at least two years stale, written before the current standard existed. It’s a fast way to tell whether the person or tool giving you speed advice is keeping up.

Lab data and field data are not the same test

Here’s the part almost nobody explains clearly, and it’s the reason your PageSpeed score can seem to contradict itself.

PageSpeed Insights actually runs two different assessments and shows you both.

Lab data is a simulated test that runs right at that moment, on a mid-tier device profile Google defines, under lab conditions. It’s a snapshot, run once, right now, by a tool, not a person.

Field data is different. It’s pulled from the Chrome UX Report, which aggregates real Core Web Vitals measurements from actual Chrome users who visited your specific page over the trailing 28 days. This is not a simulation. It’s what genuinely happened on real phones, on real connections, in the real world.

A page can score in the 90s on the lab test and still fail the real-world Core Web Vitals assessment, or the other way around, score poorly in the lab and pass comfortably in the field. Both outcomes are normal, and they happen for a boring reason: the lab test runs once under one set of conditions, while the field data reflects a mix of visitors on a mix of devices and networks over nearly a month.

Why the number on your screen and your customer’s real experience can disagree

The 75th percentile detail from earlier is the whole story here. Google doesn’t grade your site on its best moment or its average moment. It grades you on the point where three out of four of your real visits land or beat, which means the worst quarter of your traffic (the person on an old phone, on a weak rural connection, standing in a driveway with one bar) pulls that number down even if most visits are fine.

That’s also why your own experience testing the site on office wifi, on a current phone, on a fast connection, can feel nothing like what Google reports. You’re testing your best case. Google is grading closer to your worst case. If you want to see the number that actually matters, you have to go find the worst case yourself, which is what the driveway test further down is for.

Where garage door sites actually bleed speed

In roughly the order they tend to matter, here’s what actually slows down a service-business website like yours.

1. Oversized photos straight off a phone camera. A modern phone photo can run several megabytes at full resolution. A web page has no business loading that at full size. This is, by a wide margin, the most common cause we see, and it’s also the easiest to fix: compress and properly size images before they go on the page.
2. Page builder overhead. Drag-and-drop builders like Elementor or Divi on WordPress render a lot of extra markup and CSS to make the visual editor work, and that overhead ships to every visitor whether they ever touch the editor or not. It’s the trade you make for convenience.
3. Third-party scripts. Chat widgets, tracking pixels, review-badge embeds, and font-loading scripts from other companies’ servers all add code your page has to load and run before it can respond to a tap, which is exactly what hurts INP. A chat widget in particular is a common INP culprit, because it has to load and initialize before the page can respond quickly to anything. If you’re weighing a chat tool for lead capture, our sister brand, Garage Door Lead Engine, covers what to look for in a website chat widget built for lead qualification without it being the thing that tanks your INP number.
4. The host. Real, but usually the smallest factor of the four, and the one everyone blames first because it’s the easiest to point at. A weak host makes a bloated page slower. It rarely makes a lean page slow.

Platform by platform, where each one tends to land

The platform you’re on doesn’t set your score directly, but it does set how hard the first two causes above are to avoid.

Platform	Published price (checked 2026-08-28)	Typical speed profile	Where it gets hard
WordPress with Elementor or Divi	Software is free; hosting, a theme, and the page builder itself typically run tens of dollars a month once combined	Heaviest markup and script load of the group by default; every added module, slider, or plugin adds more of both	Nothing about a page builder fixes itself; someone has to audit what’s actually running on the page and keep doing it as plugins update
A static or custom-built site (the approach we use)	Not sold as a monthly plan; typically a flat one-time build fee rather than a subscription	Ships close to the minimum by default, so LCP and INP tend to start ahead of a page-builder site with the same content	You lose drag-and-drop convenience; changes go through a developer or a system built for that, and unoptimized photos can still sink it
Wix	$19 to $159/mo, billed annually, tax not included (wix.com/upgrade/website, checked 2026-08-28)	Wix’s own infrastructure is reasonably quick out of the box; it degrades as you add apps from its App Market	Limited control over what loads and when; you can’t simply remove a slow third-party script the way you can on a site you fully own
Squarespace	Core $29/mo, Plus $49/mo, billed annually, current published pricing includes an active sitewide discount (squarespace.com/pricing, checked 2026-08-28)	Similar story to Wix: solid base templates, degrades as you add galleries, blocks, and embeds	Same closed-platform ceiling; you’re optimizing inside guardrails Squarespace set, not ones you control, and the sticker price moves with whatever promotion is running that month

None of this means WordPress or Wix or Squarespace is unusable. Plenty of sites on all three post fine numbers. It means the platform decides how much rope you have, and how much of the fixing is on you versus baked in.

The tool most owners trust is also the one most likely to mislead you

This is the honest, uncomfortable part. PageSpeed Insights is free, it’s from Google, and it’s the first place almost every owner checks. It’s also the tool most likely to leave you with the wrong impression, for reasons that have nothing to do with the tool being bad.

The specific way PageSpeed misleads people: a low-traffic contractor site frequently shows only a lab score, with the field verdict reading “not enough data.” Owners see a lab number in the 60s or 70s and panic, assuming that’s their real-world grade. It isn’t. It’s one simulated run under one set of test conditions, and Google’s own ranking systems weight field data, not the lab score, according to Google’s page experience documentation. A low lab score with no field verdict tells you almost nothing about how Google, or your customers, actually experience the page. Telling an owner their favorite free tool is easy to misread is a harder sell than telling them their host is bad, but it’s the more honest one.

What’s actually worth fixing, and what’s vanity

Worth fixing: getting all three metrics into the “Good” range at the 75th percentile, because that’s the threshold tied to an actual, defined standard, and because a page that responds slowly genuinely frustrates a visitor trying to get your phone number or fill out a form.

Not worth fixing: chasing a 100 once you’re already comfortably in the Good range on all three. The distance between a 92 and a 100 on the lab score is mostly invisible to an actual visitor and rarely moves anything that matters. If your LCP is at 1.8 seconds, your INP is at 140 milliseconds, and your CLS is at 0.04, you’re done. Stop opening the tool.

The mobile test that beats every online tool

Every automated speed test, PageSpeed included, is a proxy for the thing you actually care about, which is what a real customer experiences. There’s a better test, and it takes two minutes.

Stand in your driveway, or anywhere outside your building, on your phone, on cell data, not your office wifi. Load your own homepage like a stranger would. Count the seconds out loud. Then tap your own phone number and see if it dials. Then open your contact form and start filling it in, and notice whether anything sticks or lags while you type.

That’s closer to your actual 75th-percentile visitor than any lab tool will ever get you, because it’s a real device, on a real connection, under conditions you didn’t get to choose. If it feels slow standing in your own driveway, it’s slow. No score is needed to confirm that.

What usually goes wrong when owners try to fix this themselves

The most common mistake is reaching for a “speed plugin” before touching the photos. Speed plugins can help at the margins, mostly by adding caching and minifying code, but they can’t shrink an oversized image that never should have been uploaded at full resolution, and they can’t remove a page builder’s overhead, because the plugin isn’t what’s generating that overhead in the first place.

The second most common mistake is treating the lab score as gospel and rebuilding a whole site to chase a number that was never the number Google actually uses to judge you. The lab score is a diagnostic snapshot, not the grade.

The third is fixing speed in isolation from everything else on the page. A fast page that buries the phone number, doesn’t say what towns you cover, or has a contact form that quietly fails is still a page that doesn’t get the call. We laid out the fuller list of what actually earns a call in our garage door company website checklist, and speed is one item on that list, not the whole list.

There’s a related mistake worth naming even though it’s not strictly a speed issue: a fast page that captures a lead does you no good if nobody follows up quickly once it’s captured. That’s a different problem with a different fix, and it’s covered in our sister brand’s guide to speed-to-lead for garage door companies, which is worth a look once your page itself is actually fast.

How to check yours properly, in about five minutes

1. Go to pagespeed.web.dev and enter your homepage URL. Run it on mobile, since that’s where your worst-case visitors are.
2. Look for the field data section first. If it says “not enough data,” that’s expected for a lower-traffic site, and you should move straight to step 4. If it shows real numbers, note your LCP, INP, and CLS.
3. Scroll to the lab data and the diagnostics section. Look specifically for “Largest Contentful Paint element” (usually tells you which image or block is slow) and any flagged unused JavaScript or oversized images.
4. Do the driveway test from above on your own phone, on cell data.
5. If your busiest service pages, not just the homepage, are the ones customers actually land on from search, run those too. A fast homepage with a bloated spring-repair page is still a problem.

How to tell you got it right

You got it right when all three metrics sit comfortably in the Good range at the 75th percentile, when the driveway test doesn’t make you wince, and when you can stop thinking about the score entirely because nothing about it is costing you a visitor anymore. You did not get it right if you’re still refreshing PageSpeed Insights looking for triple digits. That number was never the finish line, and chasing it past the Good threshold spends time you could put toward the things that actually decide whether the phone rings: your service pages, your service area, your reviews, and whether your form works at all.