If you've looked up how to speed up WordPress, you've probably found a plugin shopping list. Install this, toggle that, add one more.
So you installed a caching plugin, maybe two. You turned on lazy loading somewhere. And your PageSpeed score still won't move.
Most of the time, the order you fix things in matters more than which plugin you pick. Stacking plugins can leave you with a site that's slower than when you started.
The useful work starts by separating three problems: a slow server, a heavy page and a bad experience for real visitors. My companion guide on why a WordPress site is slow covers the diagnosis in more detail.
This is the order I'd work in, with the few plugins I'd use.
First, Measure Where You Actually Stand
Before you change anything, get a baseline. Otherwise you're guessing, and guessing is how people end up with six caching plugins and a broken site.
- Loading (LCP): good at 2.5 s or less, needs improvement up to 4 s, poor over 4 s
- Responsiveness (INP): good at 200 ms or less, needs improvement up to 500 ms, poor over 500 ms
- Visual stability (CLS): good at 0.1 or less, needs improvement up to 0.25, poor over 0.25
Two tools matter here:
- Google PageSpeed Insights. It's free and tests both mobile and desktop. Its field section shows real-user data from Chrome when there's enough of it. Its Lighthouse lab score is a simulated test. That's useful for finding problems, but it isn't the same as real-user performance. Google explains the field and lab split.
- Your browser's developer tools (Network tab). Open it, reload the page and look at the waterfall. You'll see every file that loads, how big it is and how long it takes. That tells you where the bottleneck lives.
Start with Time to First Byte (TTFB), which is how long the server takes to start responding. Google's guidance is 0.8 seconds or less.
Then compare it with LCP and the waterfall. A slow TTFB points to hosting, server work or the database. A good TTFB with a slow LCP usually points to the page itself, often the hero image, CSS, fonts or JavaScript.
Write down your numbers and take screenshots. Compare after each change so you know what helped and what didn't.
Page Caching: The Single Biggest Win
Every time someone visits a WordPress page, the server runs PHP, queries the database, builds the HTML and sends it back. That takes time. On a busy server or a complex page, it takes a lot of time.
Page caching builds the HTML once and hands that saved copy to every visitor after. It's the difference between cooking every meal to order and having it ready on the counter.
For most WordPress sites that's a large improvement, because it removes repeated PHP and database work on every page that can be cached. Measure before and after on the same URLs so you know what it changed on your site.
Which caching plugin?
WP Super Cache is simple and reliable. W3 Total Cache gives you more control. WP Rocket is a paid option that handles caching, minification and lazy loading in one package.
Pick one. Don't run two caching plugins at the same time. They'll conflict and break things.
Object Caching with Redis
Page caching covers visitors who see the same page. Logged-in users, WooCommerce cart pages and other dynamic content can't use it. That's where object caching comes in.
Redis keeps frequently used database results in memory, so WordPress doesn't have to ask the database every time. On WooCommerce sites especially, it can make a real difference on pages that can't be page-cached. My WooCommerce speed guide goes deeper on that.
Your host has to support Redis. Many managed WordPress hosts offer it, sometimes as an add-on. On basic shared hosting you probably don't have the option, and that's one reason to upgrade.
Browser Caching
Browser caching tells a visitor's browser to keep files it has already downloaded, so it doesn't fetch them again on the next page or visit. Your logo, CSS, JavaScript and fonts rarely change, so there's no reason to download them twice.
Your caching plugin or your server settings (often the .htaccess file) handle this. Set static files to cache for at least 30 days. If you use Cloudflare, it handles a lot of this for you.
Image Optimization: Smaller Files, Same Quality
Images are usually the heaviest part of a WordPress page. One photo straight off a phone can be several megabytes. Put six of them on a page and visitors download a lot before they see anything useful.
Three things matter here:
Convert to WebP
WebP is a modern image format. Google's WebP page puts lossy WebP images at 25 to 34% smaller than comparable JPEGs at the same quality.
Every major browser supports it. If you're still serving JPEG or PNG, you're sending bigger files than you need to.
ShortPixel or Imagify can convert your existing library to WebP. They do the processing on their own servers, so your hosting isn't slowed down.
Lazy Loading
Lazy loading waits to load images until a visitor scrolls near them. On a long page with 15 images, only the first few load at first. The rest load as the visitor scrolls down.
WordPress has lazy-loaded images by default since version 5.5.
But make sure the hero image at the top of the page isn't lazy-loaded. It should load right away. Lazy loading it hurts your LCP, because the browser waits on the most important image on the page.
Responsive Images (srcset)
A 2,000 pixel hero image doesn't need to be 2,000 pixels on a 375 pixel phone screen. The srcset attribute lets the browser download the right size for the device. WordPress makes several sizes of each image when you upload it, but your theme has to use them.
Check your theme. If phones get full-size images, you're wasting data and dragging down your mobile speed.
CDN Configuration
A content delivery network (CDN) keeps copies of your site's files on servers in many cities. A visitor in Louisville gets files from a server nearby instead of wherever your hosting lives. A visitor in Seattle gets them from a West Coast server.
For a Kentucky business whose customers are mostly local, a CDN matters less than it does for a national site. It still helps, because CDN servers are built for fast file delivery in ways that standard hosting often isn't.
Cloudflare is the easiest place to start. Its free plan includes a global CDN, free SSL and basic DDoS protection. For most small business WordPress sites, the free plan is enough.
Slow WordPress Site Costing You Customers?
I'll audit your site, find the real bottlenecks and tell you exactly what to fix. New sites start at $2,500, then $399/month for hosting, updates and local SEO.
Minification and Concatenation
Minification strips spaces, comments and other extra characters out of your CSS and JavaScript files. A 100 KB CSS file might drop to 70 KB. Across several files, that adds up.
Concatenation combines several CSS or JavaScript files into fewer files, so the browser makes fewer requests. Instead of 12 separate JavaScript files, it downloads 2. On modern HTTP/2 hosting this matters less than it used to, so don't force it if it breaks things.
Most caching plugins do both. WP Rocket does it well. Autoptimize is a free option that focuses on minifying and combining files.
One warning: aggressive JavaScript changes can break things. If the site looks wrong or features stop working, turn off the JavaScript settings first and leave CSS minification on.
CSS minification rarely breaks anything. JavaScript changes often do.
Database Optimization
Your WordPress database collects junk over time. Post revisions, spam comments, expired transients and leftover data from plugins you deleted months ago all stay behind. On a site that's been running for a few years, that can be tens of thousands of rows you don't need.
A bloated database means slower queries, which means slower page builds and slower load times.
What to clean up:
- Post revisions. WordPress saves a revision every time you update a post or page. A single post can pile up dozens. Cap revisions with the
WP_POST_REVISIONSsetting in wp-config.php (documented here), then delete the old ones. - Spam and trashed comments. Delete them. They're sitting in your database taking up space.
- Transients. Temporary data that plugins store. The plugin that created them is often long gone, but the data stays.
- Unused tables. Plugins create database tables and often leave them behind when you delete the plugin. WP-Optimize can find and remove them.
- Autoloaded data. Some plugins store large settings that load into memory on every page. Since WordPress 6.6, Tools > Site Health warns you when autoloaded options pass 800 KB. WordPress explains the check here.
WP-Optimize or Advanced Database Cleaner can handle all of this. Take a backup, then schedule a cleanup once a month.
The Plugin Problem
This is where a lot of speed guides go wrong. They tell you to install eight new plugins to make your site faster.
Every plugin is code that runs on your server. Some are light. Some aren't.
One badly built plugin can slow every page by loading JavaScript everywhere, running database queries on every request or waiting on outside services.
My approach: Install the free Query Monitor plugin. Load your home page. Look at its "Queries by Component" view.
It shows how many database queries each plugin runs and how long they take. That's where you find the real problems.
Deactivate plugins you don't use. Replace heavy ones with lighter options.
And don't add a plugin for every small feature. Sometimes a few lines of custom code beat a plugin that loads JavaScript on every page.
Hosting Matters More Than You Think
You can fix everything on this list and still have a slow site if the hosting is the bottleneck. On shared hosting, your site shares a server with many other sites. When they get busy, your site slows down.
Here's my general recommendation:
- Basic business site (under 10,000 visitors a month): a good shared host is usually fine. Avoid the cheapest tier.
- WooCommerce or high-traffic site: managed WordPress hosting, like Cloudways, Kinsta or WP Engine. Server-level caching, staging copies and Redis support make a measurable difference.
- TTFB above 0.8 seconds with page caching on: that's outside Google's "good" range. An uncached page is often slower, so test with caching on. If it's still slow on repeated tests, hosting is the likely problem. No plugin fixes a slow server.
For retail and ecommerce sites, hosting is the foundation. If server response stays slow on repeated tests while the page itself is lean, moving hosts may help more than another performance plugin.
The Order That Actually Matters
If you're going to speed up WordPress, do it in this order. Each step builds on the one before it.
- Measure your baseline. PageSpeed Insights, TTFB and LCP. Write them down.
- Check your hosting. Many hosts cache pages for you. If TTFB stays above 0.8 seconds with caching on, fix hosting first. No caching yet? Recheck TTFB after step 3.
- Set up page caching. One plugin, set up correctly. This is your biggest single win.
- Fix your images. Convert to WebP, lazy-load everything except the hero image and check srcset.
- Add a CDN. Cloudflare's free plan at minimum.
- Clean the database. Revisions, transients and leftover data.
- Audit plugins. Use Query Monitor. Remove or replace the heavy ones.
- Minify CSS and JavaScript. Carefully. Test after each change.
- Measure again. Compare with your baseline.
Most sites see the big change from steps 2 to 4. Steps 5 to 8 are refinement.
Don't skip the measuring. It keeps you honest and catches anything you broke along the way.
Common Patterns on Slow WordPress Sites
The same few problems show up on slow WordPress sites again and again. A common one: someone told the owner to "just add a caching plugin," so they added three. Now three caching plugins fight each other and make things worse.
The fix is fewer plugins and a set order.
Cut down to one caching plugin, set up properly. Move to hosting that can handle the load. Turn on Redis.
Resize and compress the images. Put a CDN in front. Clean out stale revisions.
Done in that order, it's the difference between a site that loses visitors and one they can actually use.
Two more to check for.
First, a theme that loads a dozen JavaScript files on every page. That can bog down something like a salon booking site, and it's a common website mistake. Second, a heavy form plugin that loads its scripts on every page instead of only the contact page.
When to Stop Optimizing and Start Rebuilding
Sometimes a WordPress site carries so much technical debt that fixing it costs more than starting over. Think of a bloated page builder with hard-coded scripts, 50+ plugins with half of them abandoned, or a database full of old migrations and broken tables. At that point, it's worth an honest talk about building something new.
This is a big part of why I build most of my client sites as custom static sites instead of WordPress. A static site has no database, PHP page building or plugin chain on a normal page view. For a lot of small businesses, that shorter path is the better fit.
Some businesses do need WordPress, for its CMS, for WooCommerce or for features that depend on it. If that's you, speeding up what you have is worth the effort. Follow the steps above in order, measure as you go, and you should see a real difference.
Your site's speed isn't a vanity metric. It decides whether customers can use the site without waiting around.
Fix the real bottleneck, check the result and keep it from drifting with a practical website maintenance plan. If you're not sure where the bottleneck is, the $250 Website Rescue diagnostic finds it and gives you a written fix plan.
