If you want to improve your Core Web Vitals, don't start with some random plugin. Start with the question of why the page is so slow in the first place. A website that takes three seconds to load on a phone loses roughly half its visitors before they've seen anything at all. That's not scaremongering. We measure it on almost every new client. And the causes are nearly always the same four.
We build and maintain websites for small businesses around Fuerstenfeldbruck, Olching, Germering and the western edge of Munich. In that time we've opened up dozens of small-business sites and looked at where the time gets lost. Usually it's the same suspects. Here they are, each with a fix you can put in place without a computer science degree.
What are Core Web Vitals, exactly?
Core Web Vitals are three measurements Google uses to judge how fast and stable your page feels to real users. The first measures when the largest element becomes visible (LCP). The second, how quickly the page reacts to the first tap (INP). The third, whether things jump around while the page loads (CLS). Google uses these values as a ranking signal. Your customers use them, without knowing it, as gut feeling. Slow equals untrustworthy.
Why do huge photos make a website slow?
By far the most common mistake. Someone uploads a photo straight off their phone camera or DSLR, 5000 pixels wide, 8 megabytes heavy, and drops it in as the hero image. The browser has to download that entire file before it can show the picture. On a patchy mobile connection at a bus stop in Puchheim, that feels like forever.
A real example. A baker from the district came to us because his site felt "kind of sluggish". We measured: 4.1 seconds until the hero image appeared. The culprit was a single photo, a close-up of a loaf of bread, 8 MB. We scaled it down to the size actually needed, converted it to WebP, and compressed it properly. After that: 0.9 seconds. An 8 MB brick became 140 kilobytes. The bounce rate dropped noticeably over the following weeks, and the owner called to say he thought we'd "made the whole internet faster".
The fix, in short:
- Resize photos to their display size before uploading. A hero image rarely needs to be more than 1920 pixels wide.
- Use a modern format. WebP or AVIF are far smaller than JPEG at the same visual quality.
- Hard-code the width and height in the markup, and set
loading="lazy"on images further down the page.
How many tracking scripts are too many?
The second classic. Over the years, stuff piles up. Google Analytics, plus the Facebook pixel, a chat widget, a review badge, a cookie-banner tool, maybe an old newsletter popup nobody needs anymore. Each of these scripts loads code from someone else's server, blocks rendering, and eats up processing time on your visitor's phone.
At one physiotherapy practice, we once counted eleven external scripts. Eleven. Half of them belonged to services the client no longer actively used. Clearing them out took two hours and shaved off almost a full second. With every script, ask yourself honestly: do I really need this, and if so, does it have to load the instant the page opens, or is later fine? A related topic that often plays into this: the three WordPress plugins that grind websites to a halt.
Why does the text flicker while the page loads?
You know the effect? The page loads, for a split second you see text in a default font, then everything shifts because the actual typeface loads in afterwards. That's called FOUT, and it looks cheap. The reason: the font often comes from Google Fonts, so from someone else's server, and the browser sits there waiting for it.
Two things help. First, host the font files on your own server instead of pulling them from Google. That's also cleaner for your privacy policy, because then no visitor IP addresses get sent to Google (a real concern under German and EU data-protection law, GDPR). Second, set font-display: swap in the code so readable text appears immediately. And if you're honest with yourself: one or two font weights are usually enough. Not seven.
What is layout shift and why is it so annoying?
The fourth mistake is the sneakiest, because it has nothing to do with load time and everything to do with stability. You go to tap a button, at the last moment an image loads in above it, everything slides down, and you hit the ad instead of the button. That's exactly what CLS stands for, the jumpy layout. Google penalises it, and users hate it.
The most common triggers: images without a fixed size, ad blocks that only claim their space late, and fonts loaded in at a different height. The fix is usually unglamorous. You reserve the space from the start. Height and width for every image, fixed containers for dynamic content. Nothing wild, just care during the build. Anyone who takes web design seriously builds this in from the first line, instead of patching it afterwards.
What does optimisation actually get you?
Honestly, it depends heavily on how bad the starting point is. If a site is already built decently, you might claw back a few tenths of a second. If there's an 8 MB image lurking in it like the baker's, you claw back three seconds. But what we see almost every time: fewer bounces, longer time on page, more enquiries through the contact form. Speed isn't an end in itself. It's the precondition for your content getting a chance at all. And it feeds into local visibility too, as described in the piece on local SEO on no budget.
Frequently Asked Questions
How can I test my own Core Web Vitals?
For free, through Google's PageSpeed Insights. Enter your address, choose the mobile view, read off the values. Pay attention to the field data at the top (real users), not just the lab test. For raw load time, the network tab in your browser does the job too.
Is a caching plugin enough to make a website faster?
It helps, but it doesn't solve the core problem. A cache serves the page faster, but it doesn't shrink an 8 MB image and it doesn't remove a redundant tracking script. Fix the causes first, then put caching on top.
Do I need to rent a more expensive server for fast load times?
Usually no. On the vast majority of small-business sites, the problem is in how the page is built, not in the hosting. Optimise first, then check whether the server is even the bottleneck. Often it isn't.
Want to know where your site stands, without clicking through menus yourself? In our free website check we look specifically at load time, the four mistakes above, and which lever would move the needle fastest. No sales pitch, just numbers and an honest read. Get in touch here, and we'll get back to you from Fuerstenfeldbruck.