Why Core Web Vitals Are Quietly Costing You Customers
Slow pages do not just annoy people — they lose you enquiries before anyone reads a word. What the three metrics actually measure, and the handful of fixes that move them.
Nobody emails to say your site was slow. They just leave, and you never find out. That is what makes performance the easiest problem to ignore and the most expensive to leave alone.
Core Web Vitals are Google's attempt to put numbers on that. Three of them, measured on real visitors rather than in a lab. Here is what each one actually means, in plain terms, and what usually causes it to fail.
LCP — how long until the page looks like something
Largest Contentful Paint measures how long it takes for the biggest thing above the fold to appear. Usually a hero image or a headline. Under 2.5 seconds is a pass.
Nearly every failure we audit comes down to the same thing: one enormous image. A 3 MB JPEG served at full resolution into a space 600 pixels wide, on a connection that is not your office fibre.
The fix is unglamorous and takes an afternoon:
- Serve modern formats — AVIF first, WebP as fallback
- Size the image for the space it actually occupies, and provide several widths
- Mark the hero as high priority so the browser fetches it first
- Lazy-load everything below the fold, and nothing above it
Second most common cause: a web font that blocks rendering. Preload it, and let text show in a fallback face while it arrives rather than leaving a blank space.
INP — how long until the page answers you
Interaction to Next Paint measures the lag between someone tapping something and the page visibly responding. Under 200 milliseconds is a pass.
This is a JavaScript problem, essentially always. Too much of it running on the main thread, so the browser is busy when the tap arrives. Common culprits: a heavy analytics or chat widget loaded eagerly, an animation library doing layout work on every frame, or a component re-rendering a long list on every keystroke.
The honest fix is to ship less JavaScript. After that: defer anything not needed for the first interaction, and keep animations to transform and opacity so they never trigger layout.
CLS — how much the page moves under you
Cumulative Layout Shift measures content jumping around as the page loads. You know it as reaching for a link and hitting an ad instead. Under 0.1 is a pass.
Three causes, in order of frequency:
- Images without dimensions. The browser does not know how much room to leave, so it leaves none, then shoves everything down when the image lands. Always set width and height, or an aspect ratio.
- Web fonts swapping. The fallback face has different metrics, so the text reflows when the real font arrives. Match the fallback metrics, or accept a short invisible-text window.
- Anything injected above existing content — cookie banners, promo bars, embeds. Reserve the space before it arrives.
Why this shows up in revenue
The relationship between speed and conversion is not subtle and it is not new. Every second of delay costs you a share of the people who were going to enquire. On mobile, on a mid-range Android over a patchy connection — which describes a large part of the audience in Pakistan and the Gulf — the effect is far stronger than it looks from a desktop in an office.
There is a second cost that is easier to miss. A slow site tells a visitor something about how you work. If you are selling engineering, and your own site takes six seconds to show a headline, you have made an argument against yourself before they have read a word of it.
How to find out where you stand
Two places, five minutes:
- Search Console → Core Web Vitals. This is field data from real visitors. It is the number that counts.
- PageSpeed Insights. Run your three most important pages. Ignore the score; read the specific opportunities it lists.
If the field data is thin because traffic is low, use the lab data as a rough guide and re-check once you have visitors.
Making it stick
Fixing performance once is a week of work. Keeping it fixed is a process decision.
Set explicit targets — LCP under 1.8 seconds, INP under 200 milliseconds, CLS under 0.05, and a hard ceiling on JavaScript per route. Then enforce them in CI, so a pull request that blows the budget fails before it merges.
That last part is what actually matters. Without it, every site gets slower month by month, because no individual change ever feels like the problem. We hold our own builds to those numbers, which is the only reason it is worth telling you to.
If you want to know which of the three your site is failing and why, send us the URL — we will tell you what is actually wrong with it.