Your WordPress site is slow. Here is why.

A median score of 43 out of 100, one site in two failing Core Web Vitals: the 6 causes of WordPress slowness and what you can do about it.

On this page · 11 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 numbers no one shows you#

Let’s start with data. Not the marketing promises from WordPress hosts — the actual measurements:

Metric (mobile)WordPress, market medianWhat to aim for
Lighthouse Performance score43 / 100> 90
Page weight≈ 3 MB< 1 MB
Sites passing all 3 Core Web Vitals48%Yours

Data: HTTP Archive Tech Report, September 2026, mobile, all origins.

A median score of 43 out of 100, and more than one WordPress site in two failing Core Web Vitals on mobile. 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:

  1. The browser sends a request to the server
  2. The server starts PHP
  3. PHP loads WordPress (core, theme, plugins)
  4. WordPress queries the MySQL database (55 queries on average)
  5. PHP assembles the HTML page
  6. 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.

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 several hundred kilobytes of CSS and JavaScript before your content even appears. This is not a bug — it is the direct consequence of the “all-inclusive” model.

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.

Reason 6: hosting and the PHP version#

It is the cause you will hear first, and it is real. A saturated shared server adds waiting time before WordPress even starts, and the PHP version weighs on every page it generates. WordPress currently recommends PHP 8.3 or newer. Check your host’s version under Tools > Site Health, Info tab.

Switching host or moving to a recent PHP version cuts server response time. It removes neither the plugins’ JavaScript, nor the theme’s weight, nor the database queries. It is often the first advice you get, and rarely the one that is enough.

What you can do (without migrating)#

If migrating is not an immediate option, here are the actions ranked by impact:

  1. Server cache

    Install a caching plugin (WP Rocket, LiteSpeed Cache). Impact: -50 to -70% on load time. This is the single most cost-effective measure.

  2. Plugin audit

    Deactivate each plugin one by one and measure the impact. Remove those that load JS on every page for no reason.

  3. WebP images

    Convert all your images to WebP. Use lazy loading. Declare dimensions. Impact: -30 to -50% on page weight.

  4. CDN

    Put Cloudflare in front of your site (free plan). Static files are served from the server closest to the visitor.

Fig. 1 — The 4 WordPress optimisation steps, ranked by impact.

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.

What slowness costs you#

The numbers are not abstract:

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:

  1. Live with it — and accept that your site will always be slower than competitors who made a different technical choice
  2. 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. It is the method we applied to Marrakech City Guide, a WordPress site put back online on Astro in July 2026.

Frequently asked questions#

How do I know if my WordPress site is slow?

Paste your home page address into PageSpeed Insights and look at the field data at the top: it measures what your real visitors experience. The Core Web Vitals report in Search Console gives the same information for the whole site. The three metrics are explained in our Core Web Vitals guide.

Which caching plugin should I choose?

LiteSpeed Cache if your host runs LiteSpeed: its page cache only works on those servers. WP Rocket otherwise. One caching plugin at a time: two will get in each other's way.

How many plugins is too many?

The number matters less than what each one loads. A single plugin adding its JavaScript to every page costs more than ten discreet ones. Deactivate them one by one, measuring each time: it is the only way to find the culprit.

Is switching host enough?

It cuts server response time, which matters. But it does not touch the plugins' JavaScript, the theme's weight or the images. On a heavy site, a better host gains a few points, rarely enough to turn green.

Is WordPress slow by nature?

Not necessarily. A lean WordPress site, with few plugins, a simple theme, a good host and a well-tuned cache can be fast. But by default it rebuilds every page on every visit and piles up extensions: the market median score is 43 out of 100.

Do I need to migrate to get a fast site?

Not always. If optimisation takes you above 90 on PageSpeed, keep WordPress. If you plateau below 60 despite caching, a plugin audit and image work, the problem is the architecture: the migration guide explains how to get out without losing your rankings.


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. And if you would rather we handle it: our WordPress migration service.

Reading is good. Building is better.