On this page · 9 sections
You invested in a WordPress site. You chose “good” hosting, installed a premium theme, added the plugins your agency recommended. And yet, when you test on PageSpeed Insights, the score sits between 30 and 55. The site takes 3 to 5 seconds to load. On mobile, it is worse.
This is not your fault. It is the architecture.
The 5 technical reasons why WordPress is slow by default, the real performance numbers in 2026, and the options available to you — from optimisation to migration.
The numbers no one shows you
Let’s start with data. Not the marketing promises from WordPress hosts — the actual measurements:
| Metric | WordPress (average) | Recommended threshold |
|---|---|---|
| Load time (desktop) | 3.4 seconds | < 2.5 seconds |
| Load time (mobile) | 8.6 seconds | < 2.5 seconds |
| Average page weight | 2.3 MB | < 1 MB |
| CWV pass rate | 33 to 40% | 100% |
| Average Lighthouse score | 40 to 55 | > 90 |
8.6 seconds on mobile. Over 60% of WordPress sites fail Core Web Vitals. These are not poorly built sites — this is the WordPress average.
The average public WordPress page runs 55 SQL queries and 483 milliseconds of PHP before sending a single byte to the browser. A static site sends the HTML immediately.
DebugHawk data, 5.7 million page views analysed (2025).Reason 1: PHP rebuilds every page on every visit
When someone visits your WordPress site, here is what happens:
- The browser sends a request to the server
- The server starts PHP
- PHP loads WordPress (core, theme, plugins)
- WordPress queries the MySQL database (55 queries on average)
- PHP assembles the HTML page
- The server sends the HTML to the browser
This process takes a median 483 milliseconds — before the browser even begins to display anything. And it repeats on every visit, for every page.
A static site (Astro, Hugo, Eleventy) does step 5 once, at build time. After that, the server sends the HTML file directly — no PHP, no database, no rebuilding.
WordPress is a restaurant that cooks every dish to order, even though 80% of customers order the same thing. A static site prepares all dishes in advance and serves them immediately. The food on the plate is the same — the wait time is not.
Reason 2: plugins load JavaScript everywhere
Your contact form plugin loads 200 KB of JavaScript. On every page. Including pages that have no form.
Your slider loads its animation script. Your SEO plugin loads its analysis scripts. Your chatbot loads its full library. Your analytics tool loads its tracker. Each plugin adds JavaScript — and most load it on every page, not just where it is used.
An average WordPress site loads between 300 and 450 KB of JavaScript. Each script must be downloaded, parsed, and executed by the browser before the page becomes interactive.
The result: your page looks loaded, but nothing responds when you click. This is exactly what the INP metric (Interaction to Next Paint) measures — and 23% of mobile sites fail this threshold, a much higher percentage on plugin-heavy WordPress sites.
Reason 3: premium themes are heavy by design
WordPress “premium” themes (Divi, Avada, Elementor) are built to do everything. Mega menus, parallax, animations, sliders, dynamic grids, modals, accordions — the theme loads code for all these features, even if you only use a fraction of them.
A theme like Divi loads roughly 1.2 MB of resources (CSS + JS) before your content even appears. This is not a bug — it is the direct consequence of the “all-inclusive” model.
Elementor, Divi, WPBakery and others create deeply nested HTML (dozens of divs inside divs). This “DOM bloat” slows down browser rendering, increases CLS, and makes the HTML heavier. The problem is not that these tools are badly made — it is that their flexibility has a performance cost no one mentions at the point of purchase.
Reason 4: the database grows and slows down
WordPress stores everything in MySQL: posts, pages, comments, options, metadata, revisions, plugin data, sessions, transients. Over time, that database grows.
The concrete problems:
- Infinite revisions: by default, WordPress keeps every revision of every post. A post edited 50 times has 50 copies in the database
- Expired transients: temporary data that is never cleaned up
- Uninstalled plugin data: many plugins leave their tables behind after removal
- Unoptimised queries: some plugins run queries without indexes, which slow down as the table grows
On admin pages, the P95 (slowest 5% of requests) reaches 1,598 SQL queries and 3.2 seconds of database processing. This is why your WordPress dashboard can feel so sluggish.
Reason 5: images are not optimised by default
WordPress accepts images as you upload them. If you upload a 3 MB JPEG straight from your camera, WordPress serves it as-is (with some resized versions, but not always in the right format).
Common problems:
- No automatic conversion to WebP or AVIF
- No reliable native lazy loading before WordPress 5.5 (and still imperfect)
- Dimensions are not always declared (which causes CLS)
- Above-the-fold images are not prioritised
A plugin like ShortPixel or Imagify partially fixes this. But that is yet another plugin — with its own JavaScript, its own queries, and often a paid subscription.
What you can do (without migrating)
If migrating is not an immediate option, here are the actions ranked by impact:
Install a caching plugin (WP Rocket, LiteSpeed Cache). Impact: -50 to -70% on load time. This is the single most cost-effective measure.
Deactivate each plugin one by one and measure the impact. Remove those that load JS on every page for no reason.
Convert all your images to WebP. Use lazy loading. Declare dimensions. Impact: -30 to -50% on page weight.
Put Cloudflare in front of your site (free plan). Static files are served from the server closest to the visitor.
Realistic result: with these 4 actions, you can go from a Lighthouse score of 35 to 60-70. That is significant progress. But you will probably not get above 80 — because PHP, the database, and plugin JavaScript are still there.
Caching plugins (WP Rocket, W3 Total Cache) mask the problem — they store the HTML page in memory to avoid rebuilding on every visit. This is effective but fragile: every form, every personalised content, every cookie breaks the cache. And you end up with a performance tool that itself needs configuration and maintenance.
What slowness costs you
The numbers are not abstract:
- +8.4% retail conversions for every 0.1s faster load time (Deloitte / Google, Milliseconds Make Millions, 2020)
- +32% bounce probability when load time goes from 1 to 3 seconds (Google / SOASTA, 2017)
- 3× higher conversion rate on a B2B site loading in 1s vs 5s (Portent, 2022)
- 53% of mobile visitors abandon after 3 seconds of load time (same Google / SOASTA source)
If your site gets 10,000 visits per month and 2% convert, even a 0.1-second improvement can mean dozens of extra conversions per month. This is not a marketing argument — it is arithmetic.
When optimisation is no longer enough
If after caching, plugin audits, WebP images and a CDN your Lighthouse score remains below 60, the problem is no longer configuration. It is architecture:
- PHP rebuilds the page on every uncached visit
- The database is hit on every request
- Plugins load JavaScript you cannot remove without losing features
- The premium theme is too heavy to lighten
At that point, two options:
- Live with it — and accept that your site will always be slower than competitors who made a different technical choice
- Migrate — to an architecture that does not suffer from these problems by design
We wrote a complete guide on the second option: Migrating from WordPress to Astro: the complete guide.
Want to know where your site stands? PageSpeed Insights gives you the answer in 30 seconds. If the results confirm what you suspected, the configurator shows what an Astro site would cost — same features, no slowness.