How to Speed Up a WordPress Site: A Practical Checklist

Most slow WordPress sites are slow for the same handful of reasons: an outdated PHP version on cramped hosting, no page cache, too many plugins loading scripts on every page, and oversized images. The fixes are well known, but the order matters. Installing a fifth optimization plugin will not help if every page takes two seconds to generate on the server. This checklist works from the server outward, so each step builds on the last.

Before you start, measure. Test your homepage and one key inner page (a product, service or blog post) on mobile in PageSpeed Insights, and note the Time to First Byte, LCP and Total Blocking Time. You need a baseline to know what worked.

1. Check your PHP version

WordPress runs on PHP, and newer PHP releases are generally faster. WordPress.org currently recommends PHP 8.3 or greater, and MySQL 8.0+ or MariaDB 10.11+.

It is also a security issue. According to php.net, as of October 2026:

Anything older than 8.2 no longer receives security fixes, and 8.2 drops off at the end of this year.

How to upgrade safely:

1. Check your current version under Tools > Site Health > Info > Server.
2. Take a full backup, or better, use your host's staging site.
3. Switch the PHP version in your hosting control panel on staging first.
4. Click through key pages, forms and checkout. Check the PHP error log.
5. Old, abandoned plugins are the usual source of breakage. Replace them rather than staying on old PHP.

While you are in the control panel, confirm OPcache is enabled. It stores compiled PHP so it does not have to be recompiled on every request. Most decent hosts enable it by default.

2. Make sure hosting is not the bottleneck

If your TTFB is consistently high even for a simple page, hosting is likely the limit. Signs:

• TTFB well above Google's 800 ms "good" guideline for uncached pages
• The admin dashboard is slow even with few plugins
• Speed gets much worse at busy times (shared server contention)
• You keep hitting CPU or memory limits in the hosting panel

What to look for in a host: a current PHP version, NVMe or SSD storage, server-level page caching, an option for Redis or Memcached object caching, HTTP/2 or HTTP/3, and data centers close to your customers. Our guide to reducing TTFB covers server-side tuning in more depth.

3. Turn on page caching

This is the biggest single win for most WordPress sites. Without a page cache, every visit runs PHP, loads plugins and queries the database to build the same HTML again. With one, most visitors get a prebuilt HTML file.

Options, roughly from best to simplest:

• Host-level caching (many managed WordPress hosts include it, often using Nginx or Varnish). Use this if your host provides it, and do not stack a second page cache plugin on top.
• A caching plugin such as WP Super Cache, W3 Total Cache or Cache Enabler, or a commercial equivalent.
• CDN edge caching of full HTML for mostly static sites.

Things to check after enabling:

• Logged-in users and cart/checkout pages should bypass the cache. WooCommerce sets cookies that most caching plugins recognize, but verify by adding something to the cart and browsing.
• Look at the response headers of a page in a private window. Many caches add a header such as x-cache: HIT or a comment at the bottom of the HTML.
• WordPress Site Health includes a page cache check that reports whether a cache was detected and how fast the server responded.

4. Add a persistent object cache

WordPress caches database query results in memory, but only for the duration of one request. A persistent object cache (Redis or Memcached) keeps that data between requests, which helps uncached pages, the admin area and WooCommerce in particular.

You need two things: the cache service running on your server (ask your host), and a drop-in plugin that connects WordPress to it. Site Health will suggest a persistent object cache on larger sites.

5. Audit your plugins

The problem is rarely the number of plugins. It is what each one loads. One poorly built plugin can add several scripts and stylesheets to every page, or run slow database queries on every request.

A practical audit:

1. List what each plugin is for. Delete anything you cannot justify. Deactivated plugins should also be deleted.
2. Look for overlap. Two SEO plugins, two form plugins, a page builder plus a block library plus a slider plugin.
3. Check what loads on the front end. Open DevTools > Network on a page, filter by JS and CSS, and look at the /wp-content/plugins/ paths. A contact form plugin loading its script on every page is a common example.
4. Measure the server side. The free Query Monitor plugin shows slow database queries and which plugin or theme component caused them. Use it on staging and remove it afterward.
5. Disable one at a time on staging and re-test if you cannot find the culprit any other way.

