Your WordPress site feels slow, and every speed plugin promises a perfect score.
Short answer: to speed up a WordPress site, serve cached HTML, delay scripts readers don’t need yet, and upload right-sized WebP images. Fix hosting only if uncached pages still crawl.
We measured it on our own blog. Bypassing the page cache took one post from 13 requests to 140, and mobile LCP from 2.5 to 4.6 seconds.
The catch? Part of what looks fixed is only waiting for the first scroll.
What we measured on DroidCrunch (and what we didn’t)
We tested our own live posts with Lighthouse and curl on 29 October 2026, from a server in Seattle. The stack is ordinary: WordPress on a LiteSpeed server at Hostinger, Cloudflare in front, WP Rocket for caching and bunny.net for images.
The trick is a query string. WP Rocket doesn’t serve its cached copy for a URL like /your-post/?test=123, so you see the page as WordPress builds it. That gave us two versions of one post, minutes apart:
| What we measured | Cache bypassed | WP Rocket cache |
|---|---|---|
| Time to first byte (median, 15 runs) | 0.95 s | 0.36 s |
| Mobile Lighthouse score (2 runs) | 53 and 58 | 86 and 95 |
| Mobile LCP | 4.6 to 5.2 s | 2.5 to 3.3 s |
| Layout shift (CLS) | 0.29 | 0 |
| Requests on first load | 140 to 142 | 13 |
| Data on first load | 1.9 MB | 286 KB |
We didn’t test other hosts, NitroPack or LiteSpeed Cache, and these are lab numbers from one city, not your readers.
Notice the cached scores, too: 86, then 95, two minutes apart. Never trust one Lighthouse run.
Disclosure: we earn a commission if you buy WP Rocket, Hostinger or WP Engine through our links. It doesn’t change the price you pay.
Before you change anything, measure what Google measures
Google judges speed on three Core Web Vitals from real Chrome visits: LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, at the 75th percentile.
PageSpeed Insights shows two kinds of data. The top block is 28 days of real visitors. The score below it is a lab simulation of a mid-range phone on a slow network.
Search Console uses the real-visitor data. Lighthouse can’t even measure INP, because nobody taps the page in a lab run.
Next, time your server. Google’s web.dev guide puts a good time to first byte at 0.8 seconds or less. Run both loops from your own computer:
# Normal URL (served from cache if your page cache works)
for i in 1 2 3 4 5; do curl -s -o /dev/null -w '%{time_starttransfer}\n' https://example.com/; done
# Random query string (how fast WordPress builds the page)
for i in 1 2 3 4 5; do curl -s -o /dev/null -w '%{time_starttransfer}\n' "https://example.com/?nocache=$RANDOM"; doneFast first loop, slow second? Your cache works, but your host builds pages slowly. Both slow means no page cache is serving.
Real-world tip: test in a private window. Logged-in users usually skip the page cache, so your admin view is your site at its slowest.
Fix 1: serve cached HTML instead of rebuilding every page
A page cache saves each page’s finished HTML, so WordPress skips PHP and database work for most visitors. On our posts, it cut the median first byte from 0.95 to 0.36 seconds.
That’s 0.6 seconds saved before the browser sees anything. Which cache? Start with what your host already runs.
- LiteSpeed servers, common on shared hosting: the free LiteSpeed Cache plugin talks to the server cache directly.
- Managed WordPress hosts such as WP Engine and Kinsta cache at the server, so you skip the plugin. Our WP Engine vs Kinsta comparison shows how each one handles it.
- Everyone else: a cache plugin. We use WP Rocket, which lists at $5 a month, billed yearly, for one site and has a 14-day free trial.
A confession: our server runs LiteSpeed and we still use WP Rocket. We haven’t benchmarked the two there, so we won’t call a winner.
One rule beats any brand: run one page cache, not two. Two layers caching the same HTML make purges unpredictable.
Cloudflare has a catch: it doesn’t cache HTML by default. Our pages come back marked cf-cache-status: DYNAMIC, so every visit still fetches HTML from our server.
Fix 2: get CSS and JavaScript out of the text’s way
Render-blocking files make the browser wait before it paints a single word. Our bypassed post loaded 39 stylesheets and 71 scripts, and Lighthouse put the render-blocking cost at 1,040 milliseconds.
Two WP Rocket features did most of the work. Remove Unused CSS trims each page to the CSS it uses and inlines it, so the cached post had zero stylesheet files to wait for.
Delay JavaScript holds scripts back until the reader first taps, scrolls or moves the mouse. Total Blocking Time fell from 80-92 milliseconds to zero, and layout shift from 0.29 to zero.
That shift was our whole post jumping as late CSS arrived. Here’s the setup that stopped it:
The WP Rocket settings we run on DroidCrunch
Read from our live settings on 29 October 2026. Turn them on one at a time and check the page after each.
-
Step 1 of 6
Cache
Keep the page cache on and enable the separate cache for mobile devices.
-
Step 2 of 6
File Optimization: CSS
Minify CSS and turn on Remove Unused CSS. We leave file combining off.
-
Step 3 of 6
File Optimization: JavaScript
Minify JavaScript, load it deferred and turn on Delay JavaScript execution. We exclude jQuery from deferral because our theme needs it early.
-
Step 4 of 6
Media
LazyLoad images, iframes and CSS background images, and add missing image dimensions so nothing jumps.
-
Step 5 of 6
Preload
Preload the cache and preload links, so the first visitor after a purge doesn’t get the slow version.
-
Step 6 of 6
Test logged out
In a private window, click everything that moves: menu, search, forms. If one breaks, exclude that script from Delay JS rather than switching the feature off.
Fix 3: delaying isn’t deleting, so cut scripts you don’t need
Delay JavaScript makes the first screen fast, but the scripts still download the moment a reader scrolls. Lighthouse never scrolls, so your score never sees it.
We checked. Our cached post loaded 12 requests (248 KB) before any interaction. One mouse move and one scroll later, it had pulled 111 requests and about 1.5 MB.
The bypassed version weighed 1.9 MB. So after the first scroll, our optimised page was only about 17% lighter.
Delay JS changes when the bytes arrive, not whether they arrive.
On our post, the biggest chunks were two Google tag scripts (324 KB together) and a reCAPTCHA script with about 180 KB of unused code. Elementor Pro scripts load too, on posts Elementor didn’t build. All of them start running on the reader’s first tap, the exact moment INP measures.
Find yours in Chrome DevTools. Open the Network tab, reload, scroll once and sort by size. Then ask of each third-party domain: does this page need it?
- Load form, chat and reCAPTCHA scripts only on pages that show a form or a chat.
- Keep one analytics tag unless you know why there are two.
- Unload page-builder scripts on posts the builder didn’t make.
We haven’t trimmed ours yet. It’s next on our list, and worth more than any cache setting we haven’t tried.
Fix 4: shrink images before WordPress sees them
Resize every image to the width your theme shows, then save it as WebP or AVIF. Size beats format, and our test on older DroidCrunch images shows by how much:
| Image | Original | After |
|---|---|---|
| 1,804 px JPEG | 127 KB | 45 KB as WebP, 28 KB at 1,200 px |
| 2,560 px WebP | 113 KB | 95 KB re-encoded, 39 KB at 1,200 px |
| 1,024 px sidebar banner (JPEG) | 97 KB | 57 KB as WebP, 48 KB as AVIF |
Look at the second row: re-encoding a huge image saved 16%, resizing it saved 65%.
Our new images go up as 1,200-pixel WebP files of 40 to 55 KB, and the library now holds 4,716 WebP files to 1,438 JPEGs.
For an existing library, a bulk optimiser converts everything for you. Our ShortPixel review covers one option, and our roundup of image optimization tools compares the rest.
Then check lazy loading: below-the-fold images should load late, but never your top image. WordPress 6.3 and later gives the likely main image fetchpriority="high" and skips lazy loading for it, unless a plugin overrides that.
Our own surprise: the heaviest image on the optimised post was the author’s Gravatar, a 45 KB PNG for an 80-pixel slot. A small local avatar would fix it.
Fix 5: put static files on a CDN, and know its limits
A CDN copies your images, CSS and JavaScript to servers near your readers. Ours is bunny.net, with files cached for a year.
From Seattle, one 49 KB image arrived in 37-70 milliseconds from bunny.net and 85-202 through our main domain. Both were cache hits, so the gap is mostly distance. Readers far from your server gain most.
A CDN won’t fix slow HTML or make PHP faster. For static files, Cloudflare’s free plan is an easy start, and WP Rocket bundles free RocketCDN cover for three key pages.
Fix 6: upgrade hosting when uncached pages stay slow
Hosting sets how fast WordPress builds uncached pages: logged-in views, carts, checkout, search and the first visit after a purge.
Our uncached median was 0.95 seconds, above web.dev’s 0.8-second guide. A blog can live with that, since nearly every reader gets the cached copy. A WooCommerce store, where carts skip the cache, can’t.
Check two things before you move:
- PHP version. WordPress recommends PHP 8.3 or newer, which we run. Your host’s panel shows yours.
- Persistent object cache. Redis or Memcached keeps database results in memory between requests. Our server has both PHP extensions, unused so far, and that’s the next fix we’d try on that 0.95 seconds.
Still over a second after that? The server is the limit. OurHostinger review explains why we moved 20 sites to Hostinger. Stores that want managed caching and staging should look at WP Engine instead.
New to the jargon? Our guide to how web hosting works explains shared, VPS and managed plans.
Fix 7: clean up the database you never look at
WordPress loads every autoloaded option on each uncached request. Since version 6.6, Site Health flags it as critical once those options pass 800 KB.
Ours sit at about 1.3 MB, beside 4,150 stored revisions. Revisions mostly bloat the database and backups; the autoload total slows every page WordPress builds.
Take a backup first (our list of WordPress backup plugins has options). Then list the biggest autoloaded options:
SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY bytes DESC
LIMIT 20;Options left by deleted plugins are the usual culprits; look up anything you don’t recognise before removing it. To cap revisions, add one line to wp-config.php:
define( 'WP_POST_REVISIONS', 10 );We haven’t cleaned ours yet either. When we do, we’ll rerun the uncached test and publish the difference.
Which fix should you do first?
Match the fix to the symptom you measured:
| If you see this | Do this first | Because |
|---|---|---|
| Both curl loops slow | Add one page cache | Nothing serves cached pages yet |
| Fast first byte, slow mobile LCP | Remove Unused CSS, Delay JS | Files block the first paint |
| Good score, heavy page after a scroll | Cut third-party scripts | Delayed scripts still download |
| Big images in the Network tab | Resize, then convert to WebP | Size beats format |
| Store or member pages over 1 s uncached | Object cache, then better hosting | Those pages skip the cache |
Our take: most blogs get the bulk of the gain from the first two rows. Hosting is the last fix to pay for, not the first.
Frequently asked questions
Does the number of plugins slow down WordPress?
Not by itself. What matters is what each plugin loads on the front end. We run 33 active plugins, and most never touch a visitor’s page. One form or chat plugin that loads scripts everywhere costs more than ten admin-only plugins. Check the Network tab, not the plugin count.
Is WP Rocket worth it if my host already has LiteSpeed Cache?
Start with the free LiteSpeed Cache if your host runs LiteSpeed, and measure. WP Rocket earns its yearly fee when you want Remove Unused CSS and Delay JavaScript set up from one simple panel. We use it on a LiteSpeed server, but we haven’t benchmarked the two head to head.
Should I combine CSS and JavaScript files into one?
Usually not. Our site, like most hosts today, serves pages over HTTP/2, which loads many small files in parallel over one connection. Combining saves little there and is a common cause of broken scripts. We leave combining off in WP Rocket and let Remove Unused CSS do the heavy lifting.
Do I need to clear the cache every time I update a post?
Not with a good cache plugin. WP Rocket clears an updated post’s cache, along with the pages that list it, on its own. Clear everything after you change the theme, menus, widgets or site-wide CSS, because those touch every cached page at once.
How long until Search Console shows better Core Web Vitals?
About a month. Search Console reports a rolling 28 days of real Chrome visits, so a fix shows up gradually as old visits drop out. If you click Validate Fix, Google watches the affected URLs for 28 days before it marks the issue passed.
Will a faster WordPress site rank higher on Google?
Speed helps, but it won’t beat better content. Google says good Core Web Vitals align with what its ranking systems reward, as one part of page experience. Fix speed so readers stay, and don’t expect a ranking jump from a faster score alone.
Should I use AVIF instead of WebP for WordPress images?
Only if your server supports it. In our test, AVIF files came out 10 to 16% smaller than WebP. WordPress 6.5 and later handles AVIF when the server’s image library does; check Tools, Site Health, Info, Media Handling. WebP stays the safer default for most sites.
The bottom line
To speed up WordPress, measure first, then fix in order: one page cache, unused CSS and delayed scripts, right-sized images, a CDN, and hosting last.
A blog on decent shared hosting gets most of the gain from a cache plugin and smaller images. A store or membership site should watch its uncached response time and look at hosting sooner.
One warning: a green Lighthouse score can hide a heavy page. Run the two curl loops on your own site today, then scroll it once with DevTools open and count what loads.
