Features
Browser Caching
Browser caching tells visitors' browsers to store static files (CSS, JavaScript, images, fonts) locally so they do not need to be downloaded again on repeat visits. This typically reduces page load times for returning visitors and reduces bandwidth usage.
How it works
The plugin adds caching headers to your server configuration that tell browsers how long to keep each type of file. When a visitor returns to your site, their browser loads these files from its local cache instead of downloading them again.
Key settings
Set Expires Headers
Adds far-future expiry dates to static assets. Browsers will cache these files for the specified duration, eliminating repeat downloads. This is the most impactful browser caching setting.
GZIP Compression
Compresses text-based assets (HTML, CSS, JavaScript, XML, JSON) before sending them to the browser. Typical compression ratios are 60-80%, meaning a 100KB CSS file becomes 20-40KB in transit. This is supported by every modern browser and server.
Brotli Compression
A newer, more efficient compression algorithm developed by Google. Brotli typically achieves 15-25% better compression than GZIP at the same compression level. Enable if your server supports it — most modern hosts running Apache 2.4+ or NGINX 1.11+ do.
Server compatibility
Apache
Rules are written directly to your .htaccess file. The plugin checks the result and replaces the file in one step; if the file cannot be written, nothing is written at all, and the notice tells you what to add by hand. No backup copy is left on disk.
NGINX
NGINX does not use .htaccess files, so nothing can be written for you. Page caching still works unchanged. Add the browser caching and compression rules to your server block by hand, once: the snippet is in Server configuration. Leaving the Browser Cache settings switched on does no harm on NGINX; they simply have nothing to write to.
LiteSpeed
LiteSpeed is compatible with Apache .htaccess rules. The plugin writes rules as it would for Apache.
IIS
IIS uses web.config rather than .htaccess. Caching Out does not write web.config rules, so browser caching and compression are configured in IIS by you or your host. Page caching works unchanged. See Server configuration.
What gets cached
| File type | Recommended cache duration |
|---|---|
| Images (jpg, png, gif, webp, svg) | 1 year |
| CSS files | 1 year |
| JavaScript files | 1 year |
| Font files (woff, woff2, ttf, eot) | 1 year |
| PDF documents | 1 month |
| HTML pages | Controlled by page cache, not browser cache |
Leftovers from a previous cache plugin
Deactivating and deleting another caching plugin does not always remove everything it created. Typical leftovers:
- Empty marker pairs in
.htaccesssuch as# BEGIN LSCACHEdirectly followed by# END LSCACHE(LiteSpeed Cache), or the W3TC, WP Rocket, WP Super Cache, WP Fastest Cache and Breeze equivalents. An empty pair does nothing; deleting the two lines is safe. - A marker block that still contains rules. Apache keeps applying those
rules, and Caching Out will not write its own Browser Caching rules
while such a block is present – it refuses the write and names the block
rather than mixing two plugins' rules in one file. Back up
.htaccess, delete the block from its# BEGINline to its# ENDline, then save the Browser Caching tab again. - Folders under
wp-contentsuch aswp-content/litespeed/(with its own.htaccess),wp-content/w3tc-config/,wp-content/wp-rocket-config/, and stale cache folders underwp-content/cache/(supercache,all,wp-rocket,breeze-minification,autoptimizeand others). - Configuration files such as
wp-content/wp-cache-config.php.
The Filesystem Check page (Caching Out > Filesystem Check) lists every leftover it recognises with the exact path, what it is, and whether it is safe to delete; the Page Audit reports the same as advice. Caching Out detects and advises only – it never deletes another plugin's files. Only artefacts of plugins that are no longer installed are reported; while the other plugin is still installed, its files are its own business.
Troubleshooting
Browser caching refused to write: "another caching plugin's rules are present". A block of rules from another caching plugin is still in .htaccess. See "Leftovers from a previous cache plugin" above: remove that block after taking a backup, then save the Browser Caching tab again. An empty marker pair does not cause this message.
Browser caching doesn't seem to be working. Check your response headers using browser developer tools (Network tab). Look for Cache-Control and Expires headers. If they're missing, verify your server type is correctly detected and the configuration file is writable.
My CSS/JS changes aren't visible after updating. The plugin automatically appends a version query string to enqueued assets (e.g., style.css?ver=1.2.3). When you update a file, change the version number in your theme or plugin to force browsers to re-download it.
I'm on NGINX and nothing changed. NGINX requires manual configuration. Copy the provided snippet to your server block and reload NGINX. Contact your host if you don't have access to server configuration.