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?
* 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.)
https://www.google-analytics.com/analytics.js
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'm no lawyer, but I read that as it is not used for tracking users.
(full disclosure: I work at Google, on something unrelated)
> 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.
Tracking usually refers to tracking users, which as I read the FAQ isn't what it's for.
Probably to allow for updates and estimate popularity, with low overhead assuming CSS files are small.
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.)