Most slow WordPress sites come down to the same seven problems: no page caching, CSS and fonts the design never uses, oversized images, heavy plugins, third-party scripts, an old PHP version and weak hosting. Fix caching and unused assets first. On most sites those two changes make the biggest difference for the least effort.
I’ve sped up hundreds of WordPress sites, and the problems are almost never exotic. They’re the same handful of issues, stacked on top of each other. I’ll use real numbers from this site, piash.net, which I rebuilt in Divi 5, so you can see what each fix is worth.
Work through them in this order. Each one is cheaper and safer than the next, and the first two usually solve most of the problem.
Measure before you change anything
Run your homepage and one key page, like a service page or a product page, through Google PageSpeed Insights. Write down three numbers from the mobile report: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). These are Google’s Core Web Vitals, and they’re what you’re trying to move.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP | How fast the main content appears | 2.5 s or less | Over 4 s |
| INP | How quickly the page reacts to taps and clicks | 200 ms or less | Over 500 ms |
| CLS | How much the layout jumps while loading | 0.1 or less | Over 0.25 |
1. Turn on page caching
Without caching, WordPress builds every page from scratch on every visit. PHP runs, the database is queried, the theme assembles the HTML, and only then does anything reach the visitor. Page caching saves a finished copy and serves that instead.
On this site, uncached pages took between 0.7 and 3.5 seconds for the server to respond. With page caching turned on, cached requests come back in a few milliseconds. No other single change comes close.
If your host runs LiteSpeed, its own LiteSpeed Cache plugin is usually the best fit. On other hosts, use the caching your host recommends rather than stacking two caching plugins, which often causes more problems than it solves. One more detail people miss: after a cache purge, the first visitor to each page waits while the page is rebuilt. A cache crawler, or a simple warm-up job, rebuilds the cache before real visitors arrive.
2. Remove CSS and fonts you don’t use
Themes and page builders load assets “just in case”. On this site, Divi was loading a default font the design never used, which added about 174 KB of CSS to every page. Removing it, along with block editor styles the pages didn’t need, cut the page HTML from about 311 KB to around 150 KB.
Fonts deserve special attention. Every font family and weight is a separate download, and fonts loaded from Google’s servers add an extra connection before text can render. Two families with only the weights you use is plenty for most sites. Self-hosting them and preloading the one or two used above the fold removes that extra round trip.
3. Fix oversized images
A 4,000-pixel photo straight off a phone, shown at 800 pixels wide, is still a 4,000-pixel download. Images are often the heaviest part of a page.
- Serve WebP or AVIF instead of large JPEGs and PNGs.
- Resize images to the largest size they’re actually shown at.
- Lazy-load images further down the page.
- Never lazy-load the main hero image or the logo. They should load first, not last.
- Always set width and height, so the browser reserves space and the layout doesn’t jump.
4. Audit your plugins
The number of plugins matters less than what they do. One badly built plugin can slow a site more than twenty light ones. Deactivate anything you don’t use, then look for plugins that load scripts on every page when they’re only needed on one, like a slider, a form or a booking widget.
A quick way to find the heavy ones is to compare page weight and load time with a plugin on and off, on a staging copy. If a plugin you need is heavy, check whether it has a setting to load only where it’s used.
5. Cut back third-party scripts
Chat widgets, tracking pixels, heatmaps, embedded videos and social feeds all load code from other servers. You can’t control how fast those servers are, and each one competes with your own content for the visitor’s bandwidth.
Remove the scripts nobody looks at any more. For the rest, load them only on the pages that need them, or delay them until after the page has loaded. Embedded videos are a classic: show a thumbnail and load the player only when someone presses play. That’s how the client video on this site’s homepage works.
6. Update PHP and clean the database
Newer PHP versions run WordPress noticeably faster, and old ones stop getting security fixes. Ask your host which version you’re on and move to a currently supported PHP 8 release, testing on staging first.
While you’re there, clean out what builds up in the database over the years: hundreds of post revisions, spam comments, expired temporary data and tables left behind by plugins you deleted long ago. It’s rarely a dramatic speed gain on its own, but it keeps backups smaller and admin pages quicker.
7. Check your hosting
If the server is slow to respond even with caching on, the hosting itself may be the limit. Cheap shared plans often put hundreds of sites on one server. A good rule of thumb: if your Time to First Byte is regularly over 0.8 seconds on cached pages, look at your host. Moving to better hosting is sometimes the single biggest upgrade you can make, and it’s often cheaper than the time spent working around a slow server.
Key takeaways
- Measure LCP, INP and CLS first, and re-test after every change.
- Page caching and removing unused CSS and fonts usually fix most of the problem.
- Resize images, and never lazy-load the hero image or logo.
- Audit plugins and third-party scripts by what they load, not by how many there are.
- If cached pages are still slow, the hosting is the bottleneck.
FAQ
How fast should a WordPress site load?
Aim for a Largest Contentful Paint of 2.5 seconds or less on mobile, measured in PageSpeed Insights. For cached pages, the server should respond in well under a second.
Do I need a CDN?
A CDN helps most when your visitors are spread across countries far from your server. For a local business with local visitors, good hosting and page caching matter more. Many hosts include a CDN, so check before paying for one.
Will a speed plugin fix everything?
No. Caching plugins fix the server side, but they can’t remove a heavy theme, oversized images or a dozen third-party scripts. Treat the plugin as one step, not the whole job.
Is Divi or Elementor too slow for a fast site?
Both can produce fast sites when they’re built carefully. Page weight comes far more from how a site is built than from which builder it uses.
Want to know what’s slowing your site down?
Get a free website audit. I’ll check speed, SEO basics, security and mobile, then send you a short list of what to fix first. If you’d rather not think about it again, my care plans include speed checks every month.