Leveraging Browser Caching

Checking the metrics on your website is critical. This tells you how well your site is performing and where it can improve. Two of the most popular testing tools are Pingdom and Google PageSpeed Insights.

If you’re like others, you may have seen a “Leverage Browser Caching” warning. It is hard to miss as it’s yellow and in noticeable font. Seasoned webmasters may understand this warning, but others may have questions.

For instance, how does leverage browser caching affect their website? Is it something they should be concerned about? If it’s a problem, what do they do?

Explaining the Leverage Browser Caching Warning

This warning is related to your browser’s cache. Each time that you visit a website, your browser downloads and caches numerous elements. These elements may include:

☑️ Images
☑️ JavaScript
☑️ CSS
☑️ HTML

Local cache storage ensures a faster browsing experience. When you visit that website again, your browser won’t have to download it from scratch. Instead, certain elements will be readily available.

The warning occurs when your Internet server, or a server that’s held by a third party, hasn’t implemented the right HTTP cache headers. Alternatively, the headers may exist, but the cache time setting is too brief.

Webmasters also have encountered this warning while running the website speed test known as “Think with Google.” Many people who own but don’t manage their websites use the tool, see this warning and worry that something is wrong with their website. Accordingly, they forward the warning to their webmaster to fix.

How to Fix the Leverage Browser Caching Warning in a WordPress Website

One of two problems typically is at the root of a Leverage Browser Caching warning. The most common problem is that the web server is not properly configured. The other problem is derived from scripts, which may be either Google’s or a third-party’s.

1. Web Server Configuration Issues

You may receive this warning if your web server isn’t using the appropriate headers. For instance, your web server may not have specified an expiration date.

Missing expiration dates can be an issue. It’s related to the main two types of caching: Cache-Control and Expires. The Cache-Control header relies on caching on the client side and setting the maximum age of a resource. Alternatively, the Expires header needs to define a time after which the resource becomes invalid.

You can add these headers yourself. However, if you’re not comfortable with this, contact your web host for assistance.

It’s possible to add cache-control headers through Nginx. Navigate to your server configuration’s block or location, then add this code:

location ~* .(js|css|png|jpg|jpeg|gif|svg|ico)$ {
expires 30d;
add_header Cache-Control "public, no-transform";
}

This instructs the server that the named file types won’t change for a minimum of one month. Now, your computer won’t have to download these elements each time you visit the website.

Alternatively, you may add Expires headers with Nginx. Once again in your server block, insert this code:

location ~* .(jpg|jpeg|gif|png|svg)$ {
expires 365d;
}
location ~* .(pdf|css|html|js|swf)$ {
expires 2d;
}

People who use Apache instead of Nginx follow a similar process for Cache-control headers by adding this code to their .htaccess file:

=<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"
</filesMatch>
Adding Expires headers in Apache looks like this:

## EXPIRES HEADER CACHING ##

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

## EXPIRES HEADER CACHING ##

2. Problems with the Google Analytics Script

This issue comes from Google itself. Google sets a two-hour cache time on their products as a means of quickly disseminating changes to users. You can eliminate this problem by hosting the script for Google Analytics on your server.

A WordPress plugin called Complete Analytics Optimization Suite makes this possible for free. Just download it from the repository and make certain that it’s regularly updated with wp_cron().

3. Problems with Third-Party Scripts

Business websites running on WordPress frequently utilize third-party scripts for a variety of purposes. These scripts may be essential to website functionality, and they certainly are not something that you can remove from your website without consequences.

Unfortunately, unlike the Google script it is not possible to locally host these scripts. This means that you may have to live with some level of Leverage Browser Caching warnings each time you test your website. The good news is that these warnings likely are not serious, nor will they significantly impede the performance of your website.

The next time you see a Leverage Browser Caching warning while reviewing the metrics on your website, you’ll know what it means and how to react. Remember, it may not be a difficult problem to fix. Adding some code makes the difference.

References and image credits:

• Webaroo.com.au