How to speed up a slow WordPress site, in the order that pays off
Measure the pages that matter first. Then work down the list in order. Check the PHP version and the hosting, add a page cache, fix the images, cut plugins, look at the theme, add a CDN, and tidy the database last. Change one thing at a time and measure again.
- By
- WP Ministry
- Updated
- Tested on
- WordPress 7.1.3, PHP 8.3.35
In short
- Measure before you change anything, and test the pages visitors land on, not only the home page.
- The server's first answer comes before everything else. Check the PHP version, then add a page cache.
- Images are the next thing to fix. Upload them at the size they are shown, compressed.
- Every plugin and every theme feature adds work. Remove what you do not use, and measure what is left.
- A CDN helps most when your visitors are far from your server.
- Database clean-up helps the dashboard and pages that cannot be cached. Do it last.
Most slow WordPress pages are slow for ordinary reasons. The server takes too long to answer. Every page is rebuilt for every visitor. Images are far larger than the space they fill. Plugins and the theme load more scripts than the page needs.
The steps below run from the largest usual gain to the smallest. Take a backup first, change one thing at a time, and measure after each change.
Measure before you change anything
PageSpeed Insights, at pagespeed.web.dev, is free. Give it a page's address and it reports two kinds of figures.
- Field data is how the page loaded for real visitors using Chrome over the previous 28 days. A page with few visitors has none of its own. PageSpeed Insights then shows figures for the whole site, or no field data at all.
- Lab data is one test load, run on the spot on a simulated mid-range phone on a mobile network. It comes with a performance score out of 100 and a list of what slowed the page down.
Test more than the home page. Visitors often arrive somewhere else, and a blog post, a product page and a landing page each load their own template, images and scripts. Test one page of each kind that matters.
For each page, write down:
- Largest Contentful Paint (LCP): how long until the main content of the page is on screen.
- Time to First Byte (TTFB): how long the server takes to begin answering. PageSpeed Insights shows it with the field data. Without field data, the network panel of your browser's developer tools shows how long the page's first request waited for the server.
- The lab performance score. It moves from one run to the next, so run the test five times and keep the middle result. Lighthouse, the tool behind it, says in its documentation that the median of five runs is twice as stable as a single run. It counts 90 and above as good.
What each figure means, and what counts as good, is in how to improve WordPress Core Web Vitals.
Hosting and the PHP version
What it changes: the server's first answer. Nothing else can begin until it arrives, so a slow answer makes every later figure slow. Google's guidance counts a TTFB of 0.8 seconds or less as good and more than 1.8 seconds as poor.
WordPress runs on PHP, and newer versions of PHP are built to run faster. WordPress recommends PHP 8.3 or greater. A PHP version receives fixes for four years after its release, and none after that.
Step 1: See which version the site runs
Go to Tools, then Site Health. When the PHP version is out of date, the Status tab lists it among the issues.
Step 2: Update everything else first
An old plugin or theme may not run on a new PHP version. Bring WordPress, the plugins and the theme up to date first, as how to safely update WordPress describes. If you have a staging site, change the PHP version there first.
Step 3: Change the version in your hosting control panel
Many hosts let you choose the PHP version for each site. If yours does not, ask them to change it.
Step 4: Look at the site
Open the pages you measured, the dashboard and any forms. If the site shows a critical error, set the version back in the same place, then read how to fix the white screen of death to find the plugin that failed.
Do not judge the hosting plan yet. A page cache, the next step, takes most of the work off the server. If the server is still slow to answer after that, or the dashboard itself is slow, the plan is the limit. Ask the host what the next plan up would change.
How to see that it worked: Site Health no longer lists the PHP version, and TTFB on the pages you measured is lower.
A page cache
What it changes: without a cache, WordPress runs its PHP code and queries the database to build a page each time someone asks for it. A page cache saves the finished page and hands that copy to the next visitor. WordPress's own documentation calls caching the fastest way to improve performance.
Step 1: Find out whether your host already caches pages
Some hosts cache pages on the server. Look in the hosting control panel or the host's documentation. If a page cache is already there, use it and do not add a second.
Step 2: Otherwise, install one caching plugin
WordPress caching plugins compared covers what each one does and how to choose.
Step 3: Keep personal pages out of the cache
A page that differs from one visitor to the next must be built fresh every time. On a WooCommerce store that means the Cart, My Account and Checkout pages. See how to speed up WooCommerce.
Step 4: Clear the cache after you change the site
Visitors keep receiving the saved copy until the cache is cleared. If an edit does not show, clear it.
How to see that it worked: on a live site, the Status tab of Site Health reports whether WordPress can detect a page cache and how fast the server answers. Then test the same pages again and compare TTFB.
A page cache does nothing for the dashboard, the cart or anything shown to a logged-in visitor. A persistent object cache helps those by keeping the results of database queries in memory between requests. It needs software on the server, such as Redis or Memcached, so it is your host's to offer. Site Health suggests one when the site holds enough data to gain from it.
Images
What it changes: how much has to be downloaded before the page looks finished. A photo straight from a camera can be many times larger than any web page needs.
WordPress does part of the work. When you upload an image it makes several smaller copies and tells the browser about all of them, so a phone can fetch a small one. A JPEG photo wider or taller than 2560 pixels is scaled down to that size for use on the site.
The rest is yours:
- Upload an image at about the size it will be shown, and compress it.
- Use a newer format such as WebP where you can. WordPress's documentation notes that it is smaller.
- Check the images your theme or page builder places as backgrounds. They are set in CSS, so the smaller copies WordPress makes are not offered to the browser.
How to optimize WordPress images without losing quality has the method.
How to see that it worked: the lab report in PageSpeed Insights lists images that are larger than the space they fill or that could be compressed further. That list gets shorter, and LCP falls on pages where the largest thing on screen is an image.
Fewer and lighter plugins
What it changes: each active plugin runs code whenever a page is built, and many add their own scripts and styles to every page, including pages that make no use of them. WordPress's documentation says to deactivate and delete plugins you do not need, and to switch plugins off selectively to measure their effect.
With WP-CLI, this lists what is active:
wp plugin list --status=activeDelete the ones you no longer use. An inactive plugin loads nothing, but it still has to be kept updated.
Then find the expensive ones among those you keep. On a staging site if you have one, deactivate one plugin, measure the same page, and switch it back on. It is the method in how to find a plugin conflict, used for speed. Query Monitor, a free plugin from the WordPress.org directory, shows the database queries, scripts and styles behind a page and can narrow them down by plugin or theme. Only administrators see its output.
When one plugin stands out, look for a lighter one that does the same job.
How to see that it worked: the page asks for fewer script and style files, which the network panel of your browser's developer tools shows. In the lab report, Total Blocking Time, the time scripts kept the page too busy to respond, is lower.
A lighter theme
What it changes: the theme decides how much CSS and JavaScript every page carries before any content is added. WordPress's documentation says a light theme performs far better than a heavy one loaded with graphics.
To find out what yours costs, switch a staging copy of the site to one of WordPress's default themes and measure the same page. A large difference means the theme, or the page builder it depends on, is where the time goes.
Start with the theme's own settings: switch off the sliders, animations, icon sets and font families the site does not use. If that is not enough, the remaining choice is a different theme. That is a rebuild of the site's design, so weigh it against the gain you measured.
How to see that it worked: measure the same page before and after.
A CDN
What it changes: a content delivery network keeps copies of your images, CSS and JavaScript on servers in many places and sends each visitor the copy from the nearest one. The files travel a shorter distance, and your own server answers fewer requests.
The gain depends on where your visitors are. A site hosted in one country and read around the world gains the most. A local business whose visitors live near its server gains less.
How to set up a CDN for WordPress goes through the setup.
How to see that it worked: in your browser's developer tools, look at the response headers of an image from the site. Your CDN's documentation names the header that shows the file came from its cache.
The database
What it changes: how quickly WordPress answers when it has to query the database: in the dashboard, in search, and on pages that cannot be cached. Cached pages never reach the database, so visitors seldom notice this step. That is why it comes last.
By default WordPress keeps every revision of every post and page. To cap the number, add this line to wp-config.php, above the line that says "That's all, stop editing". WordPress then removes a post's older revisions the next time that post is updated.
define( 'WP_POST_REVISIONS', 5 );With WP-CLI you can see where the space goes and clear what is safe to clear. Back up the database first.
wp db size --tables
wp transient delete --expired
wp db optimizeThe first command lists each table with its size. The second deletes expired transients, the temporary values plugins store with an expiry date. The third runs the database's own optimize command on the tables.
How to see that it worked: run wp db size before and after, and time a dashboard screen that used to be slow.
Keep it fast
A new plugin, a redesign or a few uncompressed photos can undo any of this, so measure the same pages again after a large change.
If you would rather hand the job over, our speed optimization service is a one-time job: you name the pages, and we measure them before the work and again after it.
Common questions
Do I need to do all of this?
No. Measure, check the PHP version, add a page cache and fix the images. Then measure again. Often that is enough. Carry on down the list only while the pages you care about are still slow.
Why is the site fast for me and slow in the test?
Your browser has already saved the site's files, and you are probably on a fast connection. The lab test loads the page from scratch on a simulated mid-range phone on a mobile network.
How long until the figures change?
Lab data changes at once: run the test again after each change. Field data covers the previous 28 days, so it takes about four weeks for a fix to show in full.
Can a speed plugin break the site?
Yes. Settings that combine, delay or defer scripts change the order in which they run, and a menu, a form or a slider can stop working. Switch on one setting at a time, look at the site in a private window, and switch the setting off again if something breaks.