WP Rocket: The Caching Plugin Whose Source Is on GitHub

What the plugin is, and why the source is public

WP Rocket is a caching plugin that simplifies the process and helps decrease a website's load time, and the stated aim is to make the web faster one WordPress website at a time. The interesting part for a developer is that the source is published. The repository is described as a place to browse the source and keep track of the plugin's progress, and the readme points non-developers to the documentation instead. The topic tags list what the plugin actually does, with cache, caching, lazyload, minification, database-cleaner and wordpress-performance, which is a useful summary of the feature surface. The project is a commercial product with an open source codebase, and the distinction matters when you read the repository: you can see exactly how a cache is invalidated, but you still need a licence to run it.

Installing with composer, and the two constants it needs

There is a composer path, and it is the one a development team would use.

composer require wp-media/wp-rocket

The install alone is not enough, because to validate the licence and use the plugin you also have to define two constants manually in your wp-config.php file. `WP_ROCKET_EMAIL` is the email for your WP Rocket account, and `WP_ROCKET_KEY` is your API key. These are not optional and not filled in by the installer, so a deployment that adds the composer dependency and forgets the constants ends up with an unlicensed plugin. That is a deployment detail worth putting in your infrastructure as code rather than in a hand-edited config file, and it is the kind of thing that shows up as a support ticket rather than as an error.

The Gulp tasks, and the admin CSS and JS they produce

The front end of the plugin is built with Gulp, and the task table is organised by asset type. The CSS tasks build the full admin CSS in unminified form as wpr-admin.css and in minified form as wpr-admin.min.css, with a task that builds all admin CSS files including the right-to-left variants wpr-admin-rtl.css and wpr-admin-rtl.min.css, and a watch task that rebuilds on change. The JS tasks build the admin app file unminified as wpr-admin.js and minified as wpr-admin.min.js, a separate lazyload CSS file, all of them together, and a beacon script with its source and map file, again with a watch task.

gulp build:saas:unmin
gulp build:js:all

The npm scripts wrap the same thing, with build:css pointing at the sass task and build:js at the js task, and separate watch:css and watch:js entries. The package is named lib-sass and describes itself as compressing and minifying SASS and JS with Gulp, and it carries React and ReactDOM as dependencies alongside Babel, browserify, eslint and the sass toolchain.

The repository layout and the static analysis setup

The top level of the repository shows a mature plugin with a conventional WordPress structure. The entry point is wp-rocket.php, with inc/ for the PHP includes, src/ and views/ for the newer code and templates, assets/ and languages/ for the static resources, tests/ for the test suite, and bin/ for the command line scripts. There are two dynamic list files, dynamic-lists.json, dynamic-lists-delayjs.json and dynamic-lists-incompatible-plugins.json, which are the mechanism by which the plugin can keep its own data current without a release, and licence-data.php alongside a contributors.txt. The quality tooling is visible too, with phpcs.xml for coding standards, a phpstan.neon.dist and a phpstan-baseline.neon pair, a .babelrc, an .editorconfig, a .tx directory for translation tooling, and an AGENTS.md.

The dynamic lists, which are the interesting engineering decision

Those three dynamic list files are worth a second look because they explain how a plugin like this stays current. Rather than baking a list of deferred scripts, incompatible plugins or similar into the release, the plugin can fetch an updated list at runtime. That is the difference between a plugin that knows about the last dozen popular caching conflicts and one that knows about yesterday's, and it is the reason the release cadence of the code does not have to match the pace of the ecosystem. The trade-off is that a feature can change without a version bump, which is a real consideration for anyone who pins plugin versions for reproducibility, and it is a design choice that only works because the lists are data rather than logic. The delayjs list in particular suggests the plugin defers specific JavaScript files, and knowing which ones is a maintenance task that never ends.

Testing, releases and the alpha channel

The badge at the top of the repository points at a workflow named test_wprocket_php8, so the test suite runs on PHP 8, and the presence of both a unit and an integration badge suggests those two levels are separated. The release record shows the shape of the project right now: v3.23.5.1 on 2026-10-02 as the last numbered release, then v3.24-alpha and v3.24-alpha2 on the same day in October 2026, half an hour apart. The default branch is develop, not master, which matches a project that develops on a branch and releases from somewhere else. The alpha tags being published on the same day as the previous stable is normal for an active plugin, and it is worth watching if you pin versions, since the alpha line moves fast.

Security reporting goes through Patchstack, not the tracker

The security policy has a specific route, and it is worth reading because the readme says plainly that the issue tracker is for reporting bugs and not for support. Security bugs found in the source are to be reported through the Patchstack Vulnerability Disclosure Program, with the Patchstack team assisting with verification, CVE assignment and notifying the developers. That arrangement gives you a CVE and a coordinated disclosure date, which a public issue tracker does not. Support itself is handled through a separate support page where you open a ticket, and the readme is explicit that the GitHub issues tracker is not the place to ask for help. The project also thanks BrowserStack for supporting cross-browser testing, which is a small signal about how the plugin is verified before a release.

What a caching plugin actually changes, and where the risks sit

It is worth being blunt about what a plugin like this does to a site, because the same mechanisms that make a page fast also make it break in specific ways. A page cache serves a stored response, so anything that should differ per visitor, per cart or per login has to be excluded correctly, and a mistake there shows up as a checkout serving the wrong customer's basket. Deferred JavaScript reduces blocking scripts but can change the order in which your own code runs. Minification of admin assets is low risk because it is not on the visitor path. Database cleanup removes data, which is the feature that needs the most care before you enable it. None of that is an argument against the plugin, since the same mechanisms are what every caching layer does, but it is the reason the plugin's configuration is the actual product and the code is the part most teams never read.

Editorial conclusion

WP Rocket fits an agency or developer who wants a WordPress performance layer they can inspect, extend and track in version control, rather than a black box plugin. It is the wrong choice for a site that cannot accept a paid licence, and the wrong choice if you need a free alternative with the same feature set, since the features listed here, caching, lazy loading, minification and database cleanup, are the point of the product rather than a bonus. Before you install it through composer, decide where the licence constants live in wp-config.php, because they are required for validation and are not set by the installer.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. wp-media/wp-rocket on GitHub