A slow WordPress site drives visitors away and hurts search rankings. Before rewriting anything or switching themes, it is better to measure where time is actually lost: in the vast majority of cases, the problem comes from one of the five causes below. For each one, here is how to spot it and fix it.
Start by measuring
Two figures are enough to guide the diagnosis:
- Server response time (TTFB): if it is high, the problem is on the server side (hosting, plugins, database). It takes one command to measure:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer} s\n" https://your-site.com/- The PageSpeed Insights report on mobile: it shows what weighs on the browser side (images, scripts, fonts).
On a copy of the site, the Query Monitor plugin then details SQL queries and the time spent by each plugin.
1. Undersized shared hosting
On low-end shared hosting, your site shares the processor and memory with dozens of others. A simple test is to measure the response time of a static HTML page, without WordPress: if it already exceeds 300 to 400 ms, the problem is at the source, before WordPress even starts.
- Check the PHP version: a recent PHP 8 release is noticeably faster than older ones, and WordPress supports it.
- Check that OPcache is enabled: it avoids recompiling PHP on every visit.
- If the site gets regular traffic or runs a WooCommerce store, better-sized hosting (a VPS or premium shared hosting) is often the most cost-effective gain.
2. Too many plugins, or badly written ones
Every active plugin adds queries, JavaScript and sometimes calls to external services. What matters is not the number of plugins but their quality: two or three poorly written plugins do more damage than fifteen well-coded ones.
- In Query Monitor, the queries-by-component view shows which plugins hit the database the most.
- Watch out for plugins that load their scripts and styles on every page while they are only used on one (a contact form, a slider).
- On a copy of the site, deactivate plugins one by one while measuring response time: the culprit shows up quickly.
3. Images that are too heavy
A 4 MB photo displayed 600 pixels wide wastes bandwidth for nothing.
- Resize images before uploading them, or automatically on upload: WordPress generates several sizes, but the theme still has to use the right one.
- Compress them and serve them as WebP, which WordPress accepts natively.
- Keep WordPress’s native lazy loading for images further down the page, but not for the large image at the top, which must show right away.
- Set image width and height, so the page does not “jump” while loading.
4. No caching at all
Without caching, WordPress rebuilds every page on every visit: it queries the database, runs the PHP and assembles the HTML. Several layers work together:
- a page cache (at server level or through a plugin such as WP Rocket) serves a page that is already built: this is the most visible gain;
- an object cache (Redis, for example) speeds up pages that cannot be cached whole, such as a store’s cart or a members area;
- a CDN such as Cloudflare serves images and static files from a server close to the visitor.
On a WooCommerce store, the cart, checkout and customer account must be excluded from the page cache, otherwise customers would see someone else’s cart.
5. A database that grew without maintenance
Over the years, the database accumulates post revisions, expired transients and settings left behind by uninstalled plugins. Some of these settings are loaded on every page: these are the “autoload” options. To see the heaviest ones:
SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')
ORDER BY size DESC
LIMIT 10;- Limit the number of revisions kept per post, in
wp-config.php:define( 'WP_POST_REVISIONS', 5 ); - Delete expired transients, for example with WP-CLI:
wp transient delete --expired - Remove options and tables left by uninstalled plugins, after checking what they are used for.
Any database clean-up must come after a verified backup: see the backup rule almost nobody follows.
In which order to fix things
Deal with the causes in this order: hosting, caching, images, plugins, database. Fixing plugins before having decent hosting, for example, gives disappointing results and wastes time. And measure again after each step, to know what actually made a difference.
The checklist
- Measure server response time and the mobile PageSpeed score.
- Recent PHP 8, OPcache enabled, hosting sized for the traffic.
- Page cache on, with the right exclusions for WooCommerce.
- Images resized, compressed, in WebP, with width and height.
- Unused plugins removed, slow plugins identified and replaced.
- Revisions limited, transients and orphaned options cleaned, after a backup.
- Measure again.
Going further: my expertise: Freelance WordPress developer · read also: WordPress or an all-in-one builder: which one for a professional website?
