Google's Core Web Vitals became a ranking signal in 2021. Since then, every agency has added "CWV optimised" to their pitch decks. Almost none of them explain what the metrics actually measure or what specifically causes them to fail.
Here's the non-jargon version.
What it measures: How long it takes for the largest visible element on the page to appear.
That element is usually your hero image, hero video, or a large text block. The moment that element is fully visible, the LCP clock stops.
Why it matters: LCP is the moment users decide whether the page is loading. Before LCP, they're looking at a partially rendered page. After LCP, the page feels usable.
The target: Under 2.5 seconds. Under 1.5 seconds is excellent. Above 4 seconds is where bounce rates measurably increase.
What causes it to fail: Large, unoptimised images. Hero videos that load before playing. Server response time (slow hosting). Render-blocking JavaScript that delays everything.
What it measures: How quickly the page responds when you click, tap, or type something.
INP replaced FID (First Input Delay) in 2024. It measures the worst interaction delay across the full page visit, not just the first one.
Why it matters: A page that looks fast but responds slowly to clicks feels broken. INP captures this friction.
The target: Under 200 milliseconds. Under 100ms is excellent. Above 500ms feels sluggish even on fast hardware.
What causes it to fail: Heavy JavaScript running on the main thread. Third-party scripts (chat widgets, analytics, A/B testing tools) that block interaction. Poorly optimised event handlers.
What it measures: How much the page moves around while it's loading.
If you've ever tried to click a button and it moved just as you clicked — because a banner or image loaded above it — you've experienced CLS. It's measured as a score (lower is better).
Why it matters: Layout shifts cause misclicks and signal to users that the page is poorly built. Google measures it because it correlates with bad user experience.
The target: Under 0.1. Under 0.05 is excellent. Above 0.25 is a problem.
What causes it to fail: Images without explicit width and height attributes. Fonts that load after text is painted and cause text to reflow. Dynamically injected content above existing content (banners, cookie notices).
Search ranking: CWV is a tiebreaker, not a primary ranking factor. Two pages with identical content will rank differently based on CWV. A page with poor CWV and excellent content will outrank a page with perfect CWV and thin content. But at parity on content quality, CWV matters.
Bounce rate: A 1-second LCP improvement correlates with a 10–20% reduction in bounce rate, according to Google's published data. Users who see your page load fast are more likely to stay.
Conversion rate: For every second of load delay above 2 seconds, conversion rates drop measurably. This is especially significant on mobile, where connections are slower.
Perceived quality: A fast site signals competence. A slow site from an agency that sells web products is an immediate credibility problem.
PageSpeed Insights (pagespeed.web.dev): paste your URL, run the test. Shows field data (real users, if you have enough traffic) and lab data (simulated). Lab data is what you optimise to; field data is what Google sees.
Chrome DevTools: Lighthouse tab, mobile device, throttled network. Simulates a mid-range phone on a 4G connection — the most representative scenario for your actual user distribution.
Search Console: If your site has enough traffic, Google shows your CWV status in the Core Web Vitals report. This is field data and is what Google actually uses for ranking.
The hero image is almost always the LCP element. The fix:
width and height attributes to prevent CLSfetchpriority="high" to the hero image — this tells the browser to prioritise it<head>: <link rel="preload" as="image" href="/hero.webp">This alone typically moves LCP from 2.5–4s to 1.2–2s on most marketing sites.
Analytics, chat widgets, A/B testing tools, and social embeds are often the #1 INP and LCP killer. They load synchronously, blocking everything else.
Load them with defer or async. Better: load non-critical scripts after the page is interactive (on load event or after a user interaction). For most marketing sites, analytics loading 2 seconds after the page is fine. Chat loading after first scroll is fine.
Every image without width and height causes CLS. This includes images in CMSs, blog posts, and carousels.
Add dimensions. If you can't (dynamic content), use a container with a known aspect ratio using CSS (aspect-ratio: 16/9). The browser reserves the space before the image loads.
font-display: swap for custom fontsCustom fonts are loaded asynchronously. Without font-display: swap, browsers wait for the font before rendering text — causing LCP delay. With swap, the browser renders with a fallback font immediately, then swaps when the custom font loads.
This can cause minor text reflow (a small CLS penalty), but the trade-off is almost always worth it. The alternative (invisible text until fonts load) is worse.
If your Time to First Byte is above 600ms, everything else is harder to fix. TTFB is determined by your hosting, your server-side rendering time, and your CDN configuration.
Cheap hosting with a single server in one geography = slow TTFB for users in other countries. A CDN (Cloudflare, Vercel, Fastly) distributes your content globally and reduces TTFB for most users to under 200ms.
For static marketing sites, use a CDN. It's not optional if you care about performance outside your host's data center.
| Site type | LCP | INP | CLS | Lighthouse |
|---|---|---|---|---|
| Excellent marketing site | < 1.2s | < 80ms | < 0.02 | 95–100 |
| Good marketing site | 1.2–2.0s | 80–150ms | 0.02–0.06 | 85–95 |
| Acceptable | 2.0–2.5s | 150–200ms | 0.06–0.1 | 70–85 |
| Needs improvement | > 2.5s | > 200ms | > 0.1 | < 70 |
Most Webflow sites land in "acceptable" by default. Most carefully built Next.js and Astro sites can reach "excellent" with deliberate optimisation.
Want to know how your site scores and what to fix first? Start a conversation — we'll run a full CWV audit and prioritise the changes by impact.
We take on a small number of projects each quarter. Tell us what you're building.
Caching gotchas, server vs client component decisions, Vercel vs self-hosted tradeoffs, and when the Pages Router is still the right call. Real lessons from production App Router deployments.
React Native and Flutter are both mature. The choice isn't about which is better — it's about your team, your timeline, and what you're building. Here's how to decide.