Site Speed and SEO: What Core Web Vitals Mean in Practice

When I crawl a site and report "slow pages", this is the finding people give up on. A title tag takes a minute to shorten. An alt text takes two. But "this page loads in 5.8 seconds" sounds like something that needs a developer and three weeks. Sometimes it does. Often it doesn't.

This article covers what Core Web Vitals actually measure, which numbers separate a good result from a poor one, and which causes of slowness you can fix without touching code.

How speed feeds into SEO

Google uses Core Web Vitals as part of its page experience signals. What matters is knowing how much weight that carries:

• Speed is not a primary ranking factor. Content that answers the question beats a faster page with weaker content.
• Speed decides when two pages are comparable on content. For competitive queries, that is the normal situation, not the exception.
• The indirect effect is bigger than the direct one. A slow page means more people leaving before it renders. On mobile data, that is not a thought experiment.

What speed will not do: move you from page three to page one. If someone tells you that a speed pass will lift you twenty positions, ignore it. Expect more room to compete and fewer abandoned loads.

The three metrics and their exact thresholds

Core Web Vitals are three numbers. Each has three bands: good, needs improvement, poor.

LCP — Largest Contentful Paint

The time until the largest content element in the visible part of the page is rendered. Usually the main image, a banner, or a large block of text.

| Value | Verdict | |---|---| | under 2.5 s | good | | 2.5 – 4.0 s | needs improvement | | over 4.0 s | poor |

LCP is the metric images ruin. A 3,200 × 2,100 px photo displayed at 800 px wide still has to download in full. On an online store with a large product photo, that is the most common reason LCP goes past 4 seconds.

INP — Interaction to Next Paint

The time from a click or tap to the moment the browser paints the response. INP replaced the older FID metric in March 2024. The difference matters: FID measured only the delay of the first interaction, while INP looks at the whole visit and takes the worst interactions into account.

| Value | Verdict | |---|---| | under 200 ms | good | | 200 – 500 ms | needs improvement | | over 500 ms | poor |

INP is ruined by JavaScript. A chat widget, three analytics scripts, a carousel, a cookie bar, a retargeting pixel — each one blocks the main thread. On a cheap Android phone that isn't 30 ms, it's 600.

CLS — Cumulative Layout Shift

A unitless number describing how much the content jumps around while loading. You go to click a link, a banner loads above it, the content shifts, and you click something else.

| Value | Verdict | |---|---| | under 0.1 | good | | 0.1 – 0.25 | needs improvement | | over 0.25 | poor |

CLS has the cheapest fixes. In the large majority of cases it comes down to images and iframes with no dimensions declared, or to ads and bars injected into the page flow.

Why your test result differs from Search Console

This confuses a lot of people. There are two kinds of data.

Lab data comes from a tool loading the page in a simulated environment, for example PageSpeed Insights in analysis mode. You get an instant result and a list of causes. But the number is a model: one device, one connection speed.

Field data is collected by Chrome from real visitors. The value used for assessment is the 75th percentile over the last 28 days. Not an average — the value three quarters of visits achieve or beat. Those are the numbers you see in the Core Web Vitals report in Search Console.

Two practical consequences. First: after you deploy a fix, Search Console will not change straight away. It takes roughly a month for the 28-day window to fill with new visits. Second: if a page gets few visits, field data may not exist for it at all, and it gets assessed through a group of similar URLs or the whole site.

What slows sites down most often

The same causes keep coming back. In order of how often I find them:

1. Images that were never resized. The original straight out of a camera or a stock library. Fix: resize to the maximum displayed width and save as WebP. On a product photo you can typically go from 2 MB to 150 kB with no visible difference.

2. Images with no width and height attributes. The browser doesn't know how much space to reserve, so the content shifts once the image arrives. Direct hit to CLS.

3. Lazy loading applied to the hero image too. Deferred loading is good for images further down the page. Put it on the hero image and LCP gets worse, because the browser starts the download late.

4. Too many third-party scripts. Every pixel, chat and A/B tool has a cost. Check which ones are left over from campaigns that ended long ago.

5. Slow server response. If TTFB (time to first byte) alone takes 1.5 seconds, no amount of image work saves it. The usual causes are shared hosting, no caching, or heavy database queries.

6. Fonts. A custom font without font-display: swap means the text is invisible for a moment. Loading four weights when you use two is dead weight.

7. The theme and surplus plugins. In WordPress it is normal for a theme to carry features you never use, and for every plugin to add its own CSS and JS to every page.

The order to work in

Speed work can go on forever, so here is the order by effort against result:

1. Measure where you stand. Get LCP, INP and CLS for the page types that matter: homepage, category, product detail, article. Not one number for the whole site.
2. Deal with images. Resize, WebP, correct dimensions in the HTML, lazy loading only below the fold. This is the biggest move for the least work.
3. Go through third-party scripts. Remove what you don't use. Defer the rest where the tool allows it.
4. Check TTFB and caching. Page caching changes the numbers noticeably. If TTFB is still high, the problem is the hosting.
5. Only then touch theme CSS and JavaScript. At this point you usually need someone who reads code.

One thing said plainly: steps 1 to 3 you can handle yourself. Step 5 you can't, unless you write code. There is no point claiming otherwise.

What I do here and what I don't

When I crawl a site, I flag the pages that load slowly and state what is slowing them down — which images are disproportionately large, where dimensions are missing. You get the finding with a specific URL, not a general suggestion to "speed up the site".

What I won't do: change your hosting, rewrite your theme, or touch your JavaScript. I write ready-to-paste fix text for findings that can be expressed as text — titles, meta descriptions, alt texts, structured data. Speed is a different category. There I hand you a precise brief: what to fix, on which page.

Once the fix is live, I can check the effect: 28 days before against 28 days after. Not by the feeling that "it runs better now", but by what happened to search traffic.

What to take away

The thresholds worth memorising: LCP under 2.5 s, INP under 200 ms, CLS under 0.1. Assessment uses the 75th percentile of real visits over 28 days, so expect to see the result of a fix about a month later.

Speed is not a substitute for content. It is an obstacle that can cost you visits even when your content is better than the competition's. And most of that obstacle sits in images and scripts nobody wanted — nobody just got round to removing them.

#seoobsah