“My site is slow” is one of the most common things I hear from new clients, usually followed by “so I upgraded my hosting.” Better hosting can help, but in most cases it’s treating a symptom, not the cause. Here’s what’s actually slowing WordPress sites down, based on what I find during performance audits.
Too many plugins doing too much
Every plugin adds its own CSS, JavaScript, and often database queries on every page load. A site running twenty-plus plugins, several of which overlap in what they do, is fighting an uphill battle no matter how fast the server is.
The number itself matters less than what each one loads. A plugin that only runs in the admin costs a visitor nothing. One that enqueues a stylesheet and a script on every page, including the pages it has nothing to do with, costs them on every visit. That is the distinction worth auditing: not how many plugins are installed, but how many are loading assets on the page someone actually landed on.
Page builders that generate bloated markup
Visual page builders are great for speed of building, but they often generate deeply nested divs and inline styles that the browser has to work harder to render. Custom WordPress development avoids this from the start.
That said, the builder is rarely the deciding factor. Ironclad Sites runs on Elementor Pro and scores 97 on mobile, because the CSS is printed to external files instead of inlined on every page, fonts load with swap, and LiteSpeed caches the result. The same builder with none of that configured is where the reputation comes from.
Unoptimized images
This is the single most common issue I find. Full-resolution photos straight from a phone or stock site, uncompressed and unresized, are still one of the biggest contributors to slow load times.
A photo off a modern phone is commonly three to five megabytes and several thousand pixels wide. Displayed in a slot 800 pixels across, every one of those extra pixels is downloaded and thrown away. Resizing to the size it is actually shown at, converting to WebP, and letting anything below the fold load lazily usually takes the most weight off a page for the least work.
This is not a small effect. When I measured nine local business sites around Silang and Cavite, three of the nine homepages were over 5 MB, which is roughly five times what a homepage should weigh.
No caching or a poor caching setup
Without page caching, WordPress rebuilds every page from scratch on every visit, running database queries and PHP processing that could otherwise be served instantly from a cached copy. A properly configured caching setup is one of the highest-leverage fixes available.
It is also the fix people most often assume they already have. Having the plugin installed is not the same as having it working, and the quickest way to find out is to look at how long the server takes to return the HTML before anything else happens.
Render-blocking scripts and fonts
Third-party scripts, like chat widgets, tracking pixels, and font libraries, that load before the page can render will delay everything the visitor sees. This is the one that hides best, because nothing about it looks slow. The files are tiny. The server is fast. The page still takes seconds to show anything.
A worked example, on this site
This site was measuring 79 on mobile while client sites sat in the high nineties, so I ran the same audit on it that I would run for anyone else. Everything a checklist tells you to fix was already fine: the server returned the HTML in 10 milliseconds, total blocking time was 0, layout shift was 0, and every file on the page finished downloading inside 341 milliseconds.
First paint still measured 3.3 seconds.
The cause was a single stylesheet. The fonts were loaded from Google’s servers, which meant that before one letter could appear the browser had to look up a new domain, open a connection, negotiate encryption and fetch a file, then do most of it again on a second domain for the font files themselves. None of that is slow to download. All of it is waiting.
Moving the font files onto this server took first paint from 3.3 seconds to 2.8, and the score from 79 to 83.
Two honest notes on that. It is a four point gain, not a transformation, and I would rather say so than round it up. And I got the measurement wrong the first time: PageSpeed Insights serves a cached result for a minute or two, so four runs back to back returned four identical numbers that looked like precision and were nothing of the kind. Space the runs a few minutes apart, or you are measuring the cache.
The fix isn’t usually “spend more on hosting.” It’s finding and removing the specific things slowing your site down, the same technical issues covered in 5 technical SEO fixes that actually move rankings. That’s exactly what I look for in a performance audit.