When we rebuilt a fashion retailer's storefront last year, the headline result was not the redesign. It was that Largest Contentful Paint went from 5.2 seconds to 0.9, and mobile conversion rose 34%. The product catalogue was identical. The prices were identical. The only thing that changed was how quickly people could see and use the thing they came for.
Performance is not a matter of engineering pride. It is a conversion lever, and it is measurable.
The three numbers that matter
Google's Core Web Vitals are worth understanding precisely, because each one maps to a distinct user frustration.
Largest Contentful Paint (LCP) — how long until the main content is visible. Target under 2.5 seconds. This is the "is anything happening" metric, and it is the one most correlated with bounce rate.
Interaction to Next Paint (INP) — how quickly the page responds when someone taps or clicks. Target under 200 milliseconds. This replaced First Input Delay in 2024 and it is considerably harder to pass, because it measures every interaction across the session rather than just the first.
Cumulative Layout Shift (CLS) — how much the page jumps around while loading. Target under 0.1. This is the metric behind every mis-tap on a mobile banner that loaded late.
These are measured at the 75th percentile of real users, not in a lab on your development machine. That distinction matters enormously — your site is fast on a wired connection in the office and frequently is not on a mid-range Android phone on mobile data, which is what a large share of your actual traffic is using.
Where the time usually goes
In our experience, four causes account for the overwhelming majority of poor scores.
Images. Unoptimised hero images are the single most common LCP killer. Serving a 2MB PNG where a 90KB AVIF would do adds seconds on mobile. Modern formats, correct dimensions, explicit width and height attributes to prevent layout shift, and lazy loading for anything below the fold.
JavaScript that blocks. Every kilobyte of JavaScript must be downloaded, parsed and executed before the page becomes interactive. Ship less of it. Code-split by route, defer anything non-critical, and be ruthless about third-party scripts — a single analytics or chat widget can add hundreds of milliseconds to INP.
Fonts. A custom web font that blocks rendering delays LCP directly. Preload the critical font, use font-display: swap, and subset to the characters you actually use.
Server response time. If your server takes 800ms to send the first byte, no amount of front-end optimisation will get you under 2.5 seconds. Cache at the edge, render on the server where it helps, and profile the slow database query that is almost certainly behind it.
Make it a gate, not a review
The reason most performance work does not stick is that it is done as a one-off project. Someone spends a sprint optimising, the scores improve, and then six months of feature work quietly undoes all of it.
The fix is to enforce it in continuous integration. Set a performance budget — a maximum bundle size and minimum Lighthouse score — and fail the build when a pull request breaks it. It turns performance from something a team intends to care about into something the pipeline simply will not let them regress.
Pair that with real-user monitoring in production. Lab scores tell you about a synthetic environment; field data tells you what your actual users on actual devices are experiencing, and the two diverge more than most teams expect.
The compounding argument
Fast pages rank better, because Core Web Vitals are a confirmed ranking signal. Better ranking brings more traffic. Fast pages convert more of that traffic. Faster pages also cost less to serve, because you are shipping fewer bytes to more people.
There are not many engineering investments where the SEO, conversion and infrastructure arguments all point in the same direction. This is one of them.
Want to know where your site actually stands with real users? Request a performance audit — we will send you the field data and a prioritised fix list.