Core Web Vitals get treated as a search-engine-optimisation checkbox, chased for the ranking signal and forgotten once the score turns green. That’s a mistake in both directions: the score is a proxy, not the point, and the underlying experience it measures — can a visitor see the page, can they interact with it, does it hold still — is directly tied to whether they stay, trust you, and convert. Understanding what each metric actually represents makes it obvious why fixing them pays off well beyond search rankings.
LCP is really “can a visitor see anything yet”
Largest Contentful Paint measures how long it takes the biggest visible element — usually a hero image or headline — to render. A slow LCP isn’t an abstract score; it’s a visitor staring at a blank or half-loaded screen, deciding whether to wait or leave. That decision happens in seconds, and it happens before they’ve read a word of your copy or seen a single reason to stay. It’s also one of the most directly architectural of the three metrics: a page whose main content is already in the HTML, served from a CDN close to the visitor, as in a static-first build, renders that content almost immediately, because there’s no server work or client-side data fetch standing between the click and the pixels.
INP is where lost conversions actually happen
Interaction to Next Paint measures how long the page takes to respond after someone taps a button, opens a menu, or fills a field. This is the metric most tied to frustration, because it’s felt directly and repeatedly — every laggy tap erodes a little more confidence that the site (and by extension the business behind it) is competent. INP is largely a JavaScript problem: the more script a browser has to parse and execute before it can respond to input, the worse it gets. Shipping less JavaScript by default, and hydrating only the components that genuinely need interactivity, is the most reliable lever here — it’s why an “islands” approach to interactivity consistently outperforms a page that ships a full application framework to render what is mostly static content.
CLS is a trust problem disguised as a technical one
Cumulative Layout Shift measures how much content jumps around as a page loads. A visitor starts reading, an image or ad loads above it, and the text they were reading jumps two lines down — or worse, they tap a button that shifted at the exact moment of the tap, and land somewhere they didn’t intend. Beyond the immediate annoyance, unstable layout reads as unpolished, and unpolished reads as untrustworthy, particularly at the moment someone is deciding whether to hand over payment details. Reserving space for images, ads and embedded content before they load — rather than letting the layout resolve itself as things arrive — removes the shift entirely.
Chasing the score without chasing the cause fixes nothing
A Lighthouse score can be nudged upward with narrow, cosmetic fixes that don’t touch the actual experience, and the improvement won’t last or won’t matter. The durable fix is architectural: less JavaScript shipped by default, content resolved ahead of time rather than assembled in the browser, layout reserved before content arrives. Treated that way, Core Web Vitals stop being a compliance exercise and become a genuine measure of whether your site respects a visitor’s time — which is also, not coincidentally, what tends to convert. If your current site’s numbers are somewhere between “amber” and “we’ve stopped looking,” that’s the starting point of most web development engagements we run.