Fix Leverage Browser Caching Warning

local analytics

At some point in time when you are running speed tests with your website you will most likely encounter the all popular “leverage browser caching” warning in Google PageSpeed Insights. And we are referring to the one originating from Google’s analytics.js script. In this post today we are going to show you a couple options on how to easily setup local analytics to fix this warning. Depending upon your environment you might also see a slight performance improvement. We have also included a new way to more easily do this for those of you running WordPress.

Google Analytics Leverage Browser Caching Warning

As we covered in our other post on Google PageSpeed insights, a lot of people try and strive for that 100/100 score on Google PageSpeed Insights. Some do it because they are trying to speed up their site and others because a client is demanding they meet this metric (yes, this happens more than you think). It is important to take some time though and think about why we are trying to achieve that 100/100 score. Don’t think of it solely from a metrics point of view. The whole reason Google developed PageSpeed Insights was as a guideline on best web performance practices to provide recommendations to optimize your site. And by following the guidelines hopefully you will achieve a faster website. We don’t recommend obsessing over this metric.

There are some warnings which can be a little frustrating, such as with the leverage browser caching warning, because it is coming from Google’s own analytics.js script. Kind of ironic that their own optimization tools gives us a warning. It is a valid warning as they set the cache time on their script very low. Most likely this is in case they push out any updates, they want everyone to get the new script within a short amount of time.

As you can see in the screenshot below on our test site, we got everything to 99/100, except for that leverage browser caching warning from Google Analytics script. To fix this we host their script locally.

There are other reasons why you might want to host local analytics besides fixing the PageSpeed Insights error. Don’t expect to see huge performance gains by doing this, but you might see a little.

  • By hosting locally you can ensure that their large script loads from your web server, or CDN, instead of having to reach out to Google.
  • Instead of 2 HTTP requests to Google, you now only have 1.
  • When you host locally, you now have full control over browser caching, expires headers, cache-control, etc.
  • Take advantage of your single HTTP/2 connection

Linking Normally to Google Analytics

We ran some tests with WebPageTest. When we linked to Google’s analytics.js it seemed to always result in a larger DNS lookup time the first time around, as opposed to when we hosted locally.

Total Load Time: 1.576s
Fully loaded: 1.740s

google analytics load time before

Local Analytics

We ran some tests with WebPageTest. When we hosted the analytics script locally, obviously it loads super fast from our same HTTP/2 single connection on our CDN. It then has to do the DNS lookup on the final HTTP request to Google, but the DNS lookup was always a lot less. Doing it this way also results in what we like to call, “a nicer looking waterfall.”

Total Load Time: 1.426s
Fully loaded: 1.526s

google analytics load time after

Again because this test is so small, your results might vary. Always do your own testing as each environment is different. But in our testing we did see a slight improvement to performance.

How to Fix GA Leverage Browser Caching Warning

Normally the way we would fix a leverage browser caching warning would be to simply add expires headers. However, since this is a 3rd party script hosted on Google’s servers we have no control over the headers. There are two different options below you can use to fix this warning.

Option 1

So a solution that does work is to grab a copy of Google’s analytics.js script, host it locally, and sync it periodically to ensure you are using the latest version. Again, please be aware that this is not officially supported by Google.  Credits for some of the code and scripts below go to Daan van den Bergh, Matthew Horne, and Jørgen Nicolaisen. Follow the steps below.

Step 1

The very first thing you need to do is grab a copy of the contents of Google’s Analytics script here: google-analytics.com/analytics.js. We are using Universal Analytics. Create a new file, in our example we call ours local-ga.js, and paste the contents of Google’s script into it.

Step 2

Upload the local-ga.js file to your web server where it is accessible. Note: Permissions on this file need to be writable for everything to work correctly.

Step 3

Next, you need to update the Google Analytics tracking code on your website. Again, we are using the Universal tracking code. In our example below, you can see we have updated ours to point to our local-ga.js file, and or the copy that also resides on our CDN.

<script>
 (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
 (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
 m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
 })(window,document,'script','https://cdn.yourdomain.com/local-ga.js','ga');

ga('create', 'UA-xxxxxxx-x', 'auto');
 ga('send', 'pageview');

</script>

That should now be working on your site. A quick way to test it is to launch your site it incognito mode and view real-time analytics. Ensure that tracking is working properly before proceeding.

Step 4

The next step is to setup a script so that your local script is periodically updated with Google’s hosted version. Otherwise, they might push out an update/change and the tracking of your traffic could stop reporting correctly. In our example we name ours ga-update.php.

<?
// script to update local version of Google analytics script

// Remote file to download
$remoteFile = 'https://www.google-analytics.com/analytics.js';
$localfile = 'ENTER YOUR ABSOLUTE PATH TO THE FILE HERE';
//For Cpanel it will be /home/USERNAME/public_html/local-ga.js

// Connection time out
$connTimeout = 10;
$url = parse_url($remoteFile);
$host = $url['host'];
$path = isset($url['path']) ? $url['path'] : '/';

if (isset($url['query'])) {
 $path .= '?' . $url['query'];
}

$port = isset($url['port']) ? $url['port'] : '80';
$fp = @fsockopen($host, '80', $errno, $errstr, $connTimeout );
if(!$fp){
 // On connection failure return the cached file (if it exist)
 if(file_exists($localfile)){
 readfile($localfile);
 }
} else {
 // Send the header information
 $header = "GET $path HTTP/1.0\r\n";
 $header .= "Host: $host\r\n";
 $header .= "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6\r\n";
 $header .= "Accept: */*\r\n";
 $header .= "Accept-Language: en-us,en;q=0.5\r\n";
 $header .= "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n";
 $header .= "Keep-Alive: 300\r\n";
 $header .= "Connection: keep-alive\r\n";
 $header .= "Referer: http://$host\r\n\r\n";
 fputs($fp, $header);
 $response = '';

// Get the response from the remote server
 while($line = fread($fp, 4096)){
 $response .= $line;
 }

// Close the connection
 fclose( $fp );

// Remove the headers
 $pos = strpos($response, "\r\n\r\n");
 $response = substr($response, $pos + 4);

// Return the processed response
 echo $response;

// Save the response to the local file
 if(!file_exists($localfile)){
 // Try to create the file, if doesn't exist
 fopen($localfile, 'w');
 }

if(is_writable($localfile)) {
 if($fp = fopen($localfile, 'w')){
 fwrite($fp, $response);
 fclose($fp);
 }
 }
}
?>

Step 5

The last step is that you will need to setup a cron job that runs the script above periodically. This will update your local-ga.js file with the latest version from Google. Here is an example using crontab with a daily update.

02 4 * * * /usr/bin/php /home/USERNAME/public_html/ga-update.php 2>&1

If your web host doesn’t let you setup cron jobs, you can always use an external service.

Option 2

The second option you have is to use ga-lite, which is a small, cacheable subset of Google Analytics JS client, created by Jesse Luoto. Note that this uses an API that is actually supported by Google. Note: If you just copy the analytics.js file to your own server, it could potentially break at any minute. This is, because Google makes updates to their code from time to time.

You can install ga-lite to your project by adding the following code to the ended of your HTML <body>. You can download the file locally to your server or your own CDN as well.

<script src="https://cdn.jsdelivr.net/ga-lite/latest/ga-lite.min.js" async></script>
<script>
var galite = galite || {};
galite.UA = 'UA-XXXXXX'; // Insert your tracking code here
</script>

This includes the most recent version of ga-lite to your site and initializes the script with your own UA code. See more documentation on GitHub.

Fix GA Leverage Browser Caching Warning in WordPress

If you are running WordPress, there is now a great free little plugin called Complete Analytics Optimization Suite (CAOS) that can do the above for you! It was created by Daan van den Bergh and enables you to host your Google Analytics javascript-file (analytics.js) locally and keep it updated using wp_cron(). To further optimize your sites’ usage of Google Analytics, it allows you to optionally set Adjusted Bounce Rate and decided whether to load the Analytics Tracking-code in the header or footer.

complete analytics optimization suite banner

Step 1

Download Complete Analytics Optimization Suite (CAOS) from the WordPress repository or do a search from your WordPress dashboard for “host analytics.” Then click on “Install Now.”

caos plugin

Step 2

After you have installed and activated it, go into the plugin settings by clicking into “Settings” and “Optimize Analytics” in your WordPress dashboard.

Step 3

Enter in your Google Analytics Tracking ID and position for your tracking code. We recommend placing it in your footer. The developer has also added the ability to use adjusted bounce rate (example: 30 seconds) and change the enqueue order in WordPress. The default is 0 which means the Google Analytics script will be the first script in your footer that fires. You can also enable the anonymize IP feature which is required by law in some countries.

caos analytics settings

Don’t know your Google Analytics tracking ID? Here is how to find it. Login to Google Analytics, click into your site, click on “Admin”, and then into “Property Settings.” Then copy your Tracking Id, paste into the plugin settings shown above, and click on “Save Changes.”

optimus get analytics tracking id

 

And the great news is that it works perfectly with KeyCDN’s WordPress CDN enabler plugin. So the plugin above will sync across Google’s analytics script and then our plugin will copy it to your CDN. Again remember to test to ensure it is working properly. A quick way to test it is to launch your site it incognito mode and view real-time analytics.

Important Note: Make sure you aren’t running multiple Google Analytics plugins otherwise your script might appear twice and double your reporting. If you were previously using a plugin like Monster Insights (previously Yoast Analytics) to hook up with Google Analytics, you will need to deactivate the plugin.

And now there should be no more leverage browser caching warning, at least as far as Google Analytics is concerned.

Summary

As you can see there are some great alternatives out there for local analytics if you are trying to fix the Google Analytics leverage browser caching warning in PageSpeed Insights. You might even see a small performance improvement. Have you experimented with hosting Google Analytics locally? If so we would love to hear your thoughts below.

Related Articles

Fix Leverage Browser Caching Warning was last modified: June 6th, 2017 by Brian Jackson
Share This