WP Rocket Setup Guide: The Exact Settings I Actually Use

A client’s services site was fine content wise, clear messaging, decent copy, but it felt slow the moment you clicked through. Pages were taking four to five seconds on desktop, worse on mobile. Here’s exactly what I changed, in order, and the real numbers before and after.

Where it actually started

The homepage was taking 4.2 seconds to fully load on desktop, 6.8 seconds on mobile. Not broken, just slow enough that you could feel it while you waited.

Every image was full size and uncompressed, and there was no caching layer at all, so the server was rebuilding the whole page from scratch on every single visit.

PageSpeed Insights gave it a 42. Unused JavaScript, unoptimised images, no caching, render blocking resources, the usual list you get when nobody’s ever installed a speed plugin.

The client hadn’t done anything wrong, they just genuinely didn’t have anything handling this side of things, which is more common than you’d think on a site that otherwise looks perfectly professional.

Why I didn’t just leave it

Slow pages lose visitors before they’ve even seen the offer, and Google factors speed into rankings on top of that.

With a site only pulling in around a hundred visitors a month, losing even a portion of those to load time alone felt like an easy thing to fix rather than something to keep putting off.

Getting it installed

Installation itself takes about two minutes, buy the licence, install the plugin, activate it, drop your licence key in. Nothing technical about that part at all.

That said, if you want to see what actually goes wrong when it isn’t quite that clean, worth reading my own install on this exact site, plugin conflict warning and all.

Step one: turn on caching

Caching is the actual core of what WP Rocket does, it stores a static version of each page so WordPress isn’t rebuilding it from the database every single time someone lands on it.

I went into the Caching section and switched on page caching, left the default settings as they were rather than second guessing them.

This was the single biggest win out of everything. Once a page is cached, a visitor gets a pre built static file instead of WordPress running queries and PHP processing live, which is most of where the original load time was going.

Step two: image optimisation and lazy loading

The images on this site were the other obvious problem, uncompressed JPEGs and PNGs where a 500KB image was loading at closer to 2MB.

Turning on image optimisation inside WP Rocket compresses that down without any visible quality loss, and I left it on the default compression level.

Lazy loading went on at the same time, so images further down the page only load once someone’s actually scrolled to them, rather than every image on the page loading up front whether it’s visible yet or not.

Step three: GZIP compression

GZIP compresses the actual text your site sends out, the HTML, CSS, and JavaScript, before it reaches the browser.

This one’s a single toggle under File Optimisation, and the difference in file size was immediate, a page that was sitting around 300KB uncompressed dropped to roughly 80KB.

Step four: minify and delay unnecessary code

A handful of plugins on this site were loading CSS and JavaScript that barely got used.

Turning on CSS and JavaScript minification strips out the unnecessary characters in those files without breaking anything, and I also switched on delaying JavaScript that isn’t critical to the initial page render, so the page visibly appears before every script has finished loading.

If you want a deeper walkthrough of which of these settings are genuinely safe versus the ones that need testing first, that’s exactly what this settings breakdown covers, using a different site as the example.

Step five: CDN, and why I skipped it here

A CDN keeps copies of your site on servers around the world so visitors load from whichever one’s closest to them.

WP Rocket can connect to one, but for this particular site I left it out, since the improvement from caching and image handling alone was already substantial enough that it wasn’t needed yet. Worth adding later if speed is still an issue after everything else, not something to reach for first.

Step six: preloading the cache

The last thing I turned on was cache preloading, which has WP Rocket visit your own pages in the background and build the cached version before a real visitor ever hits them.

That way nobody’s ever the unlucky first person to load an uncached page.

What actually changed

After going through all six steps, the same homepage that took 4.2 seconds on desktop was down to 1.8. Mobile went from 6.8 seconds to 2.9.

That’s not a dramatic ten times faster claim, it’s a real two to three second improvement across the board, which is genuinely what most of these fixes deliver.

PageSpeed Insights moved from 42 up to 78. Traffic ticked up slightly too, from around a hundred visitors a month to somewhere around 115 to 120 over the following couple of months, though I wouldn’t claim that’s purely down to speed, plenty of things move at once on a live site.

What did shift clearly was bounce rate, fewer people leaving the moment they landed.

For a second, independently verified example of these same kinds of gains, including the honest mobile-versus-desktop gap that doesn’t always show up in a single dashboard, here’s the real Core Web Vitals breakdown from my own site.

What this doesn’t fix

Speed didn’t create ranking miracles here, the site held roughly the same position for its existing keywords, since speed is one ranking factor sitting alongside a lot of others.

It also can’t fix a genuinely underpowered host, or a site that’s fast but has nothing worth reading on it. WP Rocket fixed the speed problem specifically. It didn’t fix anything else that happened to also be sitting there.

Where people usually go wrong with it

The most common mistake is installing it and leaving every setting on default without actually going through them, which sometimes works fine and sometimes leaves real performance sitting unused.

The second is expecting it to fix problems it was never built for, bad hosting, a heavy unoptimised video, genuinely bad code, it optimises what it can within real limits.

And the third is not checking afterward, run the speed test again once you’re done, since if the numbers haven’t moved, something else is probably blocking it and worth tracking down.

Where I actually landed on it

WP Rocket handles caching, image compression, file optimisation, and lazy loading properly, and it does it without needing you to already know what any of those terms mean going in.

It’s not the only speed plugin out there, but it’s the one that got this particular site from a 42 to a 78 in under an hour of actual setup work.

The cost is the real trade off, it isn’t free, but weighed against how much a slow site quietly costs in lost visitors, it’s paid for itself on every client site I’ve put it on.

Expect two to three times faster if a site was genuinely slow to start with, closer to a twenty to thirty percent bump if it was already reasonably quick. Either way, it’s one real piece of a working site, not a replacement for having decent content or a clear offer sitting behind it.

For the full review with more detail on when it’s worth paying for, that’s covered in the WP Rocket review. If you’re still deciding between this and a free stack, WP Rocket vs Free Plugins walks through that comparison honestly. And for the technical foundation to pair alongside speed, the Rank Math setup guide covers that side of things.

Numbers and settings were accurate at the time of writing. Always check the current version of the plugin’s settings before following along step by step.