The quickest way to speed up a WordPress website is rarely another plugin. The usual problem is what has piled up on top of WordPress: a theme loading features nobody uses, plugins putting scripts on every page, oversized photos, bargain hosting and two caching tools that disagree.
Most of it can be fixed on the site you have. The risk is in how: tick every box in an all-in-one optimisation plugin and menus stop opening, forms stop sending, and the lab score can rise while real visitors get a worse site.
Not sure where the time goes yet? Start with why is my website slow?; the principles behind each step are in the website speed optimisation guide.
How to speed up a WordPress website: the short answer
Work in this order, testing after each step:
- Copy the site to staging and record a baseline.
- Run a supported PHP version and update WordPress, the theme and plugins.
- Audit plugins by what they load, not by how many there are.
- Use one page cache, add object caching for shops, and never stack optimisation plugins.
- Let WordPress core handle images and speculative loading.
- Tune the page builder and theme, and clean the database.
- Treat WooCommerce separately, because cart, checkout and account pages can’t be page-cached.
Still slow after all seven? The theme or builder is probably the ceiling.
Step 1: Work on a staging copy, with a baseline
Staging is a private copy of your site, ideally on the same hosting, where changes can break unseen. Take a full backup first, store it off the server and check it restores.
Then record a baseline for one page per template: the homepage, a service or product page, a blog post and, for shops, a category page and the cart. Test logged out, since logged-in users usually bypass the cache.
| Measure | Where to find it | What it tells you |
|---|---|---|
| Core Web Vitals, real visits | Search Console or PageSpeed Insights | Whether visitors have a problem |
| Lab Largest Contentful Paint (LCP) and Total Blocking Time | PageSpeed Insights, mobile, three runs | Whether a change helped |
| Server response time (TTFB) | Chrome DevTools, Network panel | How long the server takes |
| Queries and generation time | The free Query Monitor plugin | Which plugins keep the server busy |
Core Web Vitals explained covers Google’s “good” thresholds. Staging often lacks the live cache or CDN, so compare like with like.
Step 2: Update PHP, WordPress and everything else
Every page not served from cache is built by PHP, and newer versions are generally faster and still get security fixes. At the time of writing (July 2026), php.net lists everything older than PHP 8.2 as end of life, and 8.2 itself gets security fixes only until 31 December 2026. WordPress.org recommends PHP 8.3 or greater, so if you’re on 8.2 or older, plan the move now.
Check it yourself. Tools → Site Health → Info → Server shows your PHP version; most hosting panels let you change it per site.
Do it safely. Switch staging first, click through key pages, submit every form and place a test order if you sell online. A plugin that breaks and hasn’t been updated in years should go. Ask your host to confirm OPcache, which keeps compiled PHP in memory, is on.
Then update core, the theme and plugins, staging first. A theme edited directly, so nobody dares update it, needs fixing first; WordPress best practices explains child themes.
Step 3: Audit plugins by what they load, not how many there are
“Too many plugins” is common WordPress speed optimisation advice, but a feature-packed SEO plugin can cost visitors less than one slider. What matters is what each plugin does on each request:
| Where it costs | Typical examples | What it slows down |
|---|---|---|
| Files sent to visitors | Sliders, pop-ups, form builders, social feeds | Loading and responsiveness (LCP, INP), especially on phones |
| Server work per page view | Live “related posts” queries, visit statistics | TTFB on pages not served from cache |
| Background work | Scheduled scans, broken-link checkers | The dashboard, and server load |
Check it yourself. Logged out, open a key page, type /plugins/ into the filter box of the DevTools Network panel and reload; each file’s path names its plugin. Repeat on a page that doesn’t use the feature: form files on a blog post are a candidate for restricting.
For each plugin:
- Remove what nobody uses. Delete it rather than deactivating it: a deactivated plugin’s code stays on the server and still needs updates.
- Replace heavy tools with lighter ones, or with nothing. A homepage slider often works better as one strong image.
- Restrict the rest to the pages that need them, via plugin settings or a developer, and test: a script removed from the wrong page breaks things silently.
Step 4: Set up caching once, in the right layer
Caching is usually the biggest single win on a WordPress site, and a common source of self-inflicted bugs. Website caching and CDNs explained covers every layer; two matter most here:
- Page caching stores finished HTML so pages aren’t rebuilt for every visitor. Use one page cache, your host’s or a plugin’s, unless your host says the two are designed to work together.
- Object caching (Redis or Memcached) keeps database results in memory. It helps what can’t be cached whole: the dashboard, logged-in users, baskets and checkouts.
Check it yourself. In DevTools, select the page request and read its response headers; many hosts, plugins and CDNs add one showing HIT or MISS. Load the page twice, logged out. Still a MISS? Page caching isn’t working. Server response still slow on a HIT? The bottleneck is hosting or network, and how to choose web hosting for speed is your next read.
Don’t stack optimisation plugins
Caching plugins often bundle extras: minifying, combining files, removing unused CSS, lazy loading, delaying JavaScript. Run two, or one alongside your host’s tools and your builder’s settings, and files get processed twice: layouts break only for logged-out visitors and forms fail silently.
Test the riskiest individually:
- Delay JavaScript until interaction can flatter lab scores, but the scripts then load on the first tap, slowing it and sometimes breaking menus, cookie banners and analytics.
- Remove unused CSS can strip styles for menus, pop-ups and tabs that appear only after a click.
- Combine files helps far less over HTTP/2 and HTTP/3 than it used to.
Clear every cache after each change, retest, and note what you switched on.
Step 5: Let WordPress core handle images and speculative loading
Images
For media library images, WordPress creates several sizes with srcset so phones download smaller files, sets width and height, lazy-loads images lower on the page and, by default, scales photos larger than 2,560 pixels down to that size. Since version 6.3 it also adds fetchpriority="high" to the image it judges most likely to be the LCP element. Three things commonly undo this:
- Hero images set as CSS backgrounds, a page-builder habit: the browser finds them late and WordPress’s handling doesn’t apply. Use an ordinary image where you can.
- A second lazy-loading plugin, which can lazy-load the main image and push back LCP.
- Templates requesting the full size, so a 2,560-pixel photo fills a 400-pixel card.
Image optimisation for websites covers formats, sizing and uploads.
Speculative loading
Since WordPress 6.8, core adds speculation rules that let supporting browsers start fetching the next page as a visitor presses down on a link. Chromium-based browsers such as Chrome and Edge act on them; others simply ignore them, so nothing breaks. It runs only for logged-out visitors on sites with pretty permalinks, and skips any URL with a query string, which keeps it away from add-to-cart links.
Check it yourself. Logged out, view the page source and search for speculationrules. Missing? Check that Settings → Permalinks isn’t set to “Plain”. If an optimisation plugin also prefetches links, keep one system, not two.
Step 6: Tune the page builder, theme and database
Page builder and theme settings
Elementor and Breakdance both have performance settings. At the time of writing:
- Elementor’s Performance tab includes optimised image loading, loading Google Fonts from your own server, and element caching.
- Breakdance’s Performance tab can stop WordPress loading block editor styles, the emoji script and, for logged-out visitors, Dashicons. Only drop block styles if no content uses blocks; blog posts often do.
How pages are built matters as much. Deeply nested sections bloat the page’s structure (the DOM), making phones work harder on layout and every tap; in Elementor, flexbox containers generally produce less markup than the older sections and columns.
Multipurpose themes often ship sliders, icon fonts and Google Fonts in many weights. Switch off unused modules and keep to two font families in two or three weights.
Clean the database, carefully
Years of use leave revisions, expired transients, spam and deleted plugins’ settings. Autoloaded options matter most, because WordPress loads them on every uncached request; since version 6.6, Site Health warns when their total passes 800 KB. Back up first, then:
WooCommerce: why stores are harder to keep fast
A brochure site can serve almost every visitor a cached page. A store can’t, so WooCommerce speed needs its own plan alongside the design choices in e-commerce website design.
Cart, checkout and My Account can’t be page-cached, because each shows one person’s data. Their speed rests on PHP, the database, object caching and hosting, so Steps 2 and 4 pay off most here.
Personalised pieces weaken caching elsewhere. Since version 7.8, WooCommerce loads its cart fragments script only where its mini-cart widget appears, but many themes put a mini-cart in every header, which can add an uncached background request to page views. The “Geolocate (with page caching support)” setting redirects new visitors to URLs with a v= string, splitting the cache; if prices and taxes don’t vary by location, a fixed default customer location avoids it.
Product galleries are heavy: zoom, lightbox and slider scripts plus several large photos. Size images for their space, lazy-load all but the first, and run one gallery system, not two.
Filters create slow queries and endless URLs. Combined attribute, price and stock filters run heavy database queries, and every combination is a new, rarely cached URL that crawlers can wander through. Offer only the filters shoppers use.
Store apps add scripts. Review widgets, upsell pop-ups and pixels often load everywhere; ask whether each earns its weight in sales. Third-party scripts and website speed covers the audit.
When the theme or builder is the real ceiling
Page builders aren’t the villain. One set up with global styles and sensible settings can be fast: the property developer site we rebuilt runs on Breakdance and went from a nine-second load to two. But builders do send more markup, CSS and JavaScript than a lean hand-built theme, and every add-on pack adds more.
You have probably hit the ceiling when:
- Uncached TTFB stays slow on good hosting, with object caching on and plugins trimmed
- PageSpeed Insights still flags a very large DOM, or unused CSS and JavaScript from the theme or builder
- Gains vanish within months as editors add pages the same way
The fix then is rebuilding the templates, sometimes only the heaviest few, not more optimisation. If speed is one of several problems, these signs your website needs a redesign help you weigh it up.
What to do next
A faster WordPress site slows down again one plugin, photo and update at a time, so the gains last only if someone keeps watching. Our website care plans keep core, theme and plugins updated, with regular backups and monitoring; the Growth plan adds monthly improvements and speed work.
Want to know where your site loses time before anyone touches it? Ask for a free website audit, mentioning your theme or builder and whether you run WooCommerce.