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

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? diagnoses the five usual causes; for page speed in general, see the page speed guide.

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.

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:

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.

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.

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 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.

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 shows how to pick the one to keep.

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 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 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 has the full method, including how to measure what an admin-only plugin costs on the server side.

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 and 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 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.

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 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.

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 explains what each option does, and third-party scripts covers the tags that most often make a WordPress page slow to react.

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 covers the fallback size.

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 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.

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.

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 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 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.