Nine causes explain almost every slow WordPress site: cheap hosting, oversized images, render-blocking code, plugin bloat, a heavy theme or page builder, missing caching, a bloated database, third-party scripts, and uncacheable dynamic pages. The trick: your site usually suffers from two or three of them. Fixing the wrong ones changes nothing. Here is how to tell which ones are yours.
First: measure before you touch anything
Run your site through PageSpeed Insights and look at two things. First, the field data at the top — how real visitors experience the site. Second, the Largest Contentful Paint (LCP) diagnosis below. LCP over 2.5 seconds means visitors are waiting. The diagnostics tell you where the wait lives: server response, render-blocking resources, or the image itself. Every cause below maps to one of those three buckets.
1. Cheap or overloaded hosting
If your Time to First Byte (TTFB) is over 800ms, no plugin will save you. The server itself is slow. Shared hosting at $3/month puts hundreds of sites on one machine. Check this first, because it caps everything else. A perfectly optimized site on a slow server is still slow.
2. Oversized images
The most common cause on business sites. A 4 MB hero photo exported straight from a camera can double your load time by itself. Images should be sized to their display dimensions, compressed, and served in WebP or AVIF format. WordPress does some of this automatically since version 5.8 — but only for new uploads, not your existing library.
3. Render-blocking CSS and JavaScript
Every stylesheet and script loaded in the page head makes the browser wait before painting anything. Themes and plugins add these freely — a typical business site loads 30+ files before showing a pixel. The fixes are deferring scripts and inlining critical CSS. This is exactly the work that separates a real optimization from a checklist pass.
4. Too many plugins — or one bad one
Plugin count matters less than plugin quality. One poorly written plugin firing 300 database queries per page hurts more than 20 lean ones. The tell is slow admin pages and high TTFB that hosting upgrades do not fix. Profiling with Query Monitor finds the culprit in minutes — guessing by deactivating plugins one by one takes days.
5. Heavy themes and page builders
Multipurpose themes and page builders (Divi, Elementor and friends) trade performance for flexibility. They ship CSS and JavaScript for every feature, whether your page uses it or not. They can absolutely be made fast — my day job is Divi development, engineering plugins for the Divi ecosystem, and optimizing builder sites regularly. But it requires builder-specific work, not generic advice. If your builder site is slow, that is a solvable problem, not a rebuild sentence.
6. No caching (or caching set up wrong)
Without page caching, WordPress rebuilds every page from PHP and the database on every visit. A caching plugin fixes this in an afternoon. Yet caching misconfiguration is also the #1 cause of “I optimized my site and it broke.” Cache the pages, exclude the dynamic parts (carts, account areas), and test on staging first.
7. Database bloat
Years of post revisions, expired transients, spam comments, and leftover tables from deleted plugins slow down every query. A 500 MB database serving a 40-page site is a red flag. Cleanup is safe with backups and dangerous when done blindly. This is where a professional pass earns its fee.
8. Third-party scripts
Chat widgets, heat maps, font services, video embeds, and tracking pixels each add external requests you do not control. A single YouTube embed can add over 1 MB. Audit what actually earns its keep; lazy-load or facade the rest.
9. Uncacheable dynamic pages
WooCommerce carts, membership dashboards, and logged-in views bypass page caching by design. These pages need a different toolkit: object caching (Redis), query optimization, and selective fragment caching. If your store is slow but your blog is fast, this is why. It is specialist work, not plugin-installation work.
Why sites stay slow after “optimization”
Most failed optimizations treat symptoms from a checklist instead of diagnosing causes. I wrote about why some sites stay slow even after optimization. The pattern repeats: someone installed caching, but nobody identified the real cause — hosting, a rogue plugin, builder bloat. Diagnosis first, fixes second, before/after numbers as proof.
What to do next
Want to try yourself? Measure with PageSpeed Insights, fix images, add caching carefully, and check TTFB against your host. If you want it handled with proof, my speed optimization service starts with a measured audit and a scoped quote. I have also written up what speed optimization costs and what you get, so you know the market before talking to anyone — including me.