by
Kostya Tereshchuk
4.9 (29 reviews)
Prevent Browser Caching
Prevents browser cache problems: visitors always get the current version of your CSS, JS, images and pages, while caching keeps working.
Prevent Browser Caching ranks #1,856 among WordPress.org plugins with 10,000+ active installations, is #208 of 4,943 in the Utilities & Tools category, a 4.9/5 rating from 29 reviews, and was last updated Aug 21, 2026. Data from WordPress.org, refreshed twice daily — see methodology.
Compatible with WP 7.1
v3.2.1
Current Version v3.2.1
Updated 3 weeks ago
Last Update on 21 Aug, 2026
Refreshed 11 hours ago
Last Refreshed on
#208 of 4,943 in Utilities & Tools
Top 5% by installs
Downloads -19.3% this week
Actively maintained
Rank
#1,856
+1 this week
Active Installs
10K+
-31.6%
KW Avg Position
27.2
0.2 better
Downloads
109.7K
+48 today
Support Resolved
100%
—
No change
Rating
98%
Review 4.9 out of 5
4.9
(29 reviews)
Next Milestone 20K
10K+
20K+
436
Ranks to Climb
-
Growth Needed
8,000,000
Active Installs
Pro
Unlock Exact Install Count
See the precise estimated active installs for this plugin, calculated from real-time ranking data.
- Exact install estimates within tiers
- Track install growth over time
- Milestone progress predictions
Need 5,437 more installs to reach 20K+
Rank Changes
Current
#1,856
Change
Best
#
Downloads Growth
Downloads
Growth
Peak
Upgrade to Pro
Unlock 30-day, 90-day, and yearly download history charts with a Pro subscription.
Upgrade NowReviews & Ratings
4.9
29 reviews
Overall
98%
5
28
(97%)
4
0
(0%)
3
1
(3%)
2
0
(0%)
1
0
(0%)
Support Threads Overview
Resolved
Unresolved
1
Total Threads
1
Resolved
0
Unresolved
100%
Resolution Rate
Security History
Source: WPVulnerabilityNo known vulnerabilities on record for Prevent Browser Caching. Checked 3 days ago.
Track This Plugin
Get detailed analytics, keyword tracking, and position alerts delivered to your inbox.
Start Tracking FreePlugin Details
- Version
- 3.2.1
- Last Updated
- Aug 21, 2026
- Requires WP
- 4.7+
- Tested Up To
- 7.1
- PHP Version
- 7.2 or higher
- Author
- Kostya Tereshchuk
Support & Rating
- Rating
- ★ ★ ★ ★ ★ 4.9
- Reviews
- 29
- Support Threads
- 1
- Resolved
- 100%
Keywords
Upgrade to Pro
Unlock keyword rankings, search positions, and detailed analytics with a Pro subscription.
Upgrade NowSimilar Plugins
Adminify – White Label, Admin Menu Editor, Login Customizer
6K+ installs
#2,756
Master Addons for Elementor – Elementor Addons, Widgets, Mega Menu Builder, Popup Builder, Widget Builder & Template Kits
30K+ installs
#1,007
Elementor Website Builder - more than just a page builder
10M+ installs
#1
Contact Form 7
10M+ installs
#3
All-in-One WP Migration and Backup
5M+ installs
#10
UpdraftPlus: WP Backup & Migration Plugin
3M+ installs
#15
WPCode - Insert Headers and Footers + Custom Code Snippets - WordPress Code Manager
3M+ installs
#19
Hostinger Tools
3M+ installs
#20
WordPress Importer
2M+ installs
#23
WPS Hide Login
2M+ installs
#27
TL;DR
AI summary of the plugin's readmeThis plugin is for WordPress site owners who update their CSS, JS, images or pages and don't want visitors stuck viewing cached old versions. It solves that by automatically versioning assets and refreshing browser and page caches so changes appear immediately without disabling caching altogether.
- Automatic CSS & JS versioning
- Image versioning in Media Library
- HTML page freshness checks
- One-click update versions button
- Page cache purge integration
- Long-term browser caching headers
- Auto refresh after plugin updates
- WP-CLI commands and AI agent abilities
Frequently Asked Questions
Common questions about 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.
