To speed up a slow WordPress site, fix it in this order: server response time, image weight, then JavaScript. Measure real visitor data first, not a test score. Most sites are slow because of too many plugins and heavy images, not because of a missing cache plugin. Cache last, not first.
I build CRM systems and business tools for clients, and site speed comes up in almost every project. The pattern is always the same. The owner has installed four speed plugins, the score still says 38, and nobody can say what is actually slow.
This guide is the order I work in. It is boring on purpose. The boring order works.
What counts as a slow WordPress site in 2026?
Google measures speed with three numbers called Core Web Vitals. They are not a single score. Each one measures a different thing, and each one has a different cause when it fails.
According to Google’s Core Web Vitals documentation, a page is good when the largest thing on screen appears in 2.5 seconds or less, the page responds to a tap in 200 milliseconds or less, and the layout does not jump more than 0.1. Google judges this at the 75th percentile of your real visits, so your slowest quarter of visitors still counts.
| Metric | Good score | What it really measures | Usual WordPress cause |
|---|---|---|---|
| LCP | 2.5 seconds or less | How fast the main image or heading shows up | Slow hosting, huge hero image |
| INP | 200 milliseconds or less | How fast the page reacts to a tap or click | Too much plugin JavaScript |
| CLS | 0.1 or less | How much the page jumps while loading | Ads, fonts, images with no size set |
Note the third column. LCP is a hosting and image problem. INP is a JavaScript problem. They need different fixes. A cache plugin helps the first one and does almost nothing for the second.
Why do most guides fail to speed up a slow WordPress site?
Because they hand you a list of twenty tips with no order. You do the three easiest ones, the score moves by four points, and you give up.
The size of the problem is real. The HTTP Archive Web Almanac CMS chapter found that only 45 percent of WordPress sites pass Core Web Vitals on mobile. Broken down, 53 percent pass LCP and about 84 percent pass CLS. The report also notes that no major CMS delivers good INP at scale, and the median WordPress page on mobile weighs around 2,894 KB.
Read that chart carefully, because it tells you where to spend your time. Layout jumping is mostly a solved problem. Load speed is not. If you are average, your site is in the 55 percent that fails.
Step 1: Measure real visitors, not a test score
Run your home page and your two busiest pages through Google PageSpeed Insights. Ignore the big coloured number at the top. That is a lab test on a simulated slow phone.
Look instead at the section near the top that says it comes from real users over the last 28 days. That is field data. It is what Google actually uses. A site can score 95 in the lab and still fail in the field, usually because real visitors are on slower phones than the test assumes.
Write down three numbers before you change anything: LCP, INP and CLS, from the field section, on mobile. Everything after this is measured against those three.
Step 2: Fix your server response time before anything else
Time to First Byte, or TTFB, is how long the server takes to start sending the page. Google’s guidance on TTFB says most sites should aim for 0.8 seconds or less.
This matters because TTFB comes first. Nothing else on the page can start until the server replies. If your TTFB is 1.8 seconds, your LCP can never be 2.5 seconds, no matter how small your images are. You are optimising a race you already lost at the starting line.
Check your PHP version first, it is free
PHP is the programming language WordPress runs on. Old versions are slower and less secure. WordPress.org recommends PHP 8.3 or greater, with MariaDB 10.11 or MySQL 8.0 for the database.
Most hosts let you switch PHP version from the control panel in two clicks. Take a backup, switch, then click through your site and check your forms still work. If something breaks, switch back. It costs nothing and it is the single cheapest speed win available.
When the host itself is the problem
If your TTFB stays above one second on a cached page, with PHP 8.3 and a light theme, the hosting is the bottleneck. The usual cause is a cheap shared plan where hundreds of sites fight over one server.
Some links below are affiliate links. If you buy through one, I earn a commission at no extra cost to you, and I only list things I would set up for a paying client.
For small business sites I usually move people to a managed WordPress plan with built in server level caching, for example Hostinger. The point is not the brand. The point is that server level caching and a modern PHP version solve TTFB in an afternoon, while plugin tuning on bad hosting can eat a week and still fail.
One honest warning. Changing host will not fix an INP problem. That is the next section, and no host can fix it for you.
Step 3: Cut your image weight
Images are usually the largest part of that 2,894 KB median page. They are also the easiest thing to fix, because you do not need a developer.
Do it in this order, and the order matters. Resize first, then compress. Compressing a 4000 pixel wide photo down to 200 KB still sends a 4000 pixel image to a phone that only has room for 400 pixels. Resize it to the width it will actually display, then compress.
Our free tools do both steps in the browser, so nothing is uploaded to a server you do not control. Use the Bulk Image Resizer to set the real display width, then the Smart Image Compressor to bring the file size down. For newer, lighter files, the PNG to WebP Converter usually saves another 25 to 35 percent over a PNG at the same visual quality.
Stop paying for lazy loading plugins
This one saves people money. WordPress already does the two main image loading tricks by itself.
Since version 6.3, core WordPress marks the likely hero image as high priority so the browser fetches it early, and it deliberately does not lazy load the first three images on the page. The WordPress core team’s own write up says this priority hint typically improves LCP by 5 to 10 percent on its own.
So a plugin that promises to lazy load your images is duplicating work core already does. Worse, some of them lazy load the hero image, which is exactly the one image you want loaded immediately. I have seen a site get faster by deleting its image optimisation plugin.
Step 4: Fix the JavaScript that ruins INP
This is the step almost every guide skips, and it is where WordPress sites quietly lose. INP measures the delay between a visitor tapping something and the screen changing. The cause is JavaScript, usually from plugins and page builders, keeping the browser busy.
A cache plugin cannot help here. Caching makes the server send the page faster. It does not reduce the amount of code the phone has to run once the page arrives.
Here is the audit I run on client sites. It takes about an hour.
- List every active plugin and write next to each one the last date it did something useful for the business.
- Deactivate anything with no recent answer. Social sharing buttons, old sliders, abandoned form builders, analytics you never open.
- Check which plugins load their code on every single page. A contact form plugin should not load on your blog posts.
- Look hard at your page builder. Builders ship JavaScript on every page, whether that page uses the features or not.
- Re-measure field data after 28 days, because field data is a rolling average and will not move instantly.
Step 5 is the part people hate. Field data takes four weeks to catch up. If you change something today and the number has not moved tomorrow, that is normal, not failure.
Step 5: Add caching last
Caching saves a finished copy of your page so the server does not rebuild it for every visitor. It is genuinely useful. It is just not step one.
Install one cache plugin. One. Two cache plugins fight each other and produce broken pages that are hard to debug. If your host already does server level caching, you may not need a plugin at all.
Turn features on one at a time and check the site after each. Minification and combining files are the two settings most likely to break a layout quietly on mobile only.
What should you skip?
| Common advice | Worth it? | Why |
|---|---|---|
| Switch to PHP 8.3 | Yes, do it today | Free, two clicks, helps every page |
| Resize images before upload | Yes | Biggest single weight saving |
| Delete unused plugins | Yes | The only real fix for INP |
| One cache plugin | Yes, after the above | Helps TTFB and LCP |
| A separate lazy loading plugin | No | Core already does it, and better |
| Chasing a 100 lab score | No | Google uses field data, not the lab number |
| Two or three speed plugins together | No | They conflict and hide the real cause |
How long does this take?
For a normal small business site, about two working days of real effort. Half a day to measure and switch PHP. Half a day on images. One day on the plugin audit, because you have to test after each removal.
Then you wait 28 days for the field data to catch up. That waiting period is why this work gets abandoned halfway. Put a reminder in your calendar for four weeks out and go do something else.
Related reading
- Smart Image Compressor, for cutting file size without a visible quality drop.
- Bulk Image Resizer, for fixing a whole folder of oversized photos at once.
- PNG to WebP Converter, for lighter image files on modern browsers.
If you have worked through this list and your site is still slow, the problem is usually structural: a theme fighting a page builder, or a plugin stack that grew for five years without anyone pruning it. That needs someone to open the hood rather than read another checklist. I build and repair business systems like this for clients, so if you want the audit done properly, get in touch and tell me what is slow.