Short answer
Core Web Vitals are three metrics: Largest Contentful Paint (should be under 2.5s), Interaction to Next Paint (under 200ms) and Cumulative Layout Shift (under 0.1). On most business websites the biggest causes of failure are oversized images, too many third-party scripts, and render-blocking CSS and JavaScript — in that order.
The three metrics, in plain terms
Largest Contentful Paint measures how long until the main thing on the page appears. Under 2.5 seconds is good. This is the metric most business sites fail, and it is usually an image problem.
Interaction to Next Paint measures how quickly the page responds when someone taps or clicks. Under 200 milliseconds is good. Failures here are almost always too much JavaScript competing for the main thread.
Cumulative Layout Shift measures how much the page jumps around while loading. Under 0.1 is good. It is caused by images and embeds without reserved space, and by fonts swapping in late.
How much speed actually affects rankings
Less than most agencies imply, and more than most business owners assume. Core Web Vitals are a genuine ranking signal but a modest one — a fast page with weak content will not outrank a slow page that answers the question better.
Where speed matters far more is conversion. People abandon slow pages, and the effect is severe on mobile connections. The commercial argument for fixing speed is usually revenue rather than rankings, and it is the stronger argument of the two.
What actually makes business websites slow
Images, overwhelmingly. A photograph uploaded straight from a camera at 4,000 pixels wide and displayed at 800 is the single most common cause of a failing Largest Contentful Paint. Resizing and converting to a modern format frequently fixes the metric on its own.
Third-party scripts come second. Chat widgets, analytics, heat mapping, ad pixels, review widgets and font loaders each add requests and execution time. Sites routinely carry a dozen, several forgotten, all still loading.
Render-blocking CSS and JavaScript come third — files the browser must fetch and process before it can display anything. Page builders and heavy theme frameworks are the usual source.
Cheap shared hosting matters less than people think, but a slow server response over about 600 milliseconds puts a floor under every other metric no matter what you optimise.
What to fix first
Start with images: resize to the largest size actually displayed, convert to WebP or AVIF, lazy-load anything below the fold, and set width and height so the browser reserves space. This is usually the largest single gain available.
Then audit third-party scripts and remove what is not earning its place. Load what remains after the page is interactive rather than before.
Then reduce and defer CSS and JavaScript, and self-host fonts with an appropriate display setting so text is visible immediately rather than after a font download.
Then look at caching and server response time. Measure after each step rather than doing everything at once — otherwise you will not know which change helped, and some "optimisations" make things worse.
Measuring it honestly
Use field data, not just lab tests. Lighthouse and PageSpeed Insights run in a synthetic environment; the Chrome User Experience Report reflects what real visitors on real devices and connections actually experienced, and that is what counts for the ranking signal.
Test on mobile, and preferably on a mid-range phone on a normal connection rather than a flagship on office wifi. That is where most of your traffic actually is, and where slow sites lose money.
Key points
- LCP under 2.5s, INP under 200ms, CLS under 0.1.
- Speed is a modest ranking signal but a major conversion factor — argue it on revenue.
- Images cause most failures; third-party scripts and render-blocking assets come next.
- Fix images first, then audit scripts, then defer CSS/JS, then caching and server response.
- Judge on field data from real users on mobile, not lab scores.
Frequently asked
Do Core Web Vitals affect Google rankings?
Yes, as a genuine but modest signal. Content relevance outweighs speed. The stronger commercial case for fixing speed is conversion, not ranking.
What is a good page load time?
Largest Contentful Paint under 2.5 seconds on mobile for real users. Whole-page load time is a much less useful measure than when the main content appears.
Why is my WordPress site slow?
Usually oversized images, then an accumulation of plugins each loading their own assets, then a page builder generating heavy markup. In that order, on most sites we review.
Written by the Softech Team team. Last reviewed September 2026. This guide is general information, not advice for your specific circumstances.