Skip to content
CWV Checker

WordPress speed test

Free, no signup, no ads. We keep nothing except the shareable result, for 30 days.

Enter any public URL. You’ll get the one change that recovers the most load time, what it’s worth, and the measurements underneath.

What actually makes WordPress sites slow

WordPress performance problems are unusually predictable. The same handful of causes account for most of them, and they are nearly all configuration rather than code.

No page cache, or a page cache that is silently off

Without one, every visit boots PHP, queries MySQL and renders the theme. This is the single biggest cause of a slow first byte on WordPress, and the most common way it breaks is not being missing but being bypassed: a plugin setting a cookie on every request, a no-store header from a security plugin, or an exclusion rule that matches more than intended. Check with curl -I https://yoursite.com/ and look for a cache hit header.

Uploads served at full camera resolution

WordPress generates resized copies, but themes and builders often output the original anyway, and the media library is full of 4000px JPEGs straight off a phone. A hero image arriving as 2 MB is routine and is frequently the whole of a bad LCP.

Lazy-loading applied to the hero image

WordPress adds loading="lazy" automatically, and optimisation plugins often extend it to background images too. Applied to the LCP element it makes things measurably worse. Every serious performance plugin has an “exclude the first N images” setting; set it to 1 or 2.

Autoloaded options bloat

Every page load reads the entire autoloaded options table. Plugins that were removed without cleaning up — especially page builders and sliders — leave megabytes of serialised data behind that gets read on every single request:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options WHERE autoload = 'yes'
ORDER BY size DESC LIMIT 20;

Anything over a few hundred kilobytes there is worth investigating.

Theme and plugin assets loading everywhere

Contact Form 7 loading on every page, a slider plugin’s bundle on pages with no slider, Font Awesome loaded in full for three icons, Google Fonts pulled from Google’s servers with a render-blocking stylesheet. Conditional dequeuing removes real weight and is the least glamorous, most reliable WordPress optimisation there is.

admin-ajax and the heartbeat

The WordPress heartbeat polls admin-ajax.php on a timer, and WooCommerce cart fragments do the same on every page. On shared hosting these requests compete with real page loads for the same PHP workers.

Shared hosting that is oversubscribed

The tell is a first byte that is fine when you test at night and terrible at 2pm. Work through caching and a CDN first — they fix most of it, and they are free. This checker only raises hosting when your measured server response is over 600ms.

A sensible order to work in

  1. Confirm the page cache is actually serving cached pages.
  2. Fix the LCP image: correct size, WebP or AVIF, not lazy-loaded.
  3. Dequeue plugin assets from pages that do not use them.
  4. Self-host fonts, with font-display: swap.
  5. Defer non-critical JavaScript, tag manager included.
  6. Clean the autoloaded options table.
  7. Only then consider a different host.

Common questions

Which WordPress caching plugin is fastest?
The difference between the good ones is much smaller than the difference between having one and not having one. WP Rocket, LiteSpeed Cache (only useful on LiteSpeed servers) and FlyingPress all do the job. If your host has server-level page caching, use that instead of a plugin — it serves the page without starting PHP at all.
Will deactivating plugins make my site faster?
Only the ones that load assets on the front end, and it depends entirely on which. Twenty plugins that run in the admin cost your visitors nothing. Two plugins that each enqueue jQuery UI and a 300 KB stylesheet on every page cost a lot. Use Query Monitor or a plugin-profiling tool to find which ones actually add front-end weight.
Do I have to stop using Elementor or Divi?
No, but you do have to work harder. Page builders generate deeply nested markup and load a large CSS and JS bundle regardless of what the page contains. Turn on whatever asset-optimisation settings the builder offers, disable the icon and font libraries you never use, and keep the DOM shallow. A builder site can pass; it just does not pass by accident.
Why is my WooCommerce shop slower than the rest of the site?
Cart pages cannot be page-cached, so every request runs PHP and hits the database. WooCommerce also loads cart fragments over admin-ajax on every page by default, including pages with no cart on them. Restricting cart fragments to pages that actually need them is a common and substantial win.