Site Speed & Core Web Vitals, Explained Simply
What Google's Core Web Vitals actually measure, why slow sites lose customers before they lose rankings, and the handful of causes behind almost every slow Phoenix business site.
What Google's Core Web Vitals actually measure, why slow sites lose customers before they lose rankings, and the handful of causes behind almost every slow Phoenix business site.
Your website's speed has a property that makes it dangerous: you can't feel it. On your office Wi-Fi, on a computer that's loaded the site a thousand times from cache, everything seems fine. Your customer — on a phone, on cellular, visiting cold — is having a completely different experience, and they're not filing a complaint about it. They're just leaving.
This piece explains the measurements Google uses for speed, in plain English, and the short list of causes behind nearly every slow site we audit in our web design practice.
Core Web Vitals are Google's attempt to turn "does this page feel good to use?" into three numbers, collected from real visitors' browsers:
Largest Contentful Paint (LCP) — "how fast does the page actually show up?" The time until the biggest visible element (usually your hero image or headline) is on screen. Target: under 2.5 seconds. This is the number your bounce rate feels.
Interaction to Next Paint (INP) — "does it respond when I tap?" How quickly the page reacts to a tap or click. Target: under 200 milliseconds. Pages heavy with scripts fail this one — the page looks loaded but ignores the visitor's tap while JavaScript churns.
Cumulative Layout Shift (CLS) — "does the page jump around?" How much content moves after it appears — the experience of aiming for a button that relocates as an ad or image loads in above it. Target: under 0.1.
You can check any site free at Google's PageSpeed Insights. Two readings matter: the field data up top (measured from real Chrome users — this is what Google actually uses) and the lab score below (a diagnostic simulation). And check mobile first — it's both how your customers arrive and how Google indexes you.
The commercial logic runs in that order deliberately. Long before rankings move, slow pages bleed the visitors you already won: every additional second of load time peels off a measurable share of them, and the drop is steepest on mobile, where patience is thinnest and connections worst. A site that converts poorly at speed X converts worse at 2X, with no other change.
The rankings effect is real but secondary — Core Web Vitals are one factor among many, a tiebreaker between comparably relevant results rather than a dominant lever. The practical summary: speed won't outrank better content, but it quietly taxes both your traffic and your conversion the entire time it's bad. For a local business, that tax lands precisely on the customers who matter most: nearby people, on phones, ready to act. It's the third of the five mistakes we find on almost every underperforming site, and it compounds the other four.
Audit enough Valley small-business sites and the same suspects appear in the same order:
Notice what's on that list: build decisions and habits, not exotic engineering. That's the encouraging part — most slow sites don't need a rebuild; they need discipline applied to fixable causes, and speed work is priced accordingly (our rates are published, starting at the $2,500 minimum engagement).
Keeping a site fast is the other half — speed decays as content, plugins, and scripts accumulate, which is why performance checks are part of our care plans rather than a one-time event.
For calibration, the shape of the work when we're hired for speed specifically: an audit first (field data, lab diagnostics, and a cause inventory ranked by impact — you get this in plain English with numbers attached); then the fix pass in impact order — images and formats, script pruning, hosting and caching configuration, layout-shift repairs; then a re-measure against the same thresholds so the improvement is documented rather than asserted. Engagements start at our $2,500 minimum and stay well below redesign cost unless the audit finds structural problems — in which case you'll get that verdict with both paths priced, and the decision stays yours.
Focus on passing the three Core Web Vitals in field data rather than chasing a 100 lab score — the last twenty lab points often cost more than they return. Passing thresholds with real users is the goal that pays.
Images, statistically: resizing, compressing, and converting to modern formats routinely recovers more load time than every other intervention combined, and it's low-risk enough to do first while the fuller audit runs. If your site has photos uploaded straight from phones or cameras, start there — you'll likely see the difference the same day.
Unknowable from your chair — your cache and Wi-Fi are lying to you. Test on PageSpeed Insights and on a phone over cellular; those are your customers' conditions.
Usually, yes — images, scripts, hosting, and caching are all fixable in place on a sound structure. When the theme or builder is the problem, we'll say so plainly and price both paths.
More, if anything — the conversion tax on visitors you already have is the bigger cost, and it applies to every visitor regardless of how they found you.
At passing field-data thresholds on mobile with your real audience. Beyond that, optimization hits diminishing returns quickly, and the budget does more good on the other four mistakes. Speed is a threshold game, not a leaderboard.
Marginally — a US-based host or CDN edge serves the Valley fine, and a CDN (standard on our builds) makes the question mostly moot. Server quality matters far more than server geography at local-business scale.
Want to know your real numbers? Send your URL — we'll run the audit, translate the results into plain English, and quote exactly what fixing them costs. Get a speed audit, or start with the full Phoenix web design guide.