4 ms·

Google Pagespeed once recommended that I enable gzip compression on an embedded Google map. https://johnrockefeller.net/google-pagespeed-_/ https://johnrockefe

Google Pagespeed once recommended that I enable gzip compression on an embedded Google map. https://johnrockefeller.net/google-pagespeed-_/ https://johnrockefeller.net/google-pagespeed-_/

arkitaip 8y ago
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?
- gondo 8y ago
  tracking
  - jopsen 8y ago
    https://developers.google.com/fonts/faq#what_does_using_the_google_fonts_api_mean_for_the_privacy_of_my_users https://developers.google.com/fonts/faq#what_does_using_the_... 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)
    - deleted 8y ago
      [deleted]
    - philtar 8y ago
      Do you have a guess why those assets are not cached more aggressively?
      - fantyoon 8y ago
        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.
        outside1234 8y ago
        So it’s tracking then
      - jopsen 8y ago
        As I read the FAQ, the actual font files are aggressively cached. It's only the CSS files that links to the font files that aren't cached forever. Probably to allow for updates and estimate popularity, with low overhead assuming CSS files are small.
    - PavlovsCat 8y ago
      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.
      - jopsen 8y ago
        > Tracking popularity is still tracking. Tracking usually refers to tracking users, which as I read the FAQ isn't what it's for.
        PavlovsCat 8y ago
        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.
  - jefftk 8y ago
    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.)
- tehlike 8y ago
  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. https://www.google-analytics.com/analytics.js 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.
- hrrsn 8y ago
  I’ve always loved how Google’s own performance profiler marks you down for Analytics/Doubleclick caching.
- jefftk 8y ago
  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.)

Google Pagespeed once recommended that I enable gzip compression on an embedded Google map. https://johnrockefeller.net/google-pagespeed-_/ https://johnrockefeller.net/google-pagespeed-_/

arkitaip 8y ago

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?

gondo 8y ago
tracking
- jopsen 8y ago
  https://developers.google.com/fonts/faq#what_does_using_the_google_fonts_api_mean_for_the_privacy_of_my_users https://developers.google.com/fonts/faq#what_does_using_the_... 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)
  - deleted 8y ago
    [deleted]
  - philtar 8y ago
    Do you have a guess why those assets are not cached more aggressively?
    - fantyoon 8y ago
      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.
      - outside1234 8y ago
        So it’s tracking then
    - jopsen 8y ago
      As I read the FAQ, the actual font files are aggressively cached. It's only the CSS files that links to the font files that aren't cached forever. Probably to allow for updates and estimate popularity, with low overhead assuming CSS files are small.
  - PavlovsCat 8y ago
    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.
    - jopsen 8y ago
      > Tracking popularity is still tracking. Tracking usually refers to tracking users, which as I read the FAQ isn't what it's for.
      - PavlovsCat 8y ago
        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.
- jefftk 8y ago
  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.)
tehlike 8y ago
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. https://www.google-analytics.com/analytics.js 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.
hrrsn 8y ago
I’ve always loved how Google’s own performance profiler marks you down for Analytics/Doubleclick caching.
jefftk 8y ago
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.)