WP Rocket Settings: Get More From What You Already Paid For
WP Rocket is the most popular premium caching plugin on WordPress. Most people install it, tick a few boxes, and assume the job is done. It isn't. The default configuration leaves a significant amount of performance on the table. This guide covers the specific settings that actually reduce load times, improve Core Web Vitals scores, and do the work most installs quietly skip.
On this page
- Why the Default Install Is Not Enough
- File Optimisation Settings Worth Switching On
- Media Settings That Cut Load Time Without Quality Loss
- Preloading and Prefetching: What Each One Does
- The Database Optimisation Tab Most Users Never Open
- CDN and Cloudflare Integration Done Right
- Testing and Validating Your Configuration
Why the Default Install Is Not Enough
WP Rocket ships in a deliberately cautious state. The moment you activate it, a handful of foundational features switch on automatically, basic page caching, cache preloading, and browser caching being the main ones. That sounds like a lot, but the settings that move the needle most on Core Web Vitals and PageSpeed scores stay completely off until you enable them yourself. The developers made this choice intentionally, because aggressive optimisations applied blindly can break poorly coded themes or conflict with certain plugins.
The real performance gains come from the features buried inside the dashboard that nobody prompts you to turn on.
LazyLoad for images and iframes is off by default. JavaScript deferral is off. CSS and JS file minification is off. Database optimisation runs on no schedule until you set one. If you install WP Rocket, get a modest score bump from the automatic settings, and leave it there, you are genuinely using about a third of what the plugin can do. Understanding which WP Rocket settings to enable, and in what order, is where the actual work begins.
File Optimisation Settings Worth Switching On
WP Rocket settings under File Optimisation give you some of the biggest performance gains on the page, but not every option is safe to enable without testing. CSS and JS minification strip out whitespace and comments from your files, reducing their size without changing what they do. Combining CSS delivery merges multiple stylesheets into a single request, which cuts round trips to the server. Both are generally safe starting points, though a complex theme with lots of third-party styles can occasionally produce layout shifts, so check your front end after enabling them.
Remove Unused CSS and Defer JS Loading are the two options that need the most care. Remove Unused CSS tells WP Rocket to load only the stylesheet rules a given page actually uses, which can dramatically shrink render-blocking CSS, but it sometimes strips rules your site needs, especially on dynamic elements like sliders or popups. Defer JS Loading delays non-critical scripts until after the page renders, which improves time to first interaction noticeably, but poorly coded plugins can break when their scripts load out of sequence. Test both on staging before pushing to production.
Media Settings That Cut Load Time Without Quality Loss
Lazy loading is one of the highest-impact WP Rocket settings you can enable, and it costs nothing in visual quality. When lazy loading is active, images and iframes below the fold only load as a visitor scrolls toward them, which means the browser spends its initial resources on what’s actually visible. On image-heavy pages, this directly improves Largest Contentful Paint scores because the critical above-the-fold content gets full bandwidth rather than competing with a dozen off-screen images loading simultaneously. Disable it, and Google’s Core Web Vitals report will tell you about it.
WebP compatibility works alongside lazy loading rather than replacing it.
WP Rocket doesn’t convert images to WebP itself, but it serves WebP versions automatically when your image plugin, such as Imagify or ShortPixel, has already generated them. A product page carrying thirty JPEG thumbnails can shed a significant portion of its image payload simply by switching to WebP delivery, with no visible difference to the user. If you’re already investing time in reducing server response time, skipping WebP and lazy loading leaves a sizeable performance gain on the table that no amount of server optimisation can recover.
Preloading and Prefetching: What Each One Does
Cache preloading tells WP Rocket to visit your pages and build their cached versions before a real visitor arrives, so nobody ever loads an uncached page cold. Sitemap-based preloading extends that idea by pulling your XML sitemap and walking every URL in it, which is genuinely useful on large sites where you publish frequently and can’t afford the first visitor to a new post eating a slow uncached response.
These two WP Rocket settings work together, preloading keeps the cache warm, and the sitemap ensures that warmth covers the full site, not just pages that have already had traffic. Without both active, a new post published at 9am could sit uncached until someone stumbles across it.
DNS prefetch and preconnect are different beasts entirely. They don’t touch your cache. Instead, they tell the browser to resolve and open connections to external domains, such as Google Fonts or a third-party analytics server, before your page actually needs them. DNS prefetch handles the name lookup, while preconnect goes further and completes the full handshake, cutting the time a browser spends waiting on outside resources. If you’re curious how early-connection work fits into the broader server response and TTFB picture, the two topics overlap more than most people expect. Add preconnect only for domains your page loads on every request, otherwise you’re opening connections that go unused.
The Database Optimisation Tab Most Users Never Open
Most WordPress sites accumulate thousands of post revisions, expired transients, and orphaned metadata within a few months of going live.
WP Rocket settings include a dedicated Database tab that handles all of this, yet it sits unopened on the majority of installs. Post revisions are the worst offender. A site with 500 posts and WordPress’s default unlimited revisions can easily carry 5,000 to 8,000 redundant rows in the wp_posts table, slowing every query that touches it. Clearing those out once makes a measurable difference. Clearing them on a recurring schedule keeps that difference permanent.
The smarter move is to enable the scheduled cleanup and set it to run weekly rather than treating it as a one-off task. Transients in particular regenerate constantly, so a single clean gives you a day or two of breathing room before the table bloats again. Set the schedule, choose your cleanup targets, and let automation handle the maintenance window you would otherwise forget. If you want to understand how other recurring technical tasks affect crawl efficiency, the piece on crawl budget and why big sites lose rankings over it covers the knock-on effects that a sluggish database can trigger upstream.
CDN and Cloudflare Integration Done Right
WP Rocket’s CDN tab is where you tell the plugin to rewrite your static asset URLs, pointing images, scripts, and stylesheets toward your CDN hostname instead of your origin server. That rewriting alone cuts load time for visitors who are geographically distant from your host, because assets are served from a node closer to them.
If you are running Cloudflare, the setup goes a step further. WP Rocket ships a dedicated Cloudflare add-on, found under Settings, that connects directly to the Cloudflare API using your account email, API key, and zone ID. Once connected, WP Rocket can push cache-purge requests to Cloudflare automatically whenever you clear your local cache.
The problem most sites run into is a mismatch between the two cache layers. A user publishes an updated page, WP Rocket clears its own cache, but Cloudflare still serves the old version from its edge nodes because the purge request was never sent, or the API credentials had quietly expired. Visitors see stale content and nobody traces it back to the CDN because the page looks fine in the browser. The fix is straightforward, verify your Cloudflare credentials inside the add-on, set the cache level to “Standard”, and enable “Auto Purge Content” so both layers clear together. If you want to go deeper on how poor server response time and TTFB compound these caching issues, that is worth reading alongside your CDN configuration.
Testing and Validating Your Configuration
Once your WP Rocket settings are in place, you need to confirm they are actually doing what you expect, not just assume the configuration worked. Run a PageSpeed Insights test on a key page and look specifically at the Diagnostics section for “Eliminate render-blocking resources” and “Serve static assets with an efficient cache policy.” If WP Rocket is configured correctly, those warnings should shrink or disappear entirely.
GTmetrix gives you a waterfall view, which lets you see whether your CSS and JS files are loading in a combined, minified form rather than as a long list of individual requests. A before-and-after comparison here is far more telling than a single score. For a deeper look at how server response time affects those results, it is worth checking what your TTFB reading looks like in both tools.
Browser DevTools fills in the gaps that online tools miss. Open the Network tab in Chrome, reload your page with the cache cleared, and filter by “Img” to check lazy loading is triggering correctly. Images below the fold should not appear in the initial request waterfall. Then filter by “JS” and confirm your deferred scripts are loading after the main document, not blocking it. The Response Headers panel on any static asset should show a “Cache-Control, max-age” value in the thousands of seconds if browser caching is set. If you see “no-cache” or a very short max-age, WP Rocket’s browser caching rule is not taking effect and needs investigating.