Expires header for Facebook JS SDK and Google Analytics

Collector picture Collector · Sep 23, 2014 · Viewed 8.7k times · Source

We all know adding a far-future expiration date to static resources is a good practice to increase our websites' page load speed. So we've ensured it for all of our resources BUT the all-too-common Facebook JS SDK and Google Analytics don't do that and thus lower the entire page's speed score.

Snapshop

Examining the headers shows Facebook do 20 minutes: Cache-Control public, max-age=1200 Connection keep-alive Content-Type application/x-javascript; charset=utf-8 Date Tue, 23 Sep 2014 04:46:38 GMT Etag "566aa5d57a352e6f298ac52e73344fdc" Expires Tue, 23 Sep 2014 05:06:38 GMT

and Google Analytics do 2 hours: Key Value Response HTTP/1.1 200 OK Date Tue, 23 Sep 2014 04:45:49 GMT Expires Tue, 23 Sep 2014 06:45:49 GMT Last-Modified Mon, 08 Sep 2014 18:50:13 GMT X-Content-Type-Options nosniff Content-Type text/javascript Server Golfe2 Age 1390 Cache-Control public, max-age=7200 Alternate-Protocol 80:quic,p=0.002 Content-Length 16,062

Is there a way to force them to longer expiration dates?

Answer

Philip Walton picture Philip Walton · Sep 25, 2014

These scripts have a short cache expire headers because they're frequently updated. When Facebook and Google add new features and fix bugs, they deploy these changes by overwriting the existing files (the ones you linked to in your question). This allows users of these services to get the latest features without having to do anything, but it comes at the cost (as you point out) of needing short cache expire headers.

You could host these scripts yourself and set far-future expire headers on them, but that would require you to manually update them when the libraries change. This would be very time-consuming and often impossible because most of these updates aren't put in public changelogs.

Moreover, doing this yourself could very likely end up being a net loss in performance because you'd lose the network cache effect that you gain due to the sheer popularity of these services. For example, I'd imagine when most users come to your site they already have a cached version of these scripts (i.e. it's extremely likely that sometime in the past two hours, the person visiting your website also visited another site that uses Google Analytics). On the other hand, if you hosted your own version, first-time visitors would always have to download your version.

To sum up, I wouldn't go out of your way to fix this "problem". Doing so would take a lot of time and probably not give you the desired effects.