Why your WordPress site is slow: the 7 most common causes
From diagnosis to fix — with data. Before spending on a CDN or premium plugin, identify the real cause.
- 80% of slow WordPress sites share the same 7 causes — identifying the right one avoids unnecessary spending
- Hosting is the most underrated #1 cause: a TTFB over 800 ms cannot be compensated by front-end optimizations
- Each cause has a specific fix — Orilyt automatically detects causes 1, 2 and 5 through tests #01, #02 and #07
Your WordPress site is slow — but why? That's the question thousands of site owners ask every day. And that's where the mistakes start: install a cache plugin, buy a CDN, switch themes... without ever diagnosing the real cause.
The reality is that 80% of slow WordPress sites suffer from the same 7 problems. These problems are well-documented, measurable, and — good news — most can be fixed without a big budget.
In this article, we'll go through each cause with concrete data, explain its real impact on user experience and SEO, and give you the precise fix to apply. From diagnosis to correction, step by step.
Cause #1: Overloaded shared hosting
This is by far the most common cause — and the most underrated. On cheap shared hosting, your site shares server resources (CPU, RAM, I/O) with hundreds of other sites. When the neighbors are active, you suffer.
The key indicator is TTFB (Time to First Byte): the time between sending the request and receiving the first byte of response. Healthy hosting responds in under 200 ms. Above 800 ms, it's critical — and no front-end optimization can compensate.
Cause #2: Unoptimized images
Images account for an average of 50 to 70% of a web page's weight. On a typical WordPress site, they're often uploaded in their original format (high-resolution JPEG or PNG), without WebP conversion, without compression, and without declared dimensions.
The result: a page that downloads 3 MB of images when it could download 800 KB with the same visuals. In WebP, images are 25 to 35% lighter than JPEG. Lazy loading avoids loading off-screen images on first load.
Cause #3: Too many active plugins
WordPress is extensible by nature — and that's its strength. But every active plugin has a cost: it adds HTTP requests, loads additional CSS and JavaScript, and runs database queries on every page load.
Beyond 30 plugins, the probability of conflicts and significant slowdowns increases sharply. A single poorly-coded plugin can multiply SQL queries by 10. Tracking, SEO, security and form plugins are the most resource-hungry.
Cause #4: No caching
Without caching, every visit to your site triggers a full cycle: PHP executed, database queried, HTML generated, response sent. This cycle takes time — from 200 ms to over a second depending on page complexity and server power.
With page caching, the first visit generates the static HTML which is then served directly for all subsequent visits. No PHP, no SQL, just a static file. The performance gain can reach 90%.
Cause #5: Render-blocking JavaScript
The browser reads HTML from top to bottom. When it encounters a script tag without a defer or async attribute, it stops everything, downloads the script, executes it, then resumes. During this time, the user sees a blank page.
This is the "render-blocking JavaScript" problem. On an average WordPress site, there are often 5 to 15 scripts loaded this way: Google Analytics, Hotjar, Facebook Pixel, the theme's jQuery script, widgets... Each adds tens or hundreds of milliseconds.
Cause #6: Unoptimized database
Over time, the WordPress database accumulates unnecessary data that slows down SQL queries: post revisions (WordPress keeps 10 by default), expired transient data, orphaned meta data from uninstalled plugins, spam comments, and fragmented tables.
On a 3-year-old site, the wp_posts table can contain 10 times more revisions than published posts. The wp_options table can weigh several MB due to stacked transients. Every SQL query takes longer to execute.
Cause #7: Heavy theme and page builders
Some "all-in-one" WordPress themes pack dozens of features you use only 10% of: sliders, animations, shortcodes, visual builders... Each adds CSS and JavaScript loaded on every page, even those that don't need it.
Page builders (Elementor, Divi, WPBakery) are particularly problematic. They generate nested and bloated HTML, load multiple CSS and JavaScript files, and often produce non-minifiable inline CSS. An Elementor theme can easily load 500 KB of extra CSS.
How to quickly diagnose
Before fixing, you need to measure. Here are the 3 steps of a quick diagnosis:
- Measure TTFB: use Chrome DevTools (Network tab, look for "Waiting for server response") or GTmetrix. If TTFB exceeds 800 ms, start with hosting.
- Analyze page weight: in GTmetrix or WebPageTest, identify the heaviest resources. 60%+ images? Start with cause #2. Lots of JS/CSS? Causes 3, 5 or 7.
- Test with and without plugins: deactivate all plugins, test speed, reactivate them one by one. Time-consuming but decisive for identifying the culprit.
Orilyt automates steps 1 and 2: test #01 (TTFB), test #02 (page weight) and test #07 (blocking resources) give you an immediate view of causes 1, 2 and 5 without technical manipulation.
Where to start?
If your site is slow and you don't know where to start, follow this priority order: hosting first (cause #1), images next (cause #2), cache (cause #4), JavaScript (cause #5). These 4 fixes cover 80% of cases.
Causes #3, 6 and 7 require more work but have significant impact on mature sites. Plan them for a second phase, once the immediate gains are captured.
For freelancers and agencies, knowing how to diagnose these causes is a key skill. Orilyt generates the performance report in 2 minutes and produces FIA recommendations (Fact, Impact, Action) ready to present to your clients — without having to dig through Lighthouse yourself.