“Why is my website slow?” is the question I hear most often from new clients here in Vienna – usually after they have already tried two optimisation plugins and an upgrade to a bigger hosting plan, and nothing changed. The frustrating truth: most speed advice online is either generic or written to sell you something. After auditing dozens of slow business websites and shops across Austria and Germany, I can tell you the real causes repeat with remarkable consistency – and they are rarely the ones people guess first. Here is how I diagnose a slow site in fifteen minutes, what the usual suspects are, and which fixes actually move the numbers instead of just polishing a score.
Start with a proper diagnosis – it takes 15 minutes
Never optimise blind. Before touching anything, I run three free tools: PageSpeed Insights for the overview, WebPageTest for the detailed loading waterfall, and Google Search Console for data from real visitors. The distinction that matters most is lab data versus field data. Lab data is a single simulated test; field data is what actual Chrome users experienced over the last 28 days. Google ranks you on the field data – the Core Web Vitals – not on the lab score.
The three numbers that count
- LCP (Largest Contentful Paint): when is the biggest visible element loaded? Target: under 2.5 seconds. This is the headline metric, and the one heavy images and slow servers destroy.
- INP (Interaction to Next Paint): how fast does the page react to clicks and typing? Target: under 200 milliseconds. Too much JavaScript shows up here.
- CLS (Cumulative Layout Shift): does the layout jump around while loading? Target: under 0.1. Usually caused by images without defined dimensions and late-loading banners.
And one number to stop worshipping: the PageSpeed score from 0 to 100 is a lab value, not a ranking factor. I have seen sites scoring 74 that pass every Core Web Vital comfortably, and sites scoring 95 that feel sluggish to real users. If you want the bigger picture of how speed fits into search visibility, I have written about technical SEO as the foundation before content separately.
The five usual suspects
In nine out of ten audits, the slowdown comes from one of these five areas – usually several at once. Check them in this order.
1. Cheap hosting with a slow server response
The first value I check is Time to First Byte (TTFB) – how long the server takes before it even starts answering. On decent hosting, an uncached WordPress page responds in 200 to 500 milliseconds. On overcrowded five-euro shared servers I routinely measure 1.5 to 2.5 seconds before a single byte of HTML arrives. Past that point, every other optimisation is cosmetic: compressing images on a two-second server is polishing the door handle of a house with no foundation. My rule of thumb: if TTFB consistently sits above 800 milliseconds, the hosting goes on trial first.
2. Images nobody ever optimised
The eternal classic: the 6000-pixel photo from the photographer goes straight into the media library and onto the homepage slider – 4 MB for an image displayed 800 pixels wide. I have audited homepages weighing 15 MB, of which 13 MB were images. The fix is boring and extremely effective: serve images at the size the layout actually needs, convert them to WebP or AVIF (typically 30 to 70 percent smaller than JPEG), and lazy-load everything below the fold. For one Viennese trades business this took the homepage from 11 MB down to 1.3 MB – LCP dropped from 6.8 to 1.9 seconds without changing a single pixel of the design.
3. Plugin sprawl and overweight themes
It is not the number of plugins that hurts – it is what they load. A cleanly built plugin with twenty PHP files is harmless; a single page builder or a “mega theme” with a bundled slider, icon library and three tracking scripts can dump 2 MB of JavaScript onto every page, including pages that use none of it. A typical audit finding: a WooCommerce shop with 41 active plugins, 28 of which load their CSS and JavaScript on every single page. Outdated and abandoned plugins are a security problem on top – one of several reasons regular WordPress maintenance pays for itself twice.
4. Web fonts – the invisible brake
Fonts are chronically underestimated. Six weights of a Google font plus an icon font quickly add up to 500 KB – and because fonts can block rendering, your visitor sees exactly nothing until they arrive. What helps: load only the weights you actually use (usually regular and bold), stick to WOFF2, set font-display: swap so text never stays invisible, and host the files locally instead of pulling them from Google. Self-hosting is faster and – for anyone serving EU visitors – the safer choice under GDPR, as the German court rulings on Google Fonts made very clear.
5. No caching, or caching set up wrong
WordPress rebuilds every page from database queries on every visit – pointless for content that changes once a week. A page cache serves ready-made HTML instead and cuts server response from 800 to under 100 milliseconds. Add sensible browser-cache headers for static files, and for shops an object cache such as Redis so repeated queries stop hitting the database. But understand what caching cannot do: it hides slow code only from the second visitor. The first hit, the cart, the checkout and everything dynamic stay exactly as slow as the foundation underneath.
What actually moves the needle – and what does not
This table ranks the most common measures by effort and real-world effect, based on what I measure in client projects rather than what plugin vendors promise:
| Measure | Effort | Typical effect |
|---|---|---|
| Changing hosts when TTFB exceeds 800 ms | Medium – half a day including migration | Very high: often 1–2 seconds off every page load |
| Images: correct sizes, WebP/AVIF, lazy loading | Low to medium | High: usually the biggest LCP lever |
| Setting up page and browser caching properly | Low | High: server response from 800 ms to under 100 ms |
| Removing unused plugins and scripts | Medium | Medium to high: less JavaScript, better INP |
| Reducing and self-hosting fonts | Low | Medium: faster text rendering, no flashing |
| Adding yet another “optimizer” plugin | Low | Low to negative: hides symptoms, creates conflicts |
Three myths that refuse to die
- “We just need a more powerful server.” More CPU does not shrink a 4 MB image or unblock render-blocking JavaScript. Diagnose first, scale second – in that order.
- “A caching plugin will sort it out.” A cache compresses no images and removes no bloated scripts. Worse, aggressive settings like CSS and JS merging regularly break layouts and checkouts – I spend more time repairing over-optimised sites than speeding up slow ones.
- “Just put a CDN in front of it.” A CDN shortens the distance to far-away visitors. If your customers are in Austria and your server is in Germany, you gain a few milliseconds – not the two seconds an overweight theme is costing you.
When it is worth bringing in a specialist
Much of this you can do yourself: compress images, prune plugins, configure a caching plugin carefully. But some situations cost more in DIY time than in professional help: when TTFB stays high despite good hosting (the problem is in the code or the database), when a shop is slow precisely in the checkout (no cache applies there), or when every optimisation round breaks something else. For a structured root-cause analysis with a prioritised action list, that is exactly what my technical consulting covers; if you would rather hand the topic off permanently, ongoing website care and maintenance includes performance monitoring as standard.
For orientation: a thorough performance audit with a prioritised list takes one to two days, implementing the top items another one to three depending on the site. Compare that with what a permanently slow website costs you in lost enquiries and abandoned carts every single month, and the maths is rarely close.
Conclusion
A slow website is not fate, and it is rarely solved by a bigger server. It is almost always the sum of weak hosting, heavy images, too much JavaScript and missing caching – in roughly that order of frequency. Measure first with PageSpeed Insights and real field data, fix the biggest brakes before the small ones, and ignore the temptation to chase a score of 100. What matters is what your visitors experience, not what a lab test claims.
Want to know exactly where your website loses its seconds? I will take a look and give you an honest diagnosis with priorities – not an off-the-shelf plugin list. Drop me a short message via the contact form; I usually reply the same working day.
