# How to speed up a WordPress site: 11 steps in the order that pays off

> Speed up a WordPress site step by step: measure first, then fix the server and page cache, PHP, plugins, the builder, images, scripts, fonts and background jobs, re-testing after each change.

Updated 2026-09-26 · WordPress & WooCommerce · HTML version: https://getreport.app/guides/speed-up-wordpress-site

To speed up a WordPress site, fix things in this order: make the server answer quickly with one page cache and a current PHP version, remove or restrict the heaviest plugins and page-builder code, resize the images, delay the scripts the first screen does not need, and move background jobs out of visitors' requests. Re-test after every step. Most slow WordPress sites get most of their speed back from the first four steps, without paying for anything.

This guide is the hands-on checklist for site owners and the people who look after WordPress for them. If you first want to know *why* your site is slow, [why is my WordPress site so slow?](https://getreport.app/guides/why-is-my-wordpress-site-so-slow) diagnoses the five usual causes; for page speed in general, see the [page speed guide](https://getreport.app/guides/page-speed).

## Quick answer

1. **Measure first**, logged out, on three templates, three runs each. Keep the report links.
2. **One page cache,** host-level if your host has one, otherwise a single caching plugin. Never two.
3. **Current PHP with OPcache,** and an object cache if the host offers Redis or Memcached.
4. **Remove, replace or restrict the heaviest plugins,** by what they load, not by how many there are.
5. **Turn on the page builder's performance settings** or use the block editor for new pages.
6. **Resize and convert images;** never lazy-load the hero image.
7. **Defer and delay JavaScript,** one setting at a time, and test the menus and forms after each.
8. **Two font families at most,** self-hosted, with `font-display: swap`.
9. **Move wp-cron to a real cron** and trim autoloaded options.
10. **Add a CDN** if visitors are far from the server.
11. **Change host last,** when a lean, cached site is still slow.

## Before you start: measure

Speeding up WordPress without a baseline is guesswork. Pick three pages that carry your traffic, usually the home page, one post or product and one category or landing page, and test each in a private window so the page cache is not bypassed for a logged-in user.

> **Free tool:** [Free website speed test and page speed check](https://getreport.app/tools/speed-test): Free website speed test for any page: Lighthouse lab results and real-user Core Web Vitals on mobile and desktop, with a fix for each slow part. No sign-up.

The speed test runs Lighthouse through Google's PageSpeed Insights on mobile and desktop and shows real-visitor Core Web Vitals beside it. Note the time to first byte (TTFB), the Largest Contentful Paint (LCP), the total blocking time and the LCP element for each page. Run each test three times; single runs vary.

Then see which plugins the page loads and what each one costs:

> **Free tool:** [WordPress theme and plugin detector](https://getreport.app/tools/wordpress-plugin-checker): Free WordPress theme and plugin detector: see the theme, page builder and plugins a site uses, what each plugin costs in kilobytes and which are abandoned.

The detector loads the page in Chromium and matches every request to its plugin, so each plugin gets its own kilobytes, requests and load time. Admin-only plugins load nothing on the front end and do not appear. Take a backup or work on a staging copy before changing anything.

## Step 1: find out whether the server is the problem

Everything waits for the server's first byte. Look at the TTFB of the second or third run of a page that should be cached, such as the home page:

- **Under 300 ms:** the server and cache are fine. Skip to step 4.
- **300–800 ms:** there is room to gain from steps 2 and 3.
- **Over 800 ms on every run:** there is probably no working page cache, or the host is overloaded.

> **Free tool:** [Web hosting speed test: is your host slow?](https://getreport.app/tools/hosting-speed-check): Free web hosting speed test: see who hosts a site, how fast its server sends the first byte, and how that compares with other sites on the same host.

The hosting speed check names the host behind the site and, once a host has 50 sites in its data, compares your first byte with the median of other sites on the same host. If you are much slower than the host's other sites, the cause is on your site; if you are typical and still slow, the host is the limit.

> **Check: Time to First Byte.** TTFB is how long the server takes to start answering. Everything else waits for it, so a slow first byte makes every other metric worse. Google's 800 ms target is for real visitors, network included; Lighthouse flags the server's own share above 600 ms (see server response time).
>
> 1. Add page caching (WordPress: WP Rocket, LiteSpeed Cache, or your host's cache; Shopify does this for you).
> 2. Put a CDN in front (Cloudflare, Bunny) so the first byte comes from a nearby edge.
> 3. Check database-heavy plugins and slow hosting; a plan with more CPU often fixes this outright.

## Step 2: use exactly one page cache

Without a page cache, WordPress starts PHP, loads every active plugin and runs dozens of database queries for every visitor. A page cache stores the finished HTML and hands it out in milliseconds. It is the single biggest speed-up for most WordPress sites.

Choose one, in this order of preference:

1. **Your host's cache,** if it has one (look in the hosting panel for "cache" or check the response headers for a cache hit header). Server-level caches serve pages before PHP starts.
2. **LiteSpeed Cache,** if the server runs LiteSpeed. The [LiteSpeed Cache settings guide](https://getreport.app/guides/litespeed-cache-settings-for-core-web-vitals) goes tab by tab.
3. **One caching plugin** on Apache or nginx hosts, such as WP Super Cache (free) or WP Rocket (paid). See the [WP Rocket settings guide](https://getreport.app/guides/wp-rocket-settings-for-core-web-vitals).

The settings that matter whichever you use: a cache lifetime of 12 to 24 hours with purge on update, cache preloading if offered, and the default exclusions for cart, checkout and account pages. Then verify it works: load a page twice in a private window and look for a hit header (`x-litespeed-cache: hit`, `x-cache: HIT`, `cf-cache-status: HIT` or the plugin's own), and a much lower TTFB on the second test.

Two caching plugins, or a caching plugin on top of a host cache that is not designed to work with it, is the most common WordPress speed mistake. They double-minify, serve stale pages and purge each other. [Why two caching plugins break things](https://getreport.app/guides/two-caching-plugins-why-it-breaks-and-which-to-keep) shows how to pick the one to keep.

> **Check: One caching layer is active.** Two caching or optimisation plugins fight over the same files: double minification breaks scripts, and stale pages are served from whichever cache wins.
>
> 1. Keep one caching plugin (the one your host recommends) and deactivate the other.
> 2. If the host provides server-side caching, use only its plugin and a separate image optimiser if needed.

## Step 3: current PHP, OPcache and an object cache

Uncached requests (logged-in users, the cart, search results, the admin) still run PHP. Three settings in the hosting panel make them faster:

- **PHP version.** Use the version the [WordPress requirements page](https://wordpress.org/about/requirements/) recommends, 8.3 or newer at the time of writing. Newer PHP is faster, and old versions no longer get security fixes. Switch on staging first and check for errors; switching back is one dropdown.
- **OPcache.** It keeps compiled PHP in memory. It is on by default on nearly every host; Tools → Site Health → Info → Server shows it.
- **Object cache.** If the host offers Redis or Memcached, turn it on (LiteSpeed Cache has an Object Cache tab; the Redis Object Cache plugin works elsewhere). It keeps repeated database results in memory, which helps uncached pages and the admin. If the host does not offer it, skip it.

When the server is still slow after steps 2 and 3, [slow server response time on WordPress](https://getreport.app/guides/wordpress-slow-server-response-time) goes deeper into slow queries, outbound calls and PHP workers.

## Step 4: remove, replace or restrict the heaviest plugins

The number of plugins matters less than what each one loads on every page. A slider plugin that loads 300 KB of JavaScript everywhere, including pages without a slider, costs every visitor.

Work down the plugin detector's table, heaviest first:

1. **Not needed at all?** Delete it. Deactivated plugins load nothing, but deleting them removes clutter and security risk.
2. **Needed, but only on some pages?** Contact forms, sliders, maps and shop add-ons often load everywhere. Use the plugin's own setting to load only where it is used, or an asset manager plugin that unloads scripts per page. Do not add an asset manager on top of a caching plugin that already has the same feature.
3. **Needed everywhere, but heavy?** Look for a lighter alternative that does the same job, and compare with the detector before and after.

The [WordPress plugin cost guide](https://getreport.app/guides/wordpress-plugin-cost) has the full method, including how to measure what an admin-only plugin costs on the server side.

> **Check: WordPress plugin weight.** Every active plugin can add scripts and styles to every page, whether the page uses them or not. A slider or a form builder can weigh more than the rest of the site together.
>
> 1. Deactivate plugins the site does not use; for the heavy ones in the table, check whether a lighter alternative exists.
> 2. Load plugin assets only where needed with a performance plugin (Perfmatters, Asset CleanUp) or the plugin's own "load on demand" setting.

## Step 5: tame the theme and the page builder

Page builders such as Elementor and Divi load their own CSS, JavaScript, icon fonts and animation libraries, and wrap each element in several layers of HTML. That is often the largest share of the code on the page.

- Turn on the builder's performance options (optimised asset loading, inline or per-page CSS, fewer icon libraries). The [Elementor performance guide](https://getreport.app/guides/elementor-performance-asset-loading-fonts-dom) and [Divi performance settings](https://getreport.app/guides/divi-performance-settings) list them.
- Remove unused widgets, animations and entrance effects from the templates that carry traffic.
- For new pages, consider the block editor. [Page builders vs Gutenberg](https://getreport.app/guides/page-builders-vs-gutenberg-the-performance-reality) compares what each sends to the browser.
- If you are choosing a theme, a lightweight block theme or a theme that loads only what each page uses starts far ahead of a multipurpose theme with every feature on.

> **Check: Page builder weight.** A page builder ships its whole framework on every page, whatever the page uses, and wraps every element in extra containers. When it becomes most of the code and most of the markup the visitor downloads and the browser lays out, every other speed fix has less to work with.
>
> 1. Switch on the builder's own performance settings first: see the report for the exact setting
> 2. Remove widgets, animations and add-on packs the page does not use; each one adds its own CSS and JavaScript.
> 3. For the pages that matter most (home, key landing pages) consider building them with core blocks and the theme alone, and keep the builder for the rest.

## Step 6: fix the images

Images are usually the heaviest part of a WordPress page, and the hero image at the top is often the LCP element.

1. **Resize before uploading.** A 4,000 px camera photo shown at 1,200 px wastes most of its bytes. Export at about twice the largest size it is shown at, typically 2,000–2,500 px for a full-width hero.
2. **Use WebP or AVIF.** WordPress accepts WebP uploads since 5.8 and AVIF since 6.5, and image plugins or your CDN can convert existing images. [Image optimisation plugins compared](https://getreport.app/guides/image-optimisation-plugins-compared-honestly) helps you pick one.
3. **Never lazy-load the hero image.** WordPress core lazy-loads images and since 6.3 adds `fetchpriority="high"` to the image it expects to be the LCP element, but themes, builders and optimisation plugins can override that and lazy-load the first slide or banner. The LCP finding shows whether yours has `loading="lazy"`.
4. **Give images width and height** so the layout does not jump; core does this for images in post content.

> **Check: Images are sized for how they are displayed.** Sending a 2000 px photo to a 400 px slot wastes most of the bytes. Responsive images let the browser pick the right size for each screen.
>
> 1. Add srcset and sizes to <img> so phones get small versions; most CMSs generate the sizes for you.
> 2. Resize the originals to the largest size you actually display.

> **Check: Offscreen images are lazy-loaded.** Images far below the fold compete for bandwidth with the ones visitors see first. Lazy loading defers them until they scroll into view.
>
> 1. Add loading="lazy" to images below the fold — but never to the hero/LCP image.
> 2. WordPress adds it by default since 5.5; check your theme or slider has not removed it.

## Step 7: defer and delay JavaScript

Most caching plugins can minify files, defer scripts, delay scripts until the first interaction and remove unused CSS. These settings can save seconds and they are also the ones that break menus, sliders and forms.

- Turn them on **one at a time**, clear the cache and test the page in a private window: open the menu, submit a form, add to cart.
- **Defer** is the safe first step: scripts download in parallel and run after the HTML is parsed.
- **Delay until interaction** helps most for third-party tags (chat, analytics, pixels), but exclude anything the first screen needs, such as a cookie banner or the menu script.
- **Remove unused CSS** is the most powerful and the most fragile. Check pages with different layouts after enabling it.

[Render-blocking resources](https://getreport.app/guides/render-blocking-resources) explains what each option does, and [third-party scripts](https://getreport.app/guides/third-party-scripts-tag-managers-chat-and-ads) covers the tags that most often make a WordPress page slow to react.

> **Check: No render-blocking resources delay the first paint.** Stylesheets and scripts in <head> stop the browser from drawing anything until they have downloaded. Each one adds a round trip before the visitor sees the page.
>
> 1. Add defer or async to scripts that are not needed before the first paint, or move them to the end of <body>.
> 2. Inline the CSS needed for the first screen and load the rest asynchronously (WordPress: "Optimize CSS delivery" in WP Rocket / LiteSpeed Cache).
> 3. Remove unused plugin CSS/JS from pages that do not need it.

> **Check: Third-party code weight.** Tags, widgets and embeds from other companies run on your visitors' phones at your page's expense. Over 250 KB or 250 ms of blocking is a sign they dominate the load.
>
> 1. List what each third party gives you; remove the ones nobody looks at.
> 2. Load the rest after interaction or with a facade (a static thumbnail for YouTube, a click-to-load chat button).
> 3. Move tags into a tag manager that fires them late, not in <head>.

## Step 8: fonts

Every font family and weight is a separate download. Use two families in two or three weights, host them on your own domain (most themes and builders have a setting), and use `font-display: swap`. [Web fonts without layout shift](https://getreport.app/guides/web-fonts-without-layout-shift) covers the fallback size.

> **Check: Web fonts show text while loading.** Without font-display, browsers show blank text for up to 3 s while a web font downloads. Visitors stare at empty headings.
>
> 1. Add font-display swap (or optional) to every @font-face rule.
> 2. For Google Fonts, append &display=swap to the stylesheet URL; self-hosted fonts get it in the @font-face block.
> 3. Preload the one or two fonts used above the fold.

## Step 9: background jobs and the database

Some slowness is random: one request in ten takes three seconds. That is usually work WordPress does during a visitor's request.

- **wp-cron.** WordPress runs scheduled tasks when visitors load pages. On a busy or plugin-heavy site, set `define('DISABLE_WP_CRON', true);` in `wp-config.php` and run `wp-cron.php` from a real cron job every five minutes. [WP-Cron and scheduled tasks](https://getreport.app/guides/wp-cron-and-scheduled-tasks) has the setup for common hosts.
- **Autoloaded options.** Plugins store settings in the `wp_options` table, and options marked autoload are loaded on every request. Since WordPress 6.6, Site Health warns when the autoloaded total goes over 800 KB, usually because of leftovers from deleted plugins.
- **WooCommerce.** Shops have their own background work, notably the cart fragments request. See [WooCommerce cart fragments](https://getreport.app/guides/woocommerce-cart-fragments-the-ajax-call-on-every-page).

## Step 10: add a CDN

A CDN serves your files, and with the right rules whole pages, from near your visitors. It helps most when they are far from the server and cannot fix a slow uncached page behind it. See [CDN basics](https://getreport.app/guides/cdn-basics-what-it-fixes-and-what-it-does-not).

## Step 11: change host, if you still need to

Only now does the hosting plan deserve the blame. If cached pages on a site with a lean set of plugins are still slower than 600 ms from nearby, the server is overloaded or far away. Before you move, measure: [choosing a WordPress host by measured TTFB](https://getreport.app/guides/choosing-a-wordpress-host-by-measured-ttfb) shows how to compare hosts with your own numbers rather than reviews.

## How to verify

- Re-run the speed test on the same three pages, three runs each, and compare with the baseline links.
- The page cache header shows a hit on the second request, and TTFB on cached pages is under 300 ms.
- The plugin detector shows the heavy plugins gone or no longer loading on pages that do not use them.
- The LCP element is the hero image, not lazy-loaded, and LCP in the lab is under 2.5 s on mobile.
- After about four weeks, the real-visitor Core Web Vitals pass. [Core Web Vitals on WordPress](https://getreport.app/guides/wordpress-core-web-vitals) explains what to do if one still fails.

## Common mistakes

- **Stacking plugins that do the same job:** two caches, two minifiers, two image optimisers.
- **Testing while logged in,** which bypasses the cache and makes the site look slower than it is.
- **Turning on every switch at once.** When the menu stops working, you will not know which setting did it.
- **Moving host first.** A new host will not fix an uncached site with a 3 MB page builder layout.
- **Lazy-loading everything,** including the first image, which makes LCP slower.

## Questions people ask

### Can I speed up WordPress without a caching plugin?

Yes, if your host provides a server-level page cache, which is often faster than any plugin because it serves pages before PHP starts. Check your hosting panel or ask support. Everything else in this guide (PHP version, plugin clean-up, images, fonts, wp-cron) needs no caching plugin either. Without any page cache at all, though, a WordPress site will rarely have a fast server response.

### Which WordPress speed settings break sites most often?

Delaying JavaScript until interaction, removing unused CSS and combining files. They change how and when code runs, so menus, sliders, cookie banners and forms can stop working. Turn them on one at a time, clear the cache, and test in a private window after each: open the menu, submit a form, add a product to the cart. Exclude the scripts that break, rather than turning everything off.

### Is it better to pay for faster hosting or a speed plugin?

Neither comes first. Start with the free steps: one page cache, current PHP, fewer heavy plugins and smaller images. Then measure the cached time to first byte. If it is still over 600 ms on a lean site, better hosting will help more than any plugin. If it is fast, paid optimisation plugins can help with scripts and CSS, but they cannot fix a slow server.

### Do I need to clean up the WordPress database to make it faster?

Rarely for visitors. Old revisions and spam comments make the database and backups larger but barely affect cached page views. What does slow every request is a large set of autoloaded options, often left behind by deleted plugins; WordPress Site Health warns when they exceed 800 KB. Clean those, limit revisions in wp-config.php, and skip aggressive database optimisation plugins that run on a schedule.