Why your site feels slow — and what actually fixes it

What the three metrics actually measure

Core Web Vitals are three field measurements, not a grade. Largest Contentful Paint (LCP) times how long the biggest visible element takes to render — usually a hero image or headline. Interaction to Next Paint (INP) measures how long the page takes to respond visually after a tap or click. Cumulative Layout Shift (CLS) counts how much the content jumps while loading. Google publishes a threshold for each.

The detail most reports skip: the thresholds are evaluated at the 75th percentile of real visits, not the average. A page can feel instant on your laptop and still fail, because a quarter of your visitors are on a mid-range phone, a weak connection, or a browser loading three marketing tags before your content appears.

• ●LCP — good at 2.5 seconds or less; usually the hero image, heading block or video poster
• ●INP — good at 200 milliseconds or less; replaced FID as the responsiveness metric
• ●CLS — good at 0.1 or less; caused by images without dimensions, late-loading fonts and injected banners
• ●The 75th percentile rule: three out of four visits must clear the threshold, not the median one

Lab scores and real users disagree — trust the field data

A PageSpeed or Lighthouse run is a simulated device on a throttled connection, executed once, in a clean browser. Field data comes from actual Chrome visits over a rolling window. That is why a page can score in the nineties in the lab and still fail in the field: real sessions carry consent-gated tags, chat widgets, ad pixels and cached-versus-cold states that a single lab run never sees.

Use the lab run for diagnosis and the field data for judgement. In Search Console, the Core Web Vitals report groups URLs by template — product pages, blog posts, the homepage. That grouping is the useful part, because a template fix propagates to every page built from it. Fixing one URL at a time is how speed projects stall.

The fixes that actually move the numbers

Work in order of impact rather than in order of what a tool flagged. Server response time comes first: if the HTML takes a second to arrive, nothing downstream can rescue LCP. Then render-blocking resources, then images, then third-party scripts. Most sites we look at lose more time to scripts nobody remembers adding than to anything the developer wrote.

• ●Cut time to first byte with caching, a sane hosting setup and a CDN in front of static assets
• ●Serve images in modern formats, sized for the viewport, with explicit width and height so nothing shifts
• ●Self-host fonts, preload only the one used above the fold, and set font-display so text is never invisible
• ●Audit third-party tags: chat widgets, heatmaps, A/B tools and pixels are the usual INP offenders
• ●Reserve space for cookie banners, promo bars and embedded video so late elements do not push content down
• ●Stop shipping JavaScript for things that are not interactive — a marketing page rarely needs a framework runtime

When speed is not your problem

Honest version: if a page gets a handful of visits a month, taking it from 3.4 seconds to 1.8 will not change your business. Speed compounds with volume. When traffic is thin, the lever is usually the offer, the clarity of the page, or the fact that nobody is finding it — and a performance project just postpones that conversation.

We say this to clients before quoting work. If your analytics show real traffic that leaves before the page renders, or a checkout that stalls on mobile, performance work pays for itself. If the page is fast and empty, we would rather look at what it says and who it reaches.

Frequently asked questions