Quick answer: measure properly first — on mobile and using real-user data, not a single tool score. Then fix in order of impact: images, unnecessary scripts and plugins, server response, missing caching. Most problems are solved by a few days of work. But if the site is assembled on a page builder carrying twenty plugins, optimisation will hit the ceiling of the architecture, and rebuilding is cheaper than optimising forever.
A slow website isn't noticed through numbers but through behaviour: people leave before the first screen appears. The owner, meanwhile, sees something else — a PageSpeed score they'd like to get into the green.
That's the wrong target. A tool's score and the actual speed your visitors experience are different things, and the place to start is establishing what exactly is slow, and for whom.
How to measure website loading speed properly
Separate lab data from field data. PageSpeed Insights shows two things: a test run on a notional device, and real-user data if there's enough of it. The first is useful for diagnosis; the second is the only one that matters in practice. A score can be amber while real visitors experience the site as fast, and the reverse.
Check the report in Search Console. The Core Web Vitals section shows which groups of URLs are slow for actual people. That's your baseline, not a number from a tool.
Measure the mobile version. Most traffic is mobile, and problems surface there: weaker processors, worse connections.
Don't draw conclusions from one measurement. Results fluctuate; what matters is repeatability, not a single figure.
Check more than the homepage. The homepage is usually polished, while traffic lands on service pages and articles. Check the twenty pages that bring visitors and enquiries — optimising two hundred irrelevant ones is pointless.
Why a website loads slowly: causes in order of impact
Heavy images. The most common cause and the cheapest to fix. Photographs uploaded straight from a camera weigh megabytes while displaying in a block a few hundred pixels wide. Solved with compression, modern formats and per-device sizing.
Plugin and script bloat. Every plugin adds its own styles and code, often on every page including those where its function isn't used. Twenty plugins means twenty sets of files on every load.
Slow server response. If the server takes a long time to think, everything else shifts later. Causes include weak hosting, an overloaded database and no caching.
No caching. Without it the page is assembled from scratch on every visit. Enabling caching is one of the few changes with an almost immediate effect.
Render-blocking styles and scripts. The browser can't display content until it has fetched whatever sits in the queue ahead of it.
Fonts. Several weights fetched from a third-party domain delay the appearance of text.
Third-party scripts. Chat widgets, analytics, advertising pixels, review widgets. Each looks harmless; together they carry noticeable weight — and you don't control their speed.
Missing dimensions on images and blocks. Doesn't affect speed directly, but causes the layout to jump during loading, which irritates people more than waiting does.
Table: what slows a website down and who fixes it
- First screen takes a long time to appear — Heavy hero image, slow server — Often in-house
- The page "thinks" before loading starts — Server response, no caching — Hosting or a developer
- Everything appears but doesn't respond to clicks — Heavy JavaScript, plugin bloat — A developer
- Layout jumps while loading — No dimensions on images and blocks — A developer
- Several times slower on mobile — Unoptimised images, heavy scripts — Mixed
- Optimisation produces no effect — Architectural ceiling — A rebuild
What you can fix yourself in an evening
Compress the images. Re-upload them at a sensible size in a modern format. It's the most common cause and the quickest win.
Remove unused plugins. Not deactivate — remove. Half were usually installed "to try" and forgotten.
Enable caching if it isn't on.
Strip out unnecessary third-party scripts. A chat widget nobody uses, counters from three analytics systems, widgets left over from an old campaign.
Check the hosting. If the site sits on the cheapest plan, moving to a decent one sometimes achieves more than weeks of optimisation.
Those steps are enough to gauge the scale of the problem. If speed is still poor afterwards, a developer is needed from here.
What requires a developer
Work on fonts and the order stylesheets load in, deferring secondary scripts, critical CSS, optimising database queries, eliminating layout shift, and serving images sized for the device. All of it produces real gains, but it takes knowing what can be touched and what will break.
A separate warning: "speed up in one click" plugins sometimes help and sometimes break layout and functionality. They get tested on a copy of the site, not the live one.
When optimisation stops helping and a rebuild is needed
There comes a point where further optimisation turns into a fight with the architecture.
The signs: you've compressed the images, enabled caching, removed half the plugins, and the numbers barely moved. Or they moved and reverted after a theme update. Or every improvement breaks something else.
The cause is usually how the site was assembled. A page builder loads code for every eventuality, including features that aren't on the page. A theme bought as universal drags along capabilities you don't need. You can optimise that indefinitely, and the ceiling will still be there.
An example from practice. A Warsaw wheel restoration workshop's site ran on an ageing platform and was slow. I rebuilt it on a custom WordPress theme — no builder, no heavy plugins, so only what's needed loads. Mobile performance went from around 50 to 92. That wasn't the result of optimisation but of a different build: the same content, a different architecture.
The practical conclusion: if optimisation produces no effect two or three attempts in a row, it's cheaper to cost out a rebuild than to keep going.
Does website speed affect rankings and enquiries
Honestly: speed is a ranking factor, but not the main one. A slow site with strong content will outrank a fast, empty one. If your pages sit at position fifty, speed isn't the issue.
Its effect on human behaviour, though, is direct — especially on mobile. A visitor who doesn't wait for the first screen never sees the offer, the prices or the button. In that sense speed isn't about SEO at all; it's about whether people reach your content.
So the right order is: if there are no rankings, work on visibility first. If there's traffic but no enquiries, speed belongs on the shortlist of suspects alongside the offer and how easy you are to contact.
How I work on website speed
I combine development and SEO, so I look at speed not as a score in a tool but as part of the chain from a search impression to an enquiry.
Technical audit — from €250. What specifically is slowing things down, in what order to fix it, what you can handle yourselves, and what runs into the architecture.
Rebuilding the site — from €1,000, if the audit shows optimising the existing build costs more than assembling it again.
Sometimes the audit's outcome is a list of three things to do in one evening, and I say so: a rebuild often isn't needed.
Where to start if your website is slow
Reduced to one principle: measure on real users first, then fix in order of impact, and don't chase the score.
A practical step for today: open the Core Web Vitals report in Search Console and see which groups of pages are flagged. Then check those pages in PageSpeed on mobile. Those two steps are enough to know whether you're looking at an evening's work or a rebuild.
If you'd rather settle it faster, write to me and I'll find what's actually slowing your site down.