Heavy page builders and multipurpose themes deserve special attention. They often load large CSS and JavaScript bundles and produce deeply nested HTML, which hurts LCP and INP. A lightweight block theme is usually far faster for a simple business site.

6. Fix images

Images are typically the heaviest part of a WordPress page.

• Resize before uploading. A 5000-pixel photo straight from a phone is wasteful even though WordPress generates smaller sizes.
• Use modern formats. WordPress supports uploading WebP, and AVIF since WordPress 6.5, provided your server's image library (Imagick or GD) supports it. Check under Site Health > Info > Media Handling.
• Let WordPress do responsive images. Images inserted via the editor get srcset and sizes automatically, so phones download smaller files.
• Check lazy loading on the hero image. WordPress adds loading="lazy" to images automatically, and since WordPress 6.3 it leaves the first few images un-lazy-loaded and adds fetchpriority="high" to the image it judges most likely to be the LCP element. Themes, page builders and optimization plugins can override this and lazy-load the hero anyway. View the page source and check.

The details of formats, srcset and compression are in our image optimization guide.

7. Clean up front-end assets

Once the server and images are handled, look at CSS and JavaScript.

• Minify and combine carefully. Minifying CSS and JS is safe. Combining files matters less with HTTP/2 and can break things.
• Defer JavaScript that is not needed for the first render. Many optimization plugins offer "defer" or "delay until interaction" options. Delaying scripts can break sliders, menus and analytics, so test thoroughly.
• Remove unused CSS or generate critical CSS for above-the-fold content. See eliminating render-blocking resources.
• Host fonts locally instead of loading from a third-party font service, and limit the number of weights.
• Remove what you do not use, for example emoji scripts, embeds on pages without embeds, or tracking pixels for ad platforms you no longer run.

8. Tidy the database

Older sites accumulate post revisions, expired transients, spam comments and orphaned plugin data.

• Limit revisions in wp-config.php:

define( 'WP_POST_REVISIONS', 10 );

• Watch autoloaded options. These load on every request. The WordPress handbook suggests keeping the autoloaded total small (under about 800 KB). Leftover data from removed plugins is a common cause of bloat.
• Make sure tables use the InnoDB engine, not the older MyISAM.

Always back up before running a database cleanup tool.

9. Consider a CDN

If your visitors are spread across regions, a CDN serves static files from locations close to them and can cache full pages too. For a local business with local customers it helps less. Weigh the cost and setup effort against where your visitors actually are.

Priority order at a glance

Frequently asked questions

How many plugins is too many?

There is no fixed number. Ten heavy plugins that load assets everywhere can be worse than forty well-built ones that load only where needed. Judge each plugin by what it adds to the front end and to server time, not by the count.

Do I need a caching plugin if my host has caching?

Usually not for page caching. Running two page caches can cause stale content and conflicts. You may still use a plugin for front-end optimizations like deferring JavaScript, as long as its page cache feature is turned off.

Will upgrading PHP break my site?

Usually not, but outdated plugins and themes can throw errors on newer PHP. Test on a staging copy first and check the error log. If a plugin breaks on a supported PHP version, it is a sign it is no longer maintained.

Why is my WordPress admin slow even though the front end is fast?

Page caches do not apply to logged-in users, so the admin always runs full PHP and database queries. A persistent object cache, a current PHP version and removing heavy plugins help most here.

What to do next

Work through the list in order and re-test after each step, so you know which change made the difference. When you are done, run a free audit to check your performance score and Core Web Vitals, and to catch the security and SEO issues that WordPress sites often have alongside speed problems. For the security side, see our WordPress security checklist.

Related reading

• WordPress 7.2 Beta 1: What Site Owners Should Test Before December: WordPress 7.2 Beta 1 arrived on October 20, 2026, ahead of a December 8 release. What changes for editors, admin speed and developers, and how to test safely.

Sources

• WordPress requirements - WordPress.org
• Optimization - WordPress Advanced Administration Handbook
• Cache - WordPress Advanced Administration Handbook
• Supported PHP versions - php.net
• Image performance enhancements in WordPress 6.3 - Make WordPress Core
• WordPress 6.5 adds AVIF support - Make WordPress Core