Prevent Browser Caching

It can only help. In the recommended automatic mode browser caching keeps working at full strength — repeat visitors load CSS/JS from their cache until a file really changes, so repeat views are as fast as ever (faster than the old 2.x default, which re-downloaded assets on every visit). And the opt-in "Speed up" option goes further: one-year caching headers for your static files — the exact fix for the Lighthouse "efficient cache policy" audit. The server cost is a few file-time lookups per page — negligible. The "ver" URL parameter is the same mechanism WordPress core uses, search engines are perfectly used to it, and the plugin does not change your page content, markup or URLs seen by crawlers.

Yes — and since 3.1.0 they can actively cooperate. Versioned asset URLs end up in the cached HTML like any others, so serving stale HTML used to mean serving old asset versions with it. When the "Also clear the page cache" checkbox on the settings page is enabled, pressing "Update versions" (toolbar, settings page, WP-CLI or an ability) also clears the detected page-cache plugin's cache, so that HTML is regenerated with the new versions. Supported: WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, WP Fastest Cache, WP-Optimize, Breeze, Cache Enabler, Hummingbird, SiteGround Optimizer, Swift Performance, Comet Cache. The checkbox is off by default — another plugin's cache is only touched when you say so (for example, if your page cache serves logged-out visitors only, you may prefer not to rebuild it on every update). Either way, the report shown after every update says whether the page cache was cleared, and the version update always completes even if a purge fails. The plugin also keeps leaving HTML cache headers to the page-cache plugin.

Yes. Builders generate their CSS as real files (usually in the uploads folder) and give them a fresh time-based version whenever they regenerate — Elementor, for example, serves its per-page CSS as post-123.css?ver=<generation time>, and that version changes every time the file is rewritten. On top of that, in the automatic mode this plugin adds its own version component from the file's modification time, so even a builder file rewritten in place busts its cache immediately. Together that makes the long-caching option safe for builder files too: their URLs always change when their content does.

Yes — verified against both. Minifiers put a content hash and the source files' modification times into their generated file names, so those files bust their own cache by name — and the long-caching option here is exactly the right policy for them: WP-Optimize's minified CSS/JS get the one-year headers and change URL whenever a source file changes, while Autoptimize serves its cache folder with its own equivalent one-year immutable policy, so the two never fight. Files the minifier leaves untouched keep this plugin's "ver" parameter — even when the minifier's "remove query strings" option is on (this plugin adds its version after them on purpose).

No — and that's by design, not an oversight. In the automatic mode the version comes from the file's modification time, read at the moment a page is rendered; nothing "happens" on the server when you upload a changed file, so there is no event to clear the page cache on. Cached HTML keeps the old asset versions until the page cache expires or is cleared. After bigger changes, press "Update versions" — with the "Also clear the page cache" option enabled, that both updates the versions and clears the detected page cache in one click.

Enable "Let browsers keep static files for a year" in the "Speed up" section of the settings page (available while CSS/JS versioning is on). The plugin serves static files with Cache-Control: public, max-age=31536000, immutable, which is exactly what the audit asks for — and it is safe here, because the plugin changes a file's URL whenever the file changes, so visitors never get stuck with an outdated copy. After enabling, the settings page tells you whether the headers were verified on your site. The same option also resolves the older name of this recommendation — "Leverage browser caching" — still shown by GTmetrix and other testing tools.

Only if you enable the long-caching option, and only using WordPress's own API (the same one core uses for permalinks): a clearly marked block between # BEGIN Prevent Browser Caching and # END Prevent Browser Caching. The block is updated when you change related settings, and removed completely when you turn the option off, deactivate or delete the plugin. On multisite, on nginx, or if you define the PBC_DISABLE_HTACCESS_WRITE constant, the plugin never writes the file — it shows you the rules to add manually instead.

No — manage them in one place. If your caching plugin already serves long-lived headers for static files, you can leave the "Speed up" option here off: versioning keeps everything fresh either way. Nothing breaks if both end up enabled — the rules don't conflict, the later block simply wins — but a single source is cleaner. The advantage of managing them here is that the headers are tied to versioning (URLs change whenever files change, so a year-long cache can never show anyone an outdated file) and the settings page verifies that the headers actually work on your server.

The rules are in place, but your server did not apply them — most often the host's Apache lacks the mod_headers/mod_expires modules, or .htaccess overrides are disabled. Ask your host to enable them, or copy the rules shown on the settings page into the server configuration. Saving the settings re-runs the check. Until the headers work, nothing breaks — browsers simply keep caching the way they did before.

If it is a local CSS/JS file served from your site: yes, the long-caching rules work by file extension and cannot see your exclusion list. Exclusions are almost always external URLs (payment scripts, CDNs), which the rules never touch — but if you exclude a local file because it must not be cached long, either keep the long-caching option off or add a narrower rule for that file in your server configuration.

Several external services — payment scripts in particular (PayPal, Braintree, Authorize.net) — reject requests with an unexpected "ver" query parameter, which used to break checkout forms. Since 3.0.0 only local files are versioned by default; there is a checkbox to include external URLs again if you relied on that.

Not in the recommended automatic mode. Files are cached normally; the version only changes when the file itself changes. The "every time a page loads" mode does disable caching of CSS/JS — use it during active development only.

The legacy "every N minutes" mode works per visitor, using a cookie — it does not rebuild anything on the server by cron. Each visitor gets a new assets version no more often than the chosen interval. Since 3.0.0 the automatic mode is a better choice for almost every case.

Yes, when "Images" is enabled: attachment URLs rendered by WordPress get versions immediately, and image URLs hardcoded in post content get the site-wide media version after the first update (the "Update versions" button or replacing a media file).

Then query-parameter versioning cannot bust that CDN's cache for those files. Configure the CDN to include query strings in its cache key, or use filename-based versioning (e.g. replace a file under a new name).

If you added prevent_browser_caching( ... ) to your theme's functions.php, that line calls a function this plugin provides. Once the plugin is deactivated the function no longer exists, so PHP stops with a fatal error. Two ways to fix it: switch to the pbc_assets_version filter (recommended — it never causes this), or wrap the call in if ( function_exists( 'prevent_browser_caching' ) ) { ... }. See "For developers" above.