Core Web Vitals: 5 Real Reasons Your Site Is Slow

When a site is slow, hosting gets blamed first. Sometimes that's fair, but on most of the sites I've looked at, upgrading the server changed nothing — because the problem wasn't how fast the server responded, it was how the browser painted that response to the screen.

First, a one-line definition for each of the three metrics:

• LCP — when did the largest visible element on the page appear? Target: under 2.5 seconds.
• CLS — how much did the page jump around while loading? Target: under 0.1.
• INP — how quickly did the page respond after a user clicked? Target: under 200 ms.

1. An unoptimized hero image

This is the number one cause of a broken LCP, and it's easy to spot: the large image at the top of the page is often a 2-4 MB JPEG, 4000 pixels wide, getting squeezed down to 380 pixels on a phone.

Fix, in order:

1. Resize the image to the size it's actually displayed at. You rarely need a hero image wider than 1600 pixels.
2. Switch to WebP or AVIF — 30-60% smaller at the same visual quality.
3. Serve a smaller version to phones and a larger one to desktop with srcset.
4. Give the hero image fetchpriority="high", and don't lazy-load it. Delaying the first thing visible on screen has exactly the opposite effect you want.

2. Render-blocking web fonts

Three separate font families pulled from Google Fonts, six weights each. Until the browser downloads those files, it either hides the text or swaps it in later — the first breaks LCP, the second breaks CLS.

Fix: cut the number of font families down to two, load only the weights you actually use, self-host the files, and always set font-display: swap. On this site I use a system font stack — zero downloads, zero jumping.

3. Images and embeds with no reserved dimensions

The classic cause of CLS. If you don't set width and height on an <img> tag, the browser has no idea how much space the image will take; when it arrives, it shoves everything below it downward. The reader loses their exact spot on the page.

The same problem hits YouTube embeds, map iframes, and ad slots. Give all of them a fixed height or an aspect-ratio — the space should already be reserved before the content arrives.

4. A pile of third-party scripts

Analytics, a pixel, a live-chat widget, a heatmap tool, a cookie banner, an A/B testing tool… Each one looks harmless on its own. But they occupy the main thread, and that's what kills INP directly: the user clicks, the browser is busy, the response is delayed.

What to do:

• Take inventory. Every script running on the site should have an owner and a reason. Delete the orphans.
• Defer anything non-critical, or load it after user interaction. A live-chat widget doesn't need to load the moment the page opens.
• Watch long tasks in Chrome DevTools → Performance to see exactly which script is blocking for how long.

5. Server response time (TTFB)

Fifth on the list, but when it's the cause, it overrides everything else you do. If the browser gets the first byte in 1.5 seconds, nothing you do on the front end will hit your LCP target.

What to check, in the order I run into them most often:

• N+1 queries: if a list has 50 records and each one triggers a separate query, that's 51 queries. The most common and the easiest to fix.
• Missing database indexes: if the columns you use in WHERE and ORDER BY aren't indexed, the table gets scanned end to end.
• A third-party API call on every request: exchange rates, shipping quotes, weather — cache these.
• An outdated PHP version: going from PHP 7 to 8.3 can be a serious win without changing a single line of code.

If you've tried all of these and TTFB is still stubbornly high, the problem might not be a single setting but the platform itself. On a setup where thirty plugins load on every request, there's a ceiling to what optimization can do — that's the point where it's worth reading about when a custom solution actually makes sense.

How to measure it

Critical point: don't confuse lab data with field data. Lighthouse runs a simulation on your own machine — useful while developing, not enough to base a decision on. Your real users' experience lives in the Core Web Vitals report in Search Console, and in the field data section at the top of PageSpeed Insights.

That's also what Google looks at for ranking. Scoring 100 on Lighthouse and seeing red in the field is entirely possible — and so is the reverse.

The order I follow

When I sit down to speed up a site, here's the sequence: measure TTFB first, and if that's the problem I don't touch the front end at all. If not, I fix the hero image — usually the single biggest win on its own. Then fonts, then layout shifts, then the script inventory last. Following this order, most sites go green within two days of work.

Performance is just one item on the list of things to verify before launch — see the rest in the 20-point technical SEO checklist.