Latest · Observed · Published 11 Sep 2026 · GA Applications editorial
The enquiry you never saw was lost to a loading bar.
A slow website loses enquiries before your analytics notice anything. The visitor hesitates, the page stutters, the button ignores a tap, and they leave — recorded as a bounce at best, invisible at worst. Google’s Core Web Vitals thresholds define “good”: content within 2.5 seconds, response within 200 milliseconds, layout shift under 0.1, at the 75th percentile of real visits.
Thresholds from web.dev, 7 May 2025. The confidence-damage mechanism is GA inference, labelled where claimed.
Mechanism
The hesitation before the bounce
Analytics records arrivals and conversions. It does not record hesitation. A visitor whose first tap is ignored does not file a complaint; they go back and tap your competitor. This is why “traffic looks fine but enquiries are down” so often traces to performance rather than marketing.
The mechanism is trust. Delay reads as indifference. A layout that jumps as you tap reads as carelessness. A button that does nothing reads as a broken business. These judgements form in seconds, on a phone, often on rural data — and they form before any event your analytics can see. That reading of the mechanism is GA’s inference and is labelled as such below; the thresholds themselves are published and measured.
Most NZ business customers meet a website on a mid-range phone, on cellular data, with one thumb. If the site only feels fast on the owner’s laptop on office Wi-Fi, it is slow where it matters.
Core Web Vitals
The thresholds that define “good”
Google’s published bar for page experience, judged on real visits rather than your best-case test.
- ≤ 2.5 sLargest Contentful PaintMain content visible
- ≤ 200 msInteraction to Next PaintPage responds to a tap
- ≤ 0.1Cumulative Layout ShiftPage stops jumping under your finger
- 75thPercentile of real visitsJudged on typical users, not your fastest
Thresholds defined by the Chrome team and published on web.dev, 7 May 2025; assessed at the 75th percentile of page visits, split by mobile and desktop.
The mobile performance replay
Replay one real visit
You do not need new tools to feel what your customers feel. You need a phone and ten honest minutes. Monthly.
Borrow a mid-range phone
Not the newest handset in the building. Your customers carry two- to four-year-old phones on ordinary data plans.
Get off the office Wi-Fi
Use cellular data, ideally somewhere with ordinary coverage. A car park counts.
Search for your own service
Start from Google the way a customer does. Tap your result and count seconds out loud until the page is usable — not loaded, usable.
Try to enquire
Tap the phone number. Fill the form with one thumb. Watch for jumping content, ignored taps and keyboard fights.
Record and repeat monthly
Screen-record the pass: same route, same questions, every month. Performance degrades by drift; a replay habit catches the drift.
The field/lab distinction
Lab scores versus field truth
Both matter. Confusing them is how sites pass tests and lose customers.
| Question | Lab test (simulated) | Field data (real visits) |
|---|---|---|
| What it measures | One simulated visit on one emulated device and network | The 75th percentile of actual visitors over a rolling window |
| What it is good for | Diagnosing causes: heavy images, blocking scripts, oversized fonts | Judging experience: what customers actually endure |
| What it misses | Your customers’ phones, coverage, impatience and thumbs | The cause — field data shows symptoms, not reasons |
| Where to find it | PageSpeed Insights “diagnose performance issues” section | PageSpeed Insights “real user experience” section; Search Console’s Core Web Vitals report |
Lab data to fix, field data to prove. Google’s thresholds are assessed on the field data.
Speed is a trust signal, not a race
The goal is not a perfect score; it is a page that never makes a customer wait, wonder or re-tap. Past the thresholds, further optimisation buys diminishing returns — spend the rest of the budget on evidence and clarity. Speed is one stage of a larger sequence; the trust-sequence audit covers the other five.
Evidence honesty
Sources, method and what would change this
- Verified fact
Core Web Vitals thresholds
Good thresholds are LCP ≤ 2.5s, INP ≤ 200ms and CLS ≤ 0.1, assessed at the 75th percentile of page visits and segmented by device.
web.dev, “How the Core Web Vitals metrics thresholds were defined”, 7 May 2025
- Verified fact
Threshold basis
The thresholds were derived from human-perception research and from what well-built origins could realistically achieve, per the web.dev account of the methodology.
web.dev, 7 May 2025
- Inference
Confidence damage before analytics
The claim that delay and instability erode trust before measurable intent is GA’s practitioner inference from field observation and replay work, not a controlled study.
GA Applications editorial
- Proposal
The replay method
The monthly replay is GA’s recommended low-cost habit for owners. It complements measured field data; it never replaces it.
GA Applications method
- Proposal
What would change this conclusion
If Google revised the thresholds, or if measured enquiry behaviour in GA’s client work stopped tracking sub-threshold performance, this piece would be revised and re-dated.
GA Applications editorial
Get your real experience measured
GA measures your site the way your customers meet it — mid-range phone, cellular data, one thumb — and returns the fix list in order of enquiry impact.
Lab and field, both reported, both explained. No perfect-score theatre.