Google will flag your assets with the “Serve static assets with an efficient cache policy” warning when they have a cache length that’s too short. Google requires that your assets (images, fonts, JS, CSS) have a cache expiry time, also referred to as cache TTL, of at least 30 days or more. Follow the steps and tips below to fix the warning.
Fix the “Serve static assets with an efficient cache policy” warning
A brand new site (not optimized) will typically have a cache TTL of 7 days on its assets, immediately triggering the cache warning in Google PageSpeed Insights. Caching is set on each asset with an HTTP header. There are different types, but the most commonly used HTTP header for caching is
You can check the current value of the caching headers on your assets by using a free tool like GiftOfSpeed’s Browser Caching Checker. Google PageSpeed Insights will also tell you, but they usually only show you the top or worse offenders. Sometimes using another tool can be helpful to check all of your assets at once.
You can also use Chrome DevTools to look at your site’s headers.
Caching headers are typically placed on your site’s assets by a WordPress hosting provider, a CDN, or a caching plugin.
1. WordPress host
Think of your WordPress host as the base layer of caching. Typically they will have some sort of default cache or expiry time set on your assets. This is especially true if you’re using a managed hosting provider like Kinsta that has server-level caching out of the box.
If you need to change your caching headers, you can reach out to your hosting provider. Otherwise, if you’re using a VPS or non-managed hosting provider, you can set the expires headers manually:
With hosting providers, there are typically two different cache types. There is cache on your pages and cache on your assets. The “Serve static assets with an efficient cache policy” warning only applies to assets, not your page cache. Therefore, it’s OK to have a shorter page cache time.
The most common approach these days is for the caching headers to be set by your content delivery network (CDN). Your hosting provider might still be setting caching headers at the base layer, but a CDN will typically be the one visitors are getting. For example, if you’re using Cloudflare, they set your caching headers. And you can easily change the cache expiry time.
Under the “Caching” tab, click on the “Configuration” tab. Set your “Browser Cache TTL” to 1 month or higher. This will resolve any warnings from Core Web Vitals complaining that you need to serve static assets with an efficient cache policy.
The same goes for other traditional CDNs like KeyCDN, BunnyCDN, etc. They all provide easy options in their dashboards to change the caching length.
3. Caching plugin
If you aren’t using a managed WordPress host with caching at the server-level, or a CDN, you might need a WordPress caching plugin. A caching plugin will usually set the appropriate caching headers for you automatically.
We recommend the following caching plugins (both of these work great alongside Perfmatters):
Here are some additional tips to ensure you don’t get the warning from PageSpeed Insights.
Third-party assets (scripts)
You might see the “Serve static assets with an efficient cache policy” warning on third-party assets or scripts. Since you don’t control their servers, you can’t change the cache length time. However, there are a few ways to fix the warnings still.
For example, the Google Analytics script has a short cache length by design. But you could host Google Analytics locally with Perfmatters. This means your local caching headers would automatically get applied and fix the warning.
Another example would be that perhaps that scripts shouldn’t be loading on the page or post you’re testing at all. In this case, you could disable it with the Script Manager in Perfmatters.
Longer is better
Longer cache times lead to improved site performance, and better cache HIT ratios. Therefore, an easy way to boost performance is simply making your cache expiry times longer. For ecommerce sites, we typically recommend 1 month. For blogs, we recommend much longer. We actually use 1 year on our blogs.