How to Correct the Leverage Browser Caching Warning in WordPress

Rarely, if ever, do we get a formal notification of Google’s algorithm updates from the search engine giant itself. So, when Google does announce something officially, the entire internet marketing community jumps on it.

The same happened on one fine April morning in 2010 when Google announced that site speed was now a search ranking factor. If you want to improve site speed, you should focus on the speed of individual pages first.

Why does loading time matter? Visitors won’t tolerate slow sites anymore now with increased internet speeds. It also takes longer for search bots to crawl a slow site.

What is Browser Caching and how can we leverage it?

When a web page loads, all of its resources i.e. images, CSS files, the HTML code of the page, and the javascript files will be loaded separately. Many requests traveling from browser to the server can increase the server load and increase your page’s loading time.

Browser caching is a way to speed up web page loading by storing the frequently accessed resources in the local memory of the device (your computer or mobile device). Since requests are not made to the server, loading time for these resources is greatly reduced.

When you implement browser caching, you are effectively asking the browser to store the commonly-used but rarely-updated files locally in its own cache memory. This reduces the server load, improves the page loading speed, and improves the overall WordPress website performance.

Does your site use browser caching?

One use of Google’s PageSpeed Insights tool is to find out if your site is already taking advantage of browser caching or not:

If you see the “Leverage browser caching” message, click the “Show how to fix link” to see which files are referenced. If the files are hosted on your own domain, read on to see how to apply browser caching.

Browser caching is configured on the server end

When the server has to tell the client (ie. the browser) to do something, it will send extra information via the HTTP Headers. To activate caching in the browser, we will be looking at “Expires” and “Cache-Control” HTTP headers.

The “Expires” header is a basic way to enable caching on the browser. It specifies a time duration after which the resource will be deleted. If the server doesn’t include this header (which is why you got the browser caching warning in PageSpeed Insights), all the resources will be downloaded from the server with each new request.

The “Cache-Control” header is more detailed and gives fine-grained options to control the caching behavior of the browser. We won’t be discussing these options in detail (you can check that on this MDN web page).

It would be a bit redundant to activate both these headers at the same time.

WP Rocket automatically applies the necessary Expires rules in the htaccess file if you are on an Apache server. So you don’t need to take any manual steps if you are using WP Rocket 🙂 If you are not using WP Rocket you can manually enable browser caching with the following instructions.

Enabling browser caching on Apache servers

Both the headers (Expires and Cache-Control) are to be added to the “.htaccess” file in your website root folder i.e. “public_html” folder. You can edit this file by downloading a copy via FTP, saving a backup copy locally and then uploading the edited version, or by logging into your hosting provider’s cPanel administration.

This is an important configuration file and if there are errors in it, it could break or blank your sites completely. Therefore, it is recommended that you copy and paste the contents of this file into a text file as a backup before you begin editing this file. This is needed because cPanel may not provide backups of previous versions.

If you want to enable the “Expires” header on Apache servers, add the following lines at the end of the “.htaccess” file in your website root folder i.e. “public_html” folder:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 2 days"

Each of these headers sets a maximum age for a different file type from the date of the first request.

All image types are set to stay alive for a full year after the page is requested. We have given the age of 1 month to all CSS, Javascript, PDF, and shockwave flash (.swf) files. Icons will have an age of 1 year and all other static resources will have an age of 2 days.

In order for these rules to take effect, your server must have the mod_expires module enabled. Most servers do, but if adding these rules does not resolve the “leverage browser caching” message, check with your host to ensure mod_expires is enabled.

If you want to enable the “Cache_Control” header on Apache servers, add the following line to your “.htaccess” file in your website root folder i.e. “public_html” folder:

Enabling browser caching on NGINX servers

An NGINX server is designed to be efficient. It doesn’t have an .htaccess file because the server needs to read it from every directory and that affects its performance negatively. NGINX has clarified about this on their website.

Therefore, you need to add all configuration for Expires or Cache-Control header in the main server block and reload for NGINX to read them.

To set the  “Expires” header in NGINX, add the following lines to your server block:

location ~* \.(jpg|jpeg|gif|png)$ {
   expires 365d;

location ~* \.(pdf|css|html|js|swf)$ {
   expires 2d;

To enable browser caching via the Cache-Control header on an NGINX server, add the following line to your server block, save and restart the server for changes to take effect:

WP Rocket (or any caching plugin) can’t modify your NGINX config automatically, but you can implement the recommended configuration which takes care of browser caching and more.

Can Google Analytics code generate the “Leverage Browser Caching” warning?

Google Analytics is the most advanced analytics engine. Practically every website uses it. But the code links to Google’s server so the browser treats it as an external resource and downloads a fresh copy.

Google does enable caching for this resource, but the age of the cached content is only 2 hours. While it may be justified from Google’s side (and you can’t really doubt the speed of Google’s own servers), some webmasters may want to eliminate this extra hop too.

To optimize and store Google’s own “analytics.js” file locally, install the Complete Analytics Optimization Suite (CAOS) plugin. This plugin gives you the option to choose where to insert the analytics code (header or footer) and keeps the analytics.js file updated using the wp_cron() functionality.

Once downloaded locally on the client, then using the above mentioned “Expires” or “Cache-Control” headers, you can enable caching of the analytics.js file.

You will need to provide your Google Analytics tracking ID to this plugin. If you have another analytics plugin, the CAOS plugin won’t work. So make sure you spot and delete any other analytics plugins you might have currently installed on your WordPress site.

What about caching third-party scripts?

Sometimes, you may use plugins that require you to add some additional scripts from the developers’ chosen server, for example social networks or ad servers. To enable caching of third-party scripts, you will have to contact the developers if they allow it. If the script is popular (like the Facebook Ad Pixel), you may find plugins for caching those.

Overall, it is totally dependent on the third-party developers whether they wish to enable caching of their scripts. If you see third party scripts listed under leverage browser caching, don’t worry too much about trying to apply browser caching to them. Focus on what you can control, and the overall load time of your site.


Catherrine Garcia is a passionate blogger and a freelance Web Developer. She along with her group of freelance developers, are experts of creating Websites on CMS.



Awesome post.
Really nice and detailed to read.

Could WP Rocket not consider to implement the Google Analytics optimization in a near future update, so users like me and others of WP Rocket could limit extra plugins?
Thank you in advance.

If you have NGINX with FastCGI cache I don’t think you will ever have to face any problem with the browser cache, page cache or anything. It just works. Furthermore it’s always good to implement memcache with atleast 512MB memory allocation. I was wondering do your plugin supports memcache?

How different between browser caching and search engine caching? and the effect on search ranking.

Does this sentence appear truncated to everyone? My browser does not show the “following line” even in the html source…

“If you want to enable the “Cache_Control” header on Apache servers, add the following line to your “.htaccess” file in your website root folder i.e. “public_html” folder:
Enabling browser caching on NGINX servers”

Hi Catherrine,

Thanks for mentioning CAOS in your post!

I actually receive a lot of questions about making CAOS compatible with WP-Rocket in the Support Forum. Do you have any experience with this?

I think it would be a great addition for both us, if CAOS would implement some extended compatibility with WP-Rocket. If possible, of course. Don’t you think?

Perhaps it’s an idea to get in touch? Let me know what you think.

Kind regards,

Daan van den Bergh

Leave a Reply

Your email address will not be published. Required fields are indicated by *