Anyone trying to improve core web vitals quickly drowns in half-knowledge: one forum recommends a plugin, another ticks a box, and in the end the site is slower than before. After years of actually making business websites faster in Vienna and across the DACH region, I can tell you this: most bad scores come from a handful of concrete causes – and a few measures deliver the bulk of the effect. The rest is myth. I will explain the three metrics in plain words, show the real causes, separate impact from superstition, and tell you when you need a specialist.
The three metrics in plain words
Core Web Vitals are three measurements Google uses to judge how fast and stable a page feels for real users. They feed into ranking – but above all they decide whether visitors stay or bounce. Instead of technical definitions, here is what they really mean:
LCP – how fast the important part appears
Largest Contentful Paint measures how long it takes for the biggest visible element to load – usually the hero image or the headline. Translated: how long does the visitor stare at a half-empty page before „something is there”? Good is under 2.5 seconds. This is the value that most directly shapes the first impression.
INP – how fast the page responds
Interaction to Next Paint replaced the old FID metric in 2024 and measures how quickly the page reacts to clicks and input. Translated: you tap a button – does something happen instantly, or does the page briefly freeze? Good is under 200 milliseconds. A poor INP feels especially sluggish to users because it interferes precisely at the moment they become active.
CLS – how stable the layout is
Cumulative Layout Shift measures how much content jumps around while loading. Translated: you go to tap a link, an ad loads in, everything slides, and you hit the wrong thing. Good is under 0.1. A poor CLS is the one users hate most, even if they cannot name it.
Important to understand: these three values are connected but have different causes. You can have a good LCP and still a poor INP – or the other way around. That is why blindly „making the site faster” gets you nowhere; you have to know which of the three is stuck and target its cause specifically. That is exactly what separates real optimisation from tinkering.
The real causes of bad scores
Before you optimise anything, you have to know what is wrong. In practice it is almost always the same four sources – and usually several of them together.
Images: the most common brake
Huge, uncompressed images are cause number one for poor LCP. A 4 MB photo loaded at full size and then shown small costs seconds. The fix is unspectacular but effective: serve images in modern formats like WebP, at the size actually needed, and lazy-load whatever sits below the visible area. No image should have missing dimensions either – that is exactly what also drives up CLS.
Fonts: the underestimated cause
External web fonts loaded from third-party servers delay rendering and make text appear briefly invisible or in the wrong typeface – bad for LCP and CLS at once. Host fonts locally, reduce the formats, and tell the browser it may show the text immediately with a fallback: small in effort, noticeable in the result.
Plugins and scripts: the quiet INP killer
Every plugin brings its own code, every tracking script runs in the background. Too many of them block the browser and make the page sluggish – INP in particular suffers from overloaded JavaScript. Less is almost always more here; a plugin diet often works better than any cache tuning.
Hosting: the foundation nobody sees
The fastest code is useless on an overloaded cheap server. The time until the server’s first response sits directly inside LCP. Solid hosting with a current PHP version is the invisible foundation everything else builds on – and the point where many people save at the wrong end. Why that is often the real cause, I described in detail in my piece on why your website is slow.
What works – and what is myth
This is where practice parts ways with forum half-knowledge. The table below shows what actually moves the needle and what burns time.
| Measure | Impact | Note |
|---|---|---|
| Compress images & WebP | high | The biggest lever for LCP, almost always first |
| Fewer / leaner plugins | high | Direct effect on INP, often underestimated |
| Solid hosting | high | Foundation – a poor server caps everything |
| Fonts local & optimised | medium | Affects LCP and CLS, low effort |
| Install a caching plugin | medium | Helps, but no cure-all – the order matters |
| „Minify everything by checkbox” | low / risky | Aggressive optimisation often breaks the layout |
The biggest myth is the belief that a single optimisation plugin fixes everything at the push of a button. These plugins do help – but activated blindly, they often cause more harm than good, because aggressively combining scripts breaks functions. The second myth: the perfect score of 100 in a test. That is nice cosmetics, but Google grades what real users experience (the so-called field data), not the lab result of one single run.
A third myth stubbornly persists: that a content delivery network (CDN) automatically speeds up everything. A CDN helps when your visitors are spread far apart, but does little if your audience sits in the DACH region anyway and your server is there too. It is a tool for a specific case, not a cure-all. And perhaps the most expensive myth: that optimisation is a one-off action. It is not. Every new plugin, every large image, every embedded third-party content can undo the values you worked hard to reach. Performance is a state you maintain, not a checkbox you tick once – which is exactly why watching load time belongs in ongoing website care and maintenance, not just in the relaunch.
The order matters just as much as the measure itself, by the way. Whoever first activates an aggressive caching plugin and then compresses images often chases bugs they created themselves. It makes sense to start with the real causes – images, plugins, hosting – and only set the fine-tuning via caching at the end. That way you know at each step what moved the value, instead of guessing afterwards.
The tools that matter
You do not have to guess. Two sources are enough to judge your scores honestly:
- PageSpeed Insights. Google’s free tool shows your three metrics and lists concrete improvements. Important: look at the field data (real users) at the top, not just the lab value below it.
- CrUX / Search Console. The Chrome User Experience Report collects your visitors’ real values over 28 days. In Search Console, the „Core Web Vitals” report shows which page groups score poorly – that is the truth Google measures you against.
An important note on interpretation: a single PageSpeed test fluctuates. Rely on the field data over several weeks, not on one good or bad individual value. And optimise by page type – the homepage, a blog article and a product page each have their own brakes.
When you need a specialist
You can tackle a lot yourself: compress images, remove superfluous plugins, choose better hosting. That often already gets you from red to green. Hand over to a professional when:
- INP stubbornly stays poor. JavaScript problems are rarely solved by a checkbox – this needs someone who understands which script blocks when.
- optimisation plugins break your site. If forms, sliders or the checkout stop working after activation, it calls for handwork, not checkboxes.
- the cause sits deeper. A poorly built theme, bloated code or database problems cannot be papered over with a cache.
When you reach that point, an outside look pays off. How I examine an existing site technically and find the real brakes is described in my technical consulting.
Conclusion
Improving Core Web Vitals is not magic, it is prioritisation. The three metrics measure how fast the important part appears (LCP), how quickly the page responds (INP) and how stable the layout stays (CLS). The real causes are almost always the same: oversized images, too many scripts, external fonts and weak hosting. Whoever tackles these four captures the bulk of the effect – and spares themselves the checkbox roulette of optimisation plugins. Measure against the field data, not the lab value, and hand over to a specialist as soon as it comes down to JavaScript or the substance of the site.
Your scores are in the red and you do not know where to start? Send me a quick message via the contact form. I will look at your site and tell you which two or three measures make the biggest difference for you.
