Most performance profilers will penalize you for embedding Google Analytics and Google Fonts because they have poor caching settings. What's so important about those resources that they can't be cached for longer periods?
There are two main reasons why short caching is helpful on tag scripts:
* Faster iteration time for developers: the more often you release updates the faster you can move. If your script has a one week cache lifetime then there's not much point in daily releases and any experiments you run will be really skewed.
* Quicker response to problems: if we push out a bad update that gets past our testing, the TTL we serve it with determines how long that will stick around in browser caches.
(Disclosure: I work at Google, on ads JS, and I previously worked on mod_pagespeed. Not speaking for Google, just myself.)
Easier bug fix presumably. Meaning if there is a bad release url is cached for little. If urls were versioned and were changable by google, it would have been done.
Google cannot bust this in case of a bug. They can mitigate this by having a loader with built in functionality that always looks out for "is there a newer version" but that has its limitations.
I see no explanation given why an asset that never changes would need to be requested once a day, and they clearly state they do record it.
> We only [sic] see 1 CSS request per font family, per day, per browser. Google Fonts logs records of the CSS and the font file requests, and access to this data is kept secure.
I read that as what's written there. It's for tracking. Tracking popularity is still tracking.
They take and keep the tracking data. What they say they use it for doesn't change that. If they simply incremented a counter the bit about "keeping access to the data secure" would make no sense.
This is a complete guess but I suppose one request everyday would be enough to get atleast some idea of how popular any given font is. The page says its to keep them updated but I highly doubt that would be the reason.
While I don't know anything about fonts stuff, successful execution of the ad tag leads to an ad request, and this happens on every page view which has the script and not just the ones where the file has fallen out of cache. So there's no additional useful information Google would get from a low cache lifetime for the script.
The script request is to a cookiless domain for performance, unlike the ad request, so there's not even much useful information on that request.
(Disclosure: I work at Google, on ads JS, and I previously worked on mod_pagespeed. Not speaking for Google, just myself.)
https://johnrockefeller.net/google-pagespeed-_/