How to Speed Up a WordPress Site: Find and Fix the Biggest Bottlenecks
Thirty speed tips won't help if you fix the wrong thing. Measure first, then work on the one part that's actually slow.
WordPress.org’s own optimization handbook has a line for people in a hurry: “go straight to the Caching section, you’ll get the biggest benefit for the smallest hassle there.”
It’s good advice. But a slow site is usually slow for one main reason, and caching only fixes one kind.
The short version: measure first, then find which of three things is slow. The server, the main image or text, or the scripts.
Fix that one, test the same page again, and judge it on real visitor data weeks later.
The 9 steps at a glance
| # | Step | Fixes | About |
|---|---|---|---|
| 1 | Measure, and find the bottleneck | Guessing | 30 min |
| 2 | Turn on page caching | Slow server response | 20 min |
| 3 | Check hosting, PHP and the database | Slow server response | 30 min |
| 4 | Fix the main image | Slow LCP | 30 min |
| 5 | Fonts and jumping layouts | Slow text, CLS | 20 min |
| 6 | Cut third-party scripts | Slow taps and clicks (INP) | 30 min |
| 7 | Trim theme and builder bloat | Heavy CSS and JavaScript | 1 hour |
| 8 | Add a CDN | Distance to visitors | 20 min |
| 9 | Change one thing at a time | Fixes that break other things | Ongoing |
Measure first
1. Measure, and find the bottleneck
Pick three or four pages that stand for the templates you use: the homepage, a post, a product page.
Run each through PageSpeed Insights on mobile, since that’s where you’ll usually see the worst numbers.
The report has two halves, and they answer different questions:
| Half | What it is | Use it for |
|---|---|---|
| Field data (top) | Real Chrome visitors over the last 28 days | Is the page actually slow for people? |
| Lab data (bottom) | One simulated load by Lighthouse | Why is it slow? |
Lab data “may not capture real-world bottlenecks”, Google says. So judge success on field data, and diagnose with the lab half.
Quiet pages often have no field data of their own. PSI then shows the whole site’s instead.
Here are the targets for the three Core Web Vitals, at the 75th percentile of visits:
| Metric | Good |
|---|---|
| LCP, when the main content shows | 2.5 seconds or less |
| INP, how fast the page reacts | under 200 milliseconds |
| CLS, how much the layout jumps | under 0.1 |
Now you can find the bottleneck. In the lab report, look at Time to First Byte and at which element is the LCP. web.dev’s rough target for TTFB is 0.8 seconds or less.
- TTFB slow: the server is the problem. Go to steps 2 and 3.
- TTFB fine, LCP slow: it’s the main image, fonts or blocking files. Go to steps 4 and 5.
- LCP fine, INP poor: it’s scripts. Go to steps 6 and 7.
Speed is one part of a site’s health. The technical SEO audit checklist covers crawling and indexing around it.
Check it: a sheet with each template’s field LCP, INP and CLS, its lab TTFB, and what its LCP element is (an image, a heading, a video).
If the server is slow
2. Turn on page caching
Without a cache, WordPress builds every page from scratch for every visitor. A page cache saves the finished HTML and hands that out instead.
Ask your host first: many already cache at the server.
If you need a plugin, use only one. Here are the common ones, with WordPress.org’s install counts in November 2026:
| Plugin | Installs | Worth knowing |
|---|---|---|
| LiteSpeed Cache | 7+ million | Its page cache only works on LiteSpeed servers or with QUIC.cloud CDN |
| WP Super Cache | 1+ million | Simple page cache, works on most hosts |
| W3 Total Cache | 900,000+ | Many settings; easy to misconfigure |
Running a shop? Cache the catalogue, but never cache cart, checkout or account pages. They’re different for every visitor.
Check it: load the same page twice in a private window. The second load’s TTFB should drop clearly, and the response headers (in your browser’s developer tools) usually show a cache hit.
3. Check hosting, PHP and the database
WordPress.org recommends PHP 8.3 or newer. Tools > Site Health > Info > Server shows yours.
Older? Ask your host to upgrade, once your theme and plugins support it. It’s a security fix too, as October’s PHP2Shell flaws showed.
A persistent object cache (Redis or Memcached) keeps database results between page loads, which helps shops and membership sites. A small blog with a page cache rarely needs one.
For the database, you can install Query Monitor while you test. It shows each page’s queries and outside calls, grouped by the plugin that made them.
Check it: on a slow page, Query Monitor shows no plugin making the same outside request on every load, and no single component behind most of the slow or repeated queries. Turn it off when you’re done.
WordPress 6.6 also added a Site Health warning when autoloaded options pass 800 KB, data loaded on every request.
See it? Find which plugin owns the big options before you delete anything.
If the main content is slow
4. Fix the main image
On most WordPress pages the LCP element is an image, like the featured image or a product photo. Four things decide how fast it shows:
- Size: upload it no wider than it’s shown. A 4,000-pixel photo displayed at 800 wastes most of the download.
- Format: WebP, or AVIF (supported since WordPress 6.5, if your server can make it), which WordPress says can be up to 50% smaller than JPEG at the same quality.
- No lazy loading on this one image.
- Priority: since 6.3, WordPress tries to add
fetchpriority="high"to the likely LCP image, though sliders and page builders can hide it from that logic.
WordPress lazy-loads images by default, which helps below the fold. It hurts the first image people see.
The Performance Lab plugin, from the WordPress performance team, has optional modules for this, such as Image Prioritizer. Treat them as experiments.
Check it: in the lab report, the LCP image starts loading early, isn’t marked
loading="lazy", and is served close to its displayed size in WebP or AVIF.
5. Fonts and jumping layouts
Is your LCP element a heading? Then the image isn’t your problem. Web fonts are a common culprit, because the browser waits for the font file before showing text in it.
Use one or two font families, only the weights you’ll actually need, hosted on your own site. Set font-display: swap so text shows in a fallback font first.
For layout shift (CLS), give every image, video and embed a width and height, and reserve space for ads.
Cookie banners and late ad slots are the usual reason a page jumps as you start to read.
Check it: the lab report shows no font blocking the LCP, and the field CLS for your templates is under 0.1.
If scripts are slow
6. Cut third-party scripts
Chat widgets, ad networks, tag managers, social embeds, heatmaps: each one adds downloads and work on the visitor’s phone. They’re the main reason pages react slowly to taps.
Start by removing what you don’t use. That old A/B testing tag nobody checks? Gone.
The chat widget nobody answers can go too.
Only then delay or defer what’s left, one script at a time. Delaying can break things, so test the cookie banner, forms, menus, checkout and analytics after each change.
Check it: the lab report’s third-party list is shorter, the site still works on a phone, and field INP improves over the following weeks.
7. Trim theme and builder bloat
Some themes and page builders load their CSS and JavaScript on every page, used or not. A slider script on a blog post with no slider is pure weight.
Use one optimization plugin at most, such as Autoptimize or Jetpack Boost. Two doing the same job fight each other.
And combining every CSS and JavaScript file into one? WordPress.org’s handbook ties that advice to HTTP/1.x, so test it before you trust it on a modern server.
Check it: compare total CSS and JavaScript on a post before and after, in the lab report’s network details.
8. Add a CDN
A content delivery network keeps copies of your images and files on servers near your visitors. Some cache whole pages too.
It matters most when your visitors are far from your server. A site hosted in the US with readers in Asia gains more than one whose readers live near the data centre.
Check it: your image and CSS responses come from the CDN (its name usually shows in the response headers), and TTFB for distant visitors drops.
Keep it fast
9. Change one thing at a time
Make one change, then test the same page on your same device and connection. Change three things at once and you won’t know which one helped, or which one broke the checkout.
Then wait. Field data covers 28 days, so a fix takes about a month to show fully.
Before a big change, like a new theme, take a backup you’ve tested.
Sites slow down again after new plugins, ad tags and themes. Re-run step 1 after each one.
Keeping WordPress current helps too. Version 6.8 added speculative loading, which starts fetching the next page as a visitor begins to click its link.
Check it: your sheet from step 1 has a “before” and “after” for every change, a month apart.
What’s overrated
- counting plugins, when one badly built plugin can cost you more than twenty light ones
- a 100 PageSpeed score or a GTmetrix grade, which are lab numbers your visitors never see
- disabling emojis and other micro-tweaks
- two cache plugins “for extra speed”, which conflict and can eat your afternoon
- a database cleanup plugin as your first fix, before you know the database is the problem
Why it matters
Speed advice online is mostly lists of 30 tweaks. Most sites need two or three of them, and the hard part is knowing which.
So don’t start with a plugin. Start with step 1, write down what’s slow, and fix in that order.
Only got an hour? Check page caching and your main image, steps 2 and 4. On most WordPress sites I’d bet on one of those two, and you’ll know which within ten minutes of opening the report.
Common Questions
Why is my WordPress site so slow?
Usually the server, the main image or third-party scripts. Run PageSpeed Insights on mobile: a slow Time to First Byte points to hosting or missing page caching, while a fast TTFB with a slow LCP points to images, fonts or blocking files.
Does the number of plugins slow down WordPress?
Not directly. What matters is what each plugin does on every page: database queries, outside requests and the CSS and JavaScript it loads. Query Monitor shows that per plugin, so a site with 30 light plugins can be faster than one with 5 heavy ones.
What is a good PageSpeed Insights score for a WordPress site?
Look past the score. Google treats 90 and above as good, but the field data at the top of the report matters more: LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1 for real visitors.
