To speed up WordPress safely, fix the server side first (hosting, PHP and page caching), then images, plugins and the database, and only then touch CSS and JavaScript delivery, testing one change at a time on staging.
By Kristijan GjorgjioskiIndependent SEO consultantPublished 18 October 2026 · 8 min read
Most guides on how to speed up WordPress hand you 25 tweaks in random order.
That's how sites end up with a broken mobile menu and a contact form that silently stops sending.
Order matters more than the tweaks. Here's the sequence I use on client sites: server first, then the things that are safe to change, then the risky front-end settings last.
Speed work on WordPress changes settings that touch every page.
So set yourself up to undo things before you change anything.
You need:
Warning: Never change caching, minify and script settings on a live site during business hours. If a checkout or booking form breaks, you may not hear about it for days.
Speed problems on WordPress live in templates, so test one URL per template, not just the homepage.
Pick:
Run each through PageSpeed Insights on mobile. Write down the LCP, INP and CLS figures, plus the largest element PageSpeed names for LCP.
Then note what each page is made of.
Which theme? Which builder? Which plugins add something visible, like a slider, a chat widget or a cookie banner?
That inventory becomes your to-do list.
If you want the metric-by-metric diagnosis behind it, my guide to improving Core Web Vitals covers it. This guide sticks to what's specific to WordPress.
Your server's response time is the floor. Nothing on the page can render before the first byte of HTML arrives.
Start with the PHP version. WordPress.org's requirements page currently recommends PHP 8.3 or greater.
Open Tools → Site Health and look at the Status tab. An outdated PHP version shows up there as a critical issue.
Ask your host to upgrade, then test your key pages.
Old plugins sometimes fail on newer PHP, which is exactly why you have staging.
Next, look at the hosting plan itself. The WordPress.org optimisation guide suggests moving to SSD or NVMe storage, a plan with higher resource limits, and an opcode cache such as OPcache.
On cheap shared hosting, you often can't get those.
That's when I tell clients plainly that no plugin will close the gap. If you're weighing a move anyway, my website migration checklist covers what to protect when you switch hosts.
Pro tip: Site Health has had a page cache check since WordPress 6.1. It runs in production only, and it flags a server response time above 600 milliseconds by default. It's a free, quick sanity check on your host.
Page caching saves a finished copy of each page, so WordPress doesn't rebuild it with PHP and database queries for every visitor.
For most WordPress sites, it's the biggest single speed gain available.
First, find out what you already have. Many managed hosts cache pages at server level.
Adding a caching plugin on top can double up the work or serve stale pages.
If nothing caches your pages, install one well-maintained caching plugin. Just one.
Two details catch people out:
WP_CACHE constant isn't a switch. WordPress's wp-config documentation says it does not enable caching by itself and has little effect without an advanced-cache.php drop-in, which caching plugins create.Then consider object caching.
Site Health may suggest a persistent object cache, such as Redis or Memcached, once your site has enough data. It needs support from your host, so ask before you install anything.
Images are usually the heaviest thing on the page, and WordPress already does more for them than most people realise.
Since version 6.3, core adds fetchpriority="high" to the image it predicts will be the largest in the viewport. According to the WordPress 6.3 image performance notes, it also never puts lazy loading and high priority on the same image.
The catch? That logic only sees images rendered through core functions.
Hero sliders, builder background images and images printed by a theme's custom code often slip past it.
In my audits, that's where the classic mistake appears: a plugin lazy-loads the main image above the fold, so it starts downloading late.
Here's how to fix it:
loading="lazy".Then fix file sizes.
Since WordPress 5.3, core scales down uploads wider or taller than 2,560 pixels and uses the scaled copy as the largest size. That stops the worst camera uploads.
But a 2,560-pixel image is still far bigger than most layouts need. Compress your images before upload, and use WebP where your setup supports it.
Every plugin that adds code to the front end costs you something on every page it touches.
The WordPress.org optimisation guide gives the blunt version: deactivate and delete plugins you don't need, then disable the rest one at a time to find the slow ones.
I do it in a spreadsheet instead of by trial and error:
| Column | What to record |
|---|---|
| Plugin | Name and version |
| Front-end output | Scripts, styles or HTML it adds |
| Where it's needed | All pages, a few pages, or admin only |
| Overlap | Anything else doing the same job |
| Decision | Keep, restrict to certain pages, replace or remove |
A free tool like Query Monitor shows which scripts and styles each page loads, and which database queries are slow.
The usual offenders are sliders, social feeds, form plugins and chat widgets that load site-wide but appear on one page.
Many can be restricted to the pages that use them.
Page builders are harder. You can't remove one without rebuilding pages.
So look for the builder's own performance settings, such as loading only the widgets a page uses. If the builder is the main problem, that's a redesign decision, not a tweak, and my guide to redesigning without losing SEO is the place to start.
Inactive plugins don't slow the front end, but they're a security risk. Delete them while you're here.
One warning: if you're replacing an SEO plugin to save weight, crawl your titles and canonicals before and after. My Yoast vs Rank Math comparison covers what each one outputs.
A database that's grown for years slows down every uncached request, including the admin, logged-in users and anything your page cache skips.
Start with autoloaded options.
These are settings WordPress loads on every single request, whether the page needs them or not.
According to the WordPress 6.6 options API note, Site Health now shows a critical issue when autoloaded options pass 800 KB. The same release stopped autoloading new large options over 150 KB by default.
Old plugins are the usual cause.
They leave settings behind after you delete them, still marked to load everywhere.
Next, revisions. WordPress keeps every saved version of a post unless you limit it.
Adding WP_POST_REVISIONS to wp-config.php with a number, such as 5, caps how many it stores per post.
Then clear the rest of the clutter:
Note: Back up the database before any clean-up. Deleting the wrong option can break a plugin's settings, and there's no undo button.
This is the step that breaks sites, which is why it comes last.
Caching and speed plugins offer settings like minify, combine, defer, delay JavaScript until interaction and remove unused CSS.
Each can help. Each can also break a menu, a slider, a cookie banner or a form.
Here's the safe way to do it:
One newer core feature is worth knowing about.
Since WordPress 6.8, core prefetches a page when a logged-out visitor starts clicking a link to it, using conservative settings, and skips URLs with query strings.
You don't need a plugin for that anymore, so check you're not running two prefetching tools.
These are the ones I see most:
If your site runs a shop, the store layer adds its own slow spots, from basket cookies to product images. I cover those separately in my guide to WooCommerce speed optimisation.
Start with the server. Check your PHP version in Site Health today, then confirm with your host whether pages are cached.
Those two answers usually explain more of a slow WordPress site than any plugin setting.
Still deciding whether WordPress is the right platform at all? My Webflow vs WordPress comparison covers how speed differs between the two.
After that, work down the steps in order, re-testing the same template URLs each time. Speed is only one part of the picture, so run the WordPress SEO checklist alongside it. Deeper server and template problems belong in a wider technical SEO review.
And if you'd rather not risk breaking anything yourself, speed and hosting are part of my WordPress SEO work. I measure your real templates, change one layer at a time on staging, and hand your developer tickets for the rest. You can read more about how I handle plugins, caching and database clean-up before deciding.
In the WordPress sites I audit, the biggest causes are slow hosting without page caching, page builders that load heavy scripts on every page, plugins that add front-end code site-wide and oversized images. Database bloat matters on older sites. Each one has a different fix, so measure first instead of installing another speed plugin and hoping.
You need page caching, but not always a plugin. Many managed WordPress hosts cache pages at server level, and adding a plugin on top can create conflicts. Ask your host what they already do. If nothing caches your pages, a well-maintained caching plugin is usually the single biggest speed gain for a WordPress site.
There is no safe number. One badly built plugin that loads scripts on every page can cost more than twenty light ones that only run in the admin. Judge each plugin by what it adds to the front end and whether something else already does the same job, rather than by the total count.
Speed alone rarely moves rankings much. Google's Core Web Vitals reward good page experience, but relevance and content still decide most positions. The clearer gain is in behaviour: faster pages lose fewer mobile visitors before they read or enquire. Treat speed as a conversion fix that also supports SEO, not a ranking shortcut.
About the author
Kristijan Gjorgjioski
Independent SEO consultant · 6+ years in SEO · 60+ client websites worked on
I'm an independent SEO consultant with 6+ years in SEO. I run audits, migrations and content programmes for businesses in Europe, the UK and the USA, and I build the automation behind my own research.
Book a free 30-minute call. I look at your site first and tell you plainly what I would fix, and in what order.