Someone sends you a screenshot with a green 95 on it and the word "Performance" above it. The site feels slow anyway. Your phone takes a beat too long on the service page. A customer mentions it.
Both things are true, and the reason is the single most useful thing to understand here.
The score in the screenshot is a lab test. The score Google actually uses is a recording of your real customers.
What is the difference between lab data and field data?
A Lighthouse run is a simulation. One page, one machine, one throttled connection, one moment. It is a diagnostic — genuinely useful for finding what is wrong, because it runs the same way every time.
Field data is different. Chrome collects real load experiences from real people on real devices and real networks — the customer on four-year-old Android in a basement with one bar, the one on hotel wifi, the one on a new iPhone. That collection is what feeds Google's assessment of your site.
So you can hold a 95 and still fail, because the lab ran on hardware nobody in your service area is holding.
The nuance that catches most people: Google grades at the 75th percentile. Not the average. Three out of four visits have to be good. Averages hide the slow quarter — and the slow quarter is disproportionately people on phones, which for a home services business is most of the people worth having.
What do LCP, INP, and CLS actually measure?
Three metrics. Each one corresponds to something a customer physically feels.
- LCP — Largest Contentful Paint. How long until the main thing appears. Not the spinner, not the header — the hero image or headline that tells someone they are in the right place. Google's threshold is 2.5 seconds or less. This is the "is this site even loading" metric.
- INP — Interaction to Next Paint. You tap something and the page does not respond yet. Threshold is 200 milliseconds or less. This replaced First Input Delay in 2024, and the change matters: FID only measured the first tap, while INP watches the whole visit. Booking flows and mobile menus have nowhere to hide now.
- CLS — Cumulative Layout Shift. The page jumps while you are reading it, because an image or ad loaded late and shoved everything down. Threshold is 0.1 or less. This is the one that makes someone tap the wrong button and leave.
Those thresholds are Google's, not mine — the current definitions live in Google's Core Web Vitals documentation, and the real-user dataset behind the grade is the Chrome UX Report. Check them yourself rather than taking any vendor's word for the numbers, including this one.
Read them in customer language rather than engineering language: did it show up, did it respond, did it hold still.
What causes each one to fail — and what fixes it
Each metric has a small number of usual suspects. This is the diagnostic sequence, not a checklist to hand your provider and hope.
LCP is usually the server or the hero image. Either the page took too long to start arriving, or the biggest image on screen is a 4MB photograph being resized by the browser. The fixes are unglamorous: get real HTML to the browser fast, serve modern image formats at the size they will actually display, and stop making the most important image wait behind fonts and scripts.
INP is almost always JavaScript. Every chat widget, tracking pixel, review carousel, popup manager, and heat-mapping tool competes for the same main thread the tap needs. Most contractor sites carry a decade of accumulated third-party tags nobody has audited. The fix is subtraction — and it is usually the single highest-leverage hour anyone spends on the site.
CLS is almost always missing dimensions. Images and embeds without reserved space, fonts that swap and reflow the text, banners injected above content after paint. These are cheap to fix and they are pure customer-experience wins, because nobody has ever enjoyed a page that moves.
What should you fix first?
Ordered by leverage, not by what is easiest to put in a report:
- Measure the field, not the lab. Pull your real-user numbers before you change anything. If you optimize against a lab score you will fix the wrong things well.
- Audit third-party scripts. List every tag on the site and make someone justify each one against revenue. This usually fixes INP by itself.
- Fix the hero path. Server response and the largest image, in that order.
- Reserve space for anything that loads late. Cheapest of the three, and it removes the most irritating symptom.
- Re-measure the field in 28 days. Field data is a rolling window; it does not update the moment you deploy. Patience here is not optional.
Notice what is not on the list: chasing 100. A green 95 that fails at the 75th percentile is worth less than an 88 where real customers are having a good time.
Why most speed reports never fix anything
Because a lab score is easy to produce monthly and hard to be accountable for. It is a screenshot. It goes in a deck. Nobody asks whether the customer on the basement Android had a better week.
There is also an uncomfortable structural reason. Speed is largely decided by architecture — what the platform ships to the browser before anyone tunes anything. A provider whose platform is slow by construction cannot fix your vitals with a plugin, so the report becomes the deliverable instead of the outcome. I have written about that pattern more directly in why the agency model is breaking.
What this looked like on our own house
We did not learn this from a conference. We rebuilt our own platform because the ceiling was architectural, and we published the numbers rather than describing them.
Load time went from roughly eight seconds on our old WordPress build to under 100 milliseconds on Hydra — because Hydra ships HTML that is already built rather than assembling a page on request. Measured over equal 46-day windows, sessions moved 247 → 460 → 844 across the three platform eras, and tracked leads went 88 → 93 → 203.
The honest read on those numbers: platform was not the only variable, and I would not claim otherwise. But the direction held across every measure we track, and the mechanism is not mysterious — pages that appear immediately get more of the visit. The full accounting, including what Webflow did and did not solve, is in WordPress to Webflow to Hydra.
What to ask your provider this week
Five questions. The answers are more informative than any report.
- What are our field Core Web Vitals — LCP, INP, CLS — at the 75th percentile on mobile?
- Which URLs are failing, not which score is average?
- Every third-party script on the site, and the business reason for each?
- Which of these is fixable on our current platform, and which is architectural?
- What will these numbers be in 28 days, and what are you changing to get there?
That last one is the tell. Anyone can describe a problem. The question is whether they will put a number and a date on the fix.
Where this is heading
Speed used to be a human courtesy. It is becoming a machine requirement, because AI systems crawling and summarizing your site are subject to the same physics your customers are — and they are less patient. A page that takes eight seconds to assemble is a page that may simply not get read by the thing deciding whether to recommend you.
That is the part most operators have not priced in yet. The speed conversation stopped being about bounce rate. It is now about whether you are legible to the systems your next customer is asking. More on that in what makes a website AI-ready and why fast websites win.
Pull your field numbers. Look at the 75th percentile on mobile. That is the score that counts.