How to speed up a WordPress site: the fixes that actually work

Most slow WordPress sites are slow for one or two reasons, and you can find them in half an hour. Measure first. Then work through the usual causes in order of impact: hosting and PHP version, page caching, images, heavy plugins and themes, and finally the database and background tasks. Fix the first one that applies before touching the next. A caching plugin cannot rescue a page that ships 6 MB of images.

This is the order we follow when a slow WordPress site reaches us, whether as a fix-up or as part of website design and development. It is also the cheapest order, because the first fixes are settings and the later ones are rebuilds.

How do you find out what is actually slow?

Run your homepage and one important inner page through PageSpeed Insights on mobile. Look at two things before anything else.

Field data. The top section shows real visitors' Core Web Vitals from the Chrome UX Report, if your site has enough traffic. Google's thresholds for a good experience are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less. Our Core Web Vitals calculator shows which of your numbers pass. If field data already passes, further work is for visitors and conversion, not rankings.

Server response time. Check Time to First Byte, either in the lab diagnostics or in Chrome DevTools, where the Timing tab for the page request shows "Waiting for server response". Google's guidance on TTFB treats 0.8 seconds or less as good. A slow first byte means the server is slow to build the page: hosting, a missing page cache, or slow PHP and database work. A fast first byte with a slow LCP means the page itself is heavy: images, CSS, JavaScript and fonts.

That split tells you which half of this guide to read. For slow server work, install the free Query Monitor plugin on a staging copy. It lists database queries, slow hooks and which plugin each comes from, for every page load.

Is your hosting holding the site back?

Hosting sets the floor. On crowded shared hosting, an uncached WordPress page can take more than a second to start arriving, and nothing you do inside WordPress changes that. The signs are a slow first byte on every page, including simple ones, and timings that vary wildly between runs.

Check three things in your hosting panel:

• PHP version. As of October 2026, WordPress.org recommends PHP 8.3 or newer. Newer PHP is faster, and old versions are a security risk. Test the switch on staging first.
• Server-level caching. Managed WordPress hosts cache pages at the server, before PHP runs. If yours does, you do not need a caching plugin, and adding one can conflict with it.
• Location. A server in the US serving visitors in India adds delay to every uncached request. A CDN fixes static files; the HTML still comes from the origin unless the CDN caches pages too.

If the host is the problem, moving to managed WordPress hosting is often the single biggest improvement you can buy. As of October 2026, expect ₹1,500 to ₹4,000 a month in India or $20 to $50 elsewhere for one business site. Where to host a WordPress site compares the options.

What does page caching fix, and how do you set it up?

WordPress builds each page from PHP and the database on every request. A page cache stores the finished HTML and serves it directly, so the first byte arrives in tens of milliseconds instead of hundreds. For a company site where most visitors are not logged in, this is the largest single software fix.

Use one caching layer, not three:

• If your host caches at the server, use that, with its purge button or companion plugin.
• On a LiteSpeed server, use the LiteSpeed Cache plugin, which controls the server's own cache.
• Otherwise, one page-cache plugin such as WP Super Cache, W3 Total Cache or the paid WP Rocket.

Exclude pages that must stay personal: cart, checkout, account and anything behind a login. Purge the cache when you publish. Logged-in users and shoppers with items in the cart bypass the page cache, and that is where a persistent object cache helps. Redis or Memcached, usually offered by managed hosts, keeps database results in memory between requests.

Caching plugins add define( 'WP_CACHE', true ); to wp-config.php themselves. That constant only tells WordPress to load the plugin's cache file. It does nothing on its own.

How much do images slow WordPress down?

On most slow sites, images are the heaviest part of the page and the usual cause of a poor LCP. WordPress creates several resized copies of each upload and adds srcset, so browsers pick a sensible size. It cannot fix a 5 MB camera photo used as a full-width banner.

Resize before upload. A full-width hero rarely needs to be wider than 2,000 pixels. Compress it before it goes in; our image compressor does it in the browser.

Use WebP or AVIF. WordPress has accepted WebP uploads since version 5.8 and AVIF since 6.5. Convert existing images with the WebP converter, or have WordPress save the resized copies of JPEG uploads as WebP with the image_editor_output_format filter, as shown in its reference entry:

add_filter( 'image_editor_output_format', function ( $formats ) {
	$formats['image/jpeg'] = 'image/webp';
	return $formats;
} );

Put it in a small site plugin rather than the theme's functions.php, so it survives a theme change. Check first that the server's image library supports WebP: Tools → Site Health → Info → Media Handling lists the supported formats.

Do not lazy-load the hero. WordPress adds loading="lazy" to images automatically, skips it for the first large image, and since 6.3 adds fetchpriority="high" to the image it expects to be the LCP element. Page builders and sliders often defeat this by setting the hero as a CSS background. PageSpeed Insights names the LCP element; if it is a background image or lazy-loaded, fix the template. Image SEO covers sizes and formats in more detail.

Which plugins and themes cost the most speed?

The ones that add code to every page. A form plugin that loads its scripts on all 40 pages when the form is on one. A homepage slider that ships 200 KB of JavaScript. Social feeds, chat widgets, popup builders and all-in-one toolkits that load everything everywhere. And page builders, which add their own CSS, JavaScript, icon fonts and layers of wrapper elements around every piece of content.

To find them, open a page in Chrome DevTools, go to the Network tab, reload and sort by size. The file paths tell you the source: /wp-content/plugins/plugin-name/ for plugins, /wp-content/themes/theme-name/ for the theme. Then deactivate the suspect on staging and measure again.

Fixes, cheapest first:

• Load plugin files only on pages that use them. Many plugins have a setting for it; otherwise a developer can dequeue the files on other pages.
• Replace a heavy plugin with a lighter one that does the same job.
• Remove what nobody uses. How many WordPress plugins is too many has an audit method.

If a page builder is the main weight, is Elementor slowing your site down shows how to measure it. Sometimes the honest answer is that the theme is the problem. A multipurpose theme with a bundled builder, a slider and a dozen required plugins cannot be tuned into a fast site. Rebuilding the key templates on a light block theme often costs less than months of tuning.

What about the database, cron and the smaller fixes?

These matter on older and busier sites, rarely on a new brochure site.

Revisions. WordPress keeps every saved revision of every post. Years of edits bloat the posts table. Cap them in wp-config.php; this limits future revisions and does not delete old ones:

define( 'WP_POST_REVISIONS', 10 );

Leftover options. Plugins store settings in the options table, and some are loaded on every request. Plugins you removed often leave theirs behind. Site Health warns when the autoloaded total grows large.

WP-Cron. WordPress runs scheduled tasks when someone visits a page. On a busy site that adds work to page loads; on a quiet site, tasks run late. The documented fix is to switch off the visitor-triggered cron and run it from the server's scheduler instead:

define( 'DISABLE_WP_CRON', true );

Then add a system cron job, for example every 15 minutes:

*/15 * * * * wget -q --delete-after https://example.com/wp-cron.php

Do this only if you can manage server cron jobs and will remember it exists. A missing cron job stops scheduled posts, emails and backups. Both constants are listed in the wp-config.php documentation.

Speculative loading. Since WordPress 6.8, core prefetches a page when a visitor starts to click a link, which makes the next page feel faster at no cost. Leave it on.

When is speed work not worth it?

When field data already passes and the site's job does not depend on speed. A 12-page company site with green Core Web Vitals gains little from shaving another 200 milliseconds. Spend that time on content, or on the other items in our technical SEO checklist.

It is also not worth patching a site whose problems are structural. If the theme, builder and plugins together ship several megabytes per page, every fix fights the foundation. Do the cheap fixes first (hosting, caching, images), measure again, and if the result is still poor, price a rebuild of the main templates before buying another optimisation plugin. Our WordPress for business guide describes the setup we use so a site does not end up there.