Three metrics deciding whether Google trusts your homepage.
You ran your shop's homepage through PageSpeed Insights because a competitor two towns over kept outranking you, and it handed back a red 41 on mobile plus three acronyms you'd never seen: LCP, INP, CLS. Those are the Core Web Vitals, Google's real-world measure of how fast your page shows its main content, how quickly it reacts when someone taps, and whether things jump around while it loads. They've been an official ranking signal since June 2021, so a failing score can quietly cost you positions and visitors at the same time. The good news is that passing is achievable for a small business site, and a lot of it is decided by the platform you're on before you touch a single setting.
LCP, loading
Largest Contentful Paint is the moment your biggest visible element, usually the hero image or the main headline block, finishes rendering. It's the instant a visitor feels the page has actually arrived. Google wants that inside 2.5 seconds. The usual culprits are heavy uncompressed images, slow hosting, and scripts that block the page from drawing.
INP, responsiveness
Interaction to Next Paint measures the lag between someone tapping a button, opening a menu, or typing in a form and the page visibly responding. It replaced the older First Input Delay metric in March 2024 and it's stricter, because it watches every interaction across the visit, not just the first. Aim for under 200 milliseconds. Heavy JavaScript and third-party scripts are what blow it.
CLS, visual stability
Cumulative Layout Shift scores how much your content jumps around unexpectedly as the page loads, that maddening moment where the button moves right as you go to tap it. It's driven by images with no reserved dimensions, fonts swapping in late, and ads or banners injecting themselves above what you were reading. Keep the score under 0.1.
Pass, borderline, or actively hurting you.
Google sorts every page into one of three bands per metric. You want "good" on all three, measured on mobile, because that's the version Google leans on for ranking.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP (loading) | Under 2.5s | 2.5s to 4.0s | Over 4.0s |
| INP (responsiveness) | Under 200ms | 200ms to 500ms | Over 500ms |
| CLS (visual stability) | Under 0.1 | 0.1 to 0.25 | Over 0.25 |
One detail that trips owners up: the scores Google actually ranks on aren't the lab simulation at the top of PageSpeed Insights. They're field data, real measurements from real Chrome visitors, pooled over a rolling 28-day window in what's called the Chrome User Experience Report. A brand-new site with almost no traffic won't even have field data yet, so it shows "no data" rather than a pass or fail. That lag is worth knowing before you panic about a single lab number.
The half of your competitors quietly failing this.
Two reasons this earns a spot on a small business owner's short list rather than a developer's. First, it's a confirmed ranking factor. It won't vault a thin page over a genuinely better one, but when you and a local competitor are otherwise close, page experience is a real tiebreaker, and it applies to both mobile and desktop results. Second, and honestly the bigger one, is what slow does to the people who do land on your site. Google's own research found that as a page's load time goes from one second to three, the chance a visitor bounces climbs by about 32 percent; by five seconds it's roughly 90 percent. Separate performance studies put a one-second delay at up to 7 percent fewer conversions. For a business where a handful of enquiries a week is the difference, that's not abstract.
The encouraging part is the scoreboard. Only around half of mobile sites currently pass all three Core Web Vitals. If you're in the half that does, you've got a measurable edge over the half that doesn't, and passing is far more attainable than most owners assume once they see where the failures actually come from.
Most of a Core Web Vitals score is decided by your platform before you ever open the settings.
Three free tools, in the order that helps.
You don't need a paid audit to see where you stand. Everything below is free and takes minutes.
- PageSpeed Insights (pagespeed.web.dev). Paste a URL, get both the lab score and, if the page has enough traffic, the field data that Google ranks on. Read the field panel first; the lab gauges are a diagnostic, not your grade.
- Google Search Console, Experience then Core Web Vitals. This is the one that scales. Instead of checking pages one at a time, it groups every URL on your site into passing and failing buckets, split by mobile and desktop, so you can see which templates are dragging the whole site down.
- Lighthouse in Chrome DevTools. Press F12, open the Lighthouse tab, run a report. It's the most technical of the three and gives line-by-line diagnostics, best kept for when you already know what you're chasing.
The same handful of causes, on nearly every failing site.
Poor scores are rarely mysterious. LCP fails when a giant unoptimized image loads over slow shared hosting with no CDN in front of it, so the largest thing on the page shows up late. That is also the single most common reason WordPress sites end up slow: a heavy theme, a stack of plugins, and a budget host all fighting the same first paint. INP fails when there's too much JavaScript to chew through, usually a pile of third-party scripts (chat widgets, analytics, ad tags, a booking embed) plus whatever plugins are running. CLS fails when images ship without width and height set, fonts swap in after the text has already drawn, or a cookie banner shoves everything down half a second in.
The standard fixes follow the causes: compress images and serve them as WebP, always set explicit dimensions, put a CDN in front of your assets, defer non-critical scripts, cut plugins you don't need, and move off the cheapest shared hosting tier. Every one of those is real and worth doing. The catch nobody mentions in the how-to lists is that on a plugin-based platform this is not a one-time job. It's continuous maintenance, re-tuning after every plugin update and theme change, permanently fighting the platform's defaults. The far cheaper move, if you're not already locked in, is to start on a stack where those defaults are already fast.
Passing by construction, not by constant tuning.
This is the honest fork in the road. You can chase a passing score on a platform built to be slow, or start on one where the causes above mostly don't exist. Devani, the free open-source CMS running this blog, sits firmly in the second camp, and it's worth seeing why on the merits.
Typical plugin-based build
Fast is possible, but it's a job you never finish.
- ✓ Total control and a plugin for every feature you can name
- × A cold mobile test on a typical build posts an LCP around 7.2 seconds, well into the poor band, with a performance score near 47
- × Every plugin adds JavaScript that pressures INP, and every update can undo your last round of tuning
- × Passing means ongoing performance work, or paying someone to own it
Devani
Database-free, so the slow parts were never installed.
- ✓ No database to query and no plugin stack: pages are plain files, server-rendered as clean HTML and served statically from a CDN
- ✓ Images auto-compress to WebP on the CDN, so the usual LCP killer is handled before you notice it
- ✓ In a cold lab test the desktop side reads a 0.7-second LCP at a 100 performance score, and a live Devani site posts a 1.8-second mobile LCP, both under the 2.5-second bar
- × A fast shell can't save you from a heavy third-party widget you embed yourself; drop a bloated chat or booking script in and you can still hurt INP and CLS
The gap that matters most is the mobile one, since that's the version Google grades. Desktop-to-mobile drops are normal because the test throttles the connection, but the size of the drop is the tell: a fast static build loses roughly 8 points from desktop to mobile, where a heavier platform routinely sheds around 30. That's the difference between a site that squeaks a desktop pass and fails the phones, and one that clears the bar on both. If you want the fuller picture on what a plugin platform actually asks of you over time, the WordPress review walks through the maintenance math in detail.
On the AI point, be precise, because WordPress is catching up here. WordPress.com shipped an MCP integration and the Vibe AI plugin arrived by mid-2026, so connecting an assistant to WordPress isn't exotic anymore. Both work well only inside the block editor, though. Devani is MCP-native and works hand in hand with an LLM inside the visual builder: when a report flags something, you connect your own ChatGPT or Claude account, no API keys, and describe the fix in plain language. Because a fast build has fewer things to fix in the first place, that comes up less often than you'd think.
Are Core Web Vitals a Google ranking factor?
Yes, since June 2021, as part of the page experience signals. They're a tiebreaker rather than an override: strong content still wins, but between two comparable pages, the one that passes has the edge, on both mobile and desktop results.
What's a good Core Web Vitals score?
All three metrics in the "good" band on mobile: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. Google grades on field data from real visitors, not the lab simulation.
Why does my page pass on desktop but fail on mobile?
The mobile test throttles the connection and CPU to mimic a mid-range phone on a so-so network, which exposes heavy images and JavaScript that desktop hides. Since Google ranks primarily on the mobile experience, the mobile band is the one to fix first.
Can I fix Core Web Vitals without a developer?
Partly. Compressing images, setting width and height on them, and cutting unused plugins are all owner-level jobs. Render-blocking scripts, CDN setup, and hosting-level fixes usually need someone technical. On a platform where fast is the default, most of this is simply moot, which is the cheaper route if you're not already committed to a heavy stack.
My site is brand new and shows "no data." Is that bad?
No. Field data needs enough real Chrome visitors over a 28-day window before it appears, so a new or low-traffic site legitimately has none yet. Use the lab score to sanity-check the build in the meantime, and the field grade will populate as traffic arrives.
Core Web Vitals reward the thing a good small business site should do anyway: show up fast, respond instantly, and hold still while people read. You can get there on almost any platform with enough tuning, and if you're already invested in one, the fixes above are all real and worth doing. But the honest shortcut is to not inherit the problem, and start on a stack where sub-second loads and a near-100 Lighthouse score are what you get out of the box rather than what you chase for years.
See what passing looks like out of the box.
A Devani site builds with AI in ten to fifteen minutes and goes live in under a minute on the managed free tier, or one command on about a $5-a-month server. Run the result through PageSpeed Insights yourself before you commit to anything.