Expires header for Facebook JS SDK and Google Analytics

Question

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.

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?

Sharpshooter

While it is possible to download the scripts and serve them locally with whichever expires header I'd choose, I still prefer not to employ such a solution. – Sharpshooter

The ga.js is added by code that runs asynchronously so (assuming that snippet is setup correctly) this wont really affect site performance. – Pneumococcus

Answer 1

The solution finally implemented was to move to Facebook's rediret API which doesn't force loading their script on each page load. It's actually what StackOverflow does here as well. Start a session in a private/incognito browser and you'll see. This link might help: https://developers.facebook.com/docs/php/howto/example_facebook_login

Sharpshooter

could you please extend your answer a little. I'm facing the same problem. How did you use the Facebook redirect API??? – Prowl

This should be a good start: developers.facebook.com/docs/php/howto/example_facebook_login – Sharpshooter

Answer 2

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.

Rascality

While I thank you for your time and answer, it didn't really answer my question which was about forcing them to have a longer expiration time, perhaps by some undocumented tweak. Even if Google/FB scripts are frequently updated, my guess is that we could live with a week's expiration for most purposes. They may choose shorter expiration time for their own reasons, but perhaps they left this optional or tweakable somewhere. – Sharpshooter

No, there is no way for you (someone without access to their servers) to change the cache-control headers. Honestly, it sounds to me like you're using a tool like Google Page Speed and you're frustrated that it's docking you for things outside of your control. While I understand that frustration, you shouldn't develop to a set of rules, you should develop to the principles behind the rules. – Rascality

If you really don't like the expire times you can always file a bug or feature request for the library. I don't know about Facebook, but for Google Analytics you can submit a feature request on their issue tracker – Rascality

The 2 hours timeframe for Google Analytics means that metrics are updated every two hours. A longer timeframe would negatively reflect on outdated stats. I guess that Facebook SDK works in a similar fashion. – Countermarch

@PhilipWalton Thanks for the link, I added a request code.google.com/p/analytics-issues/issues/detail?id=503 I do develop for principles and see no principle in setting a short expiry time for the script itself. – Sharpshooter

@Countermarch - which "metrics" would need be updated every two hours and why? Each page load is tracked by the script and as long as the script hasn't changed, there's no need to reload it. – Sharpshooter

Collector, I was actually inaccurate in my previous comment. I thought that expire header had to do with cookies GA sets to track visits. Nevertheless, digging deeper I've found out that the short expire timespan simply means: "if your copy of ga.js is older than 2 hours please download it again". In other words, it's a way for Google to ensure that browsers do not cache outdated script tracking the wrong things. Additionally, the script refreshing is done asynchronously which doesn't really add up on your page performance. – Countermarch