TL;DR: A page loads fast enough when it passes all three Core Web Vitals at the 75th percentile of real visitors: LCP under 2.5s, INP under 200ms, CLS under 0.1. Google grades these from real Chrome field data over a 28-day window, not a lab test, and calibrates them around mid-range mobile, so mobile is almost always your weakest report. INP replaced FID in March 2024 and is the metric most sites now fail. Fix LCP with faster delivery and lighter images, INP with lighter JavaScript, and CLS with explicit dimensions.
What does "loads fast" actually mean?
It means passing Core Web Vitals: three metrics Google uses to measure real-world experience. Largest Contentful Paint (LCP) measures loading, with a good threshold under 2.5 seconds. Interaction to Next Paint (INP) measures responsiveness, good under 200 milliseconds. Cumulative Layout Shift (CLS) measures visual stability, good under 0.1. A page passes only when at least 75% of real visits hit the good threshold on all three.
This is check 12 of the AI SEO checklist and the first of the six technical pre-flight checks. A page that fails it loses visitors before your content ever loads, and a visitor who bounces is a citation the engine never gets to make.
Why is field data different from a lab score?
Because Google grades you on real users, not your test. The Core Web Vitals that count come from the Chrome User Experience Report (CrUX): actual visits from real devices, aggregated at the 75th percentile over a rolling 28-day window. A perfect Lighthouse score in your dev tools is a lab result on one machine and proves nothing about the field.
Google's Core Web Vitals report documentation confirms the mechanics: it assesses each metric at the 75th percentile and labels a URL group by its worst-performing metric, so poor CLS with good LCP still makes the page poor. Two consequences follow. Changes take about 28 days to show, because the window is rolling, so a fix deployed today will not move the report immediately. And the thresholds are calibrated around mid-range mobile, which is why the same page can feel instant on your laptop and still fail in the field.
How do you fix LCP?
LCP is usually an image and delivery problem. The largest element above the fold, typically the hero image or a large text block, has to render within 2.5 seconds, and four fixes move it most:
- Preload the LCP image with a high-fetch-priority preload hint so the browser fetches it early instead of discovering it late.
- Serve next-gen formats (WebP, AVIF) through a CDN, cutting both file weight and the geographic latency that inflates load time.
- Cut server response time (TTFB): faster hosting, caching, and fewer redirect hops before the page even starts rendering.
- Inline critical CSS and preload fonts so render is not blocked waiting for stylesheets or web fonts.
The single most common LCP mistake is lazy-loading the hero image. Deferring the largest above-the-fold image delays the exact element LCP measures, so lazy-loading belongs below the fold only.
How do you fix INP, the metric most sites fail?
INP is a JavaScript problem. It measures the latency of every interaction across the whole visit, not just the first, which is why it replaced First Input Delay in March 2024 and why it is now the most commonly failed Core Web Vital. When a tap or click has to wait for the main thread to finish a long task, INP climbs. The fixes are architectural: break long JavaScript tasks into smaller pieces, defer non-critical scripts, yield to the main thread during interactions, and reduce DOM complexity so the browser has less to process. Third-party scripts, chatbots, and heavy analytics are frequent culprits, since they run on the same main thread your buttons need.
How do you fix CLS?
CLS is a reserved-space problem. Layout shift happens when something loads and pushes content that was already there, and the fix is to reserve the space in advance. Give every image, video, iframe, and ad slot explicit width and height attributes so the browser holds the space before the asset arrives. Use font-display swap and matched fallback fonts so text does not reflow when the web font loads. And reserve space for anything injected late, like cookie banners or dynamic ads, rather than letting it shove the page down. Because CLS is a score, not a time, one late-loading ad unit can fail an otherwise stable page.
Which metric should you fix first?
| Priority | Metric | Root cause | Primary fix |
|---|---|---|---|
| 1 | Whatever is "poor" | Worst band drags the whole grade | Fix the red metric first |
| 2 | INP | Heavy main-thread JavaScript | Break tasks, defer scripts |
| 3 | LCP | Slow delivery, heavy hero image | Preload, next-gen, faster TTFB |
| 4 | CLS | Unreserved space | Explicit dimensions everywhere |
Do not optimize a metric that is already green. Fix whatever sits in the poor band first, then INP (hardest and most-failed), then LCP (highest commercial impact), then CLS (easiest).
How we apply this at HBS
We check Core Web Vitals on real mobile field data, not just a Lighthouse pass, before any page goes live, and we prioritize by the field-data band rather than chasing a perfect lab number. Speed is treated as a delivery-reliability standard for both search and conversion, which is why it is the first gate in our technical pre-flight. The Advanced SEO Solutions work we deliver includes diagnosing failing templates on field data and rebuilding the performance-critical paths so pages pass on real devices and stay passing.
Speed is the entry ticket
If your page fails Core Web Vitals on mobile, none of the structure, trust, or content work behind it gets a chance to matter, because the visitor is already gone. Pass the three metrics on real devices and keep them green through the 28-day window. If your site looks fast to you but Search Console says otherwise, our Advanced SEO Solutions team can diagnose the field-data failures, fix the LCP, INP, and CLS causes at the code level, and keep them green. Get a free audit and see where your real users are losing speed.
