The settings that move Core Web Vitals are off by default and break things when switched on carelessly. Delay JavaScript, unused CSS and preload, tuned against your plugin stack and tested before anyone touches live.
WP Rocket’s defaults are safe rather than fast. The settings that actually move Core Web Vitals, delay JavaScript execution and remove unused CSS, ship switched off because they break things when configured carelessly. A WP Rocket expert builds the exclusion and safelist entries your specific plugin stack needs. Most configuration jobs take half a day to two days, quoted at a fixed price within 48 hours after the discovery call.
WP Rocket sells itself on being simple, and it is, right up until the point where simple stops being enough. Activation gives you page caching, GZIP and a handful of safe defaults. That is worth having and it is not what people bought it for. They bought it because a score was red and they wanted it green.
The features that turn a score green are the ones switched off in a fresh install. Delay JavaScript execution takes scripts off the critical path entirely and is the single biggest improvement the plugin can deliver. Remove Unused CSS strips stylesheet weight that never gets used. Both of them will also break your site if you enable them and walk away, which is exactly why they ship disabled.
So a WP Rocket expert is really doing exclusion work. Which scripts must run immediately for the slider to initialise. Which CSS selectors are applied by JavaScript and therefore invisible to the unused-CSS analyser. Which pages must never be cached because they show something different to every visitor. None of that is guessable from a settings screenshot, and it is why copying a configuration from a blog post produces a broken site rather than a fast one.
Worth saying plainly before you spend money: if your host runs LiteSpeed, you probably do not need WP Rocket. LiteSpeed Cache is free, caches at server level rather than inside PHP, and generally outperforms it. Hostinger, and plenty of others, run LiteSpeed. I would rather tell you that than configure a plugin you did not need. The Core Web Vitals documentation is the standard everything here gets measured against, whichever plugin ends up doing the work.
Six areas that separate a configured install from an activated one.
Every panel reviewed against your actual plugin stack rather than a settings screenshot from a blog post. Baseline measured first so the improvement is a number, not an impression.
The biggest single win WP Rocket offers, and the easiest to break. Exclusion lists built by testing every interactive element rather than guessing which ones matter.
RUCSS enabled with a safelist covering the selectors it cannot detect: JavaScript-applied classes, hover states, and anything that appears after interaction.
Preloading tuned to your sitemap and traffic rather than left on defaults, so real visitors hit a warm cache instead of generating it.
Two caching plugins fighting, host-level caching duplicating the page cache, leftover rules in configuration files from a plugin that was deactivated but never removed.
Cart fragment handling, checkout exclusions verified against a real purchase, and dynamic pricing tested so nobody is served last week’s price.
Related service pages: WordPress speed optimization, Core Web Vitals optimization, and maintenance plans.
If more than two of these are true, the licence is not doing what you paid for.
Send me the URL. I will tell you what your host already caches, whether WP Rocket is duplicating it, and if a free alternative would do the job better. That answer is free even when it costs me the work.
Get a Free Caching ReviewFour principles that keep a caching job from becoming an outage.
Without a starting number, every result afterwards is an opinion. So the first step is field data from the Chrome UX Report where traffic supports it, a lab run on a throttled mid-range device, and a note of which metric is actually failing.
That last part matters more than the overall score. A site failing LCP needs different work from one failing INP, and caching helps one far more than the other. Optimising the metric that was already passing is how people spend a week and move nothing.
Two page caches is the most common broken-caching setup I inherit, and it produces symptoms that look random: stale content for some visitors, a logged-in user seeing a cached guest page, a store showing an empty cart. Each cache is doing its job and neither knows the other exists.
Removing the loser means deleting the plugin rather than deactivating it, then clearing what it left behind in your configuration files. Several caching plugins write rules there and leave them on deactivation, which is why sites keep misbehaving after the plugin is supposedly gone. If the move is between plugins or hosts, that runs alongside migration work.
Delay JavaScript and Remove Unused CSS both produce real gains and both break things. Switching them on together means you know something is broken without knowing which change did it.
So it is one at a time, on staging, with a test pass across every interactive element afterwards: sliders, tabs, accordions, forms, filters, add-to-cart and the full checkout. On a store I place a real test order. A caching configuration that has not survived a purchase has not been tested. That applies doubly on WooCommerce builds.
Caching makes delivery fast. It does nothing about a 4MB hero image, a theme loading twelve font weights, a database nobody has cleaned in three years, or hosting that is simply undersized. Layering a cache over those problems hides them from you and not from a visitor on mobile data.
When the audit finds that caching is not the bottleneck, I say so rather than configuring around it. The work moves to whatever actually is, which is usually images, plugin count or the database. That is the speed optimization engagement rather than a caching job.
Four ways to engage, depending on whether something is unconfigured, broken, or part of a wider performance problem.
| Model | Suits | How it works | Typical timeline |
|---|---|---|---|
| Configuration job | WP Rocket installed but not configured | Audit, configure, test, before-and-after report | Half a day to 2 days |
| Conflict fix | Something broke after enabling a feature | Diagnosis first, quoted per job | Often resolved same day |
| Full speed engagement | Caching is one part of a bigger problem | Images, database, hosting and assets together | 1 to 2 weeks |
| Maintenance plan | Keeping it configured as the site changes | Monthly, includes re-testing after updates | Live sites that matter |
Most work is quoted fixed-price, so you know the number before anything begins.
Delay JavaScript, unused CSS, plugin conflicts, WooCommerce, Cloudflare, and whether you need it at all.
Free 30-minute call. Send me the URL and I will tell you what is misconfigured, what is conflicting, and whether the plugin is even the right choice for your host.
