Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Fix this warning by changing the HTTP cache headers on the server, CDN, or other layer that delivers the flagged static file. Set an intentional Cache-Control policy (and, where used, Expires and validators such as ETags), use versioned asset URLs so updates invalidate old files, then verify the actual response headers. A WordPress plugin setting or an .htaccess line is not proof that the browser is receiving the policy.

What the warning means

“Leverage Browser Caching” is older Google PageSpeed terminology. Current reports may instead say “Serve static assets with an efficient cache policy.” The underlying issue is the same: one or more resources have no useful caching directives or a cache lifetime that is short for the type of file.

Browser caching applies to individual responses such as images, CSS, JavaScript, fonts and other static files. It is different from page caching, which stores generated HTML pages. WordPress documentation identifies Cache-Control (especially max-age), Expires and entity tags as the mechanisms involved. Google’s older PageSpeed documentation describes the policy as answering whether a resource can be cached, by whom, for how long and how it should be revalidated. That Google page is deprecated and documented PageSpeed Insights API v4, so its label and thresholds are legacy guidance rather than a universal current ranking rule.

Find the resource and the layer that serves it

  1. Open the performance report and record every flagged URL, not just the page URL.
  2. Check the hostname. A file on your WordPress domain may be served by the origin, a reverse proxy or a CDN; a file on another hostname is controlled by that provider.
  3. Request the exact URL and inspect its response headers. In a terminal, run curl -I "https://example.com/path/file.css", replacing the example with the reported URL. In browser developer tools, open Network, reload the page, select the asset and inspect Response Headers.

Look for a deliberate Cache-Control policy, its max-age, and—if your setup uses them—Expires and validators such as ETag. Check the response from the URL listed by the audit; a rule in WordPress or a plugin dashboard is irrelevant if another host or edge layer supplies the file.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Choose an implementation that matches your server

Approach Best when Important limitation
Web-server or edge configuration You or your host can edit Apache, Nginx, CDN or proxy rules Syntax and control differ by server; configure the layer that actually returns the file
WordPress caching plugin You need dashboard-based management and the plugin supports your stack Features and server requirements vary; verify them instead of assuming compatibility
Hosting or CDN support The host or edge provider owns the response configuration Ask which layer serves the asset and how invalidation is performed

Configure Apache with .htaccess or host controls

On Apache, an .htaccess and mod_expires approach can set expiration policies when the host enables the module and permits overrides for that directory. A representative pattern is:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType text/css "access plus 1 year"
  ExpiresByType application/javascript "access plus 1 year"
</IfModule>

Use the file types your site actually serves and confirm the resulting headers. Do not apply a long freshness period to frequently changing or personalized content without a reliable invalidation plan.

Apache-only plugin example

The WordPress.org listing for the plugin named Leverage Browser Caching says it writes rules to .htaccess and requires Apache, mod_expires and a writable .htaccess. It does not work on Nginx or IIS. Therefore, install it only after confirming all three requirements with your host, and still verify the asset response.

Configure Nginx, a CDN or a reverse proxy

.htaccess cannot configure Nginx. Use the site’s Nginx server configuration, hosting control panel or CDN rules, or ask the host to set cache headers for the relevant static locations. WordPress supports Nginx installations, but the exact directive and deployment method depend on the host’s configuration.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The same ownership rule applies to a CDN or proxy: set the policy where that layer generates the response, and define how a changed asset is purged or revalidated. If the flagged file belongs to a third party, you generally cannot change its headers; document it separately rather than altering your origin configuration.

Pick a cache lifetime and plan invalidation

Google’s deprecated guidance for static or infrequently changing assets suggested at least one week and preferably up to one year. Treat those durations as legacy guidance, not a guaranteed current audit requirement. The correct lifetime depends on how reliably your site changes the resource URL when its contents change.

Use versioned WordPress asset URLs

For enqueued styles and scripts, WordPress supports a version argument. When the version changes, the requested URL changes, so browsers fetch the new file instead of reusing the old representation. Use a dependable versioning strategy for every update and purge any page cache that continues to emit the previous URL.

Long-lived caching is appropriate only when that URL-change or purge process is dependable. Never use it as a substitute for cache invalidation on files that change in place.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Clear stale caches after changing headers or files

  • Clear the relevant WordPress page-cache or optimization-plugin cache.
  • Purge the CDN or reverse-proxy cache when it stores the asset.
  • Refresh or clear the browser cache while testing, or use a private window.
  • Confirm that the stylesheet or script URL includes the new version and that the response headers changed.

WordPress documentation notes that browser and server-side caching commonly hide edits. Clearing only one layer can leave an old response visible.

Verify the fix

  1. Request each previously flagged asset again with curl -I or browser developer tools.
  2. Confirm that the response contains the intended Cache-Control policy and an appropriate lifetime; check Expires and validators when your setup uses them.
  3. Verify that the URL is served by the layer you configured, rather than a different hostname or CDN edge.
  4. Re-run the current performance audit and inspect the flagged resource list.

If files you control now have an appropriate policy but the report still identifies third-party resources, the remaining headers must be changed by those resource owners or their delivery provider.

Common mistakes

  • Installing an Apache plugin on Nginx: an .htaccess rule cannot configure Nginx.
  • Checking only a plugin toggle: success requires the response headers, not an enabled setting.
  • Setting Expires alone: inspect the complete caching policy and actual lifetime.
  • Caching changing files for a year without versioning: returning visitors can retain stale CSS or JavaScript.
  • Changing origin rules for a CDN or third-party URL: configure the layer and owner that serves that URL.
  • Expecting a guaranteed score increase: no fixed speed or PageSpeed improvement follows from this configuration.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.