3 ms·

> if lots and lots of sites link to the same CDN-hosted version of, say, jQuery, then surely users are likely to already have that exact file on their machine a

> if lots and lots of sites link to the same CDN-hosted version of, say, jQuery, then surely users are likely to already have that exact file on their machine already > [However] Safari has completely disabled this feature for fear of abuse where privacy is concerned All major browsers have now disabled shared caches[0][1]. Using a CDN for resources is strictly worse, now, performance-wise. [0] https://developers.google.com/web/updates/2020/10/http-cache-partitioning https://developers.google.com/web/updates/2020/10/http-cache... [1] https://arstechnica.com/gadgets/2020/12/firefox-v85-will-improve-its-cache-partitioning-for-stronger-privacy/ https://arstechnica.com/gadgets/2020/12/firefox-v85-will-imp...

eternityforest 5y ago
I really hate that you can't disable the cache partition. Every megabyte counts in a mobile first world.
- earthboundkid 5y ago
  > Every megabyte counts in a mobile first world. I manage a normal looking regional news site. First load is 691KB. Megabytes don't come into it. (I cheat by not having Google Ads on the page, but lol, Google is the one who sucks. Our house ads are fine.)
  - eternityforest 5y ago
    If saves 2 hits like that a day, it's over 30MB a month. Not extreme, it's still 1% monthly data saved, for something that likely would have been easy to make into a setting.
    - MrJohz 5y ago
      That estimation seems pretty suspect though. Firstly, once you've visited the site personally, the assets will be cached for you anyway. Assuming the site updates its CDN'd assets once a month, the shared cache might possibly save you the first hit each month if you've visited another site that uses the same exact assets beforehand. (But given that the asset has just been updated, this seems unlikely.) So we're not talking about two hits a day. Secondly, the vast majority of the site will not be on shared CDNs, because it's specific to that site. Images are usually the biggest offender in terms of page load, and those are very unlikely to end up in a shared cache. In a busy marketplace like that of news media, brand identity is very important, so I would guess that most of the CSS is either custom or customised, and therefore not in a shared cache. I don't know how much JS the site uses, but I'll be generous to your argument and assume they use jQuery, which is hosted on a shared CDN. Custom JS is obviously not used on other sites, so won't be in the shared cache. And thirdly, there's a reasonably high chance, even if the jQuery stuff is hosted on a shared CDN and you've visited another page that uses jQuery before, that either the CDN host is different, or the version of jQuery being downloaded is different. It's unlikely that everyone updates immediately when a new version is released, which leaves you with a long tail of different versions being spread out over different hosts. A better estimate probably like like this: * Assume only one hit per month - the rest would have been cached anyway after the first visit to the site. * Assume only a minified version of jQuery is hosted via a shared CDN. * Assume that half the time, the version of jQuery used on this particular site is so unique that it wouldn't have been found in the shared cache. According to Bundlephobia, the gzipped, minified size of the latest jQuery package is about 30kB. Assuming we would have had to download it anyway on about 50% of requests, and given that every request after the first would is cached anyway, you're saving around 15kB a month on average. Assuming 3GB data a month (based on your 1% figure), that's about 0.0005% of your data each morning getting a successful cache hit that it would not otherwise have got if the shared cache was not there.
      - eternityforest 5y ago
        https://developers.google.com/web/updates/2020/10/http-cache-partitioning https://developers.google.com/web/updates/2020/10/http-cache... Google claims a 4% increase in bytes over the network.
- mro_name 5y ago
  so why not cut it from image cruft, videos or bloated code and frameworks? What kind of pages are we talking? Print-ready image archives?
  - eternityforest 5y ago
    Because for whatever reason, they seem to have no interest in turning down the quality slider on the JPG you will look at for 0.5 seconds by even one point. If web designers don't care, at least the browser can try to clean up the mess.
- lelandfe 5y ago
  It's for the best. Cache partitioning solves a browser history leak described in Timing Attacks on Web Privacy[0] The permutations of different CDNs and asset versions meant the cache hit rate was low anyway.[1][2] [0] https://www.cs.umd.edu/~jkatz/TEACHING/comp_sec_F04/downloads/web-timing.pdf https://www.cs.umd.edu/~jkatz/TEACHING/comp_sec_F04/download... (PDF) [1] https://zoompf.com/blog/2010/01/should-you-use-javascript-library-cdns/ https://zoompf.com/blog/2010/01/should-you-use-javascript-li... [2] https://web.archive.org/web/20111123170325/http://statichtml.com/2011/google-ajax-libraries-caching.html https://web.archive.org/web/20111123170325/http://statichtml...
  - dspillett 5y ago
    > The permutations of different CDNs and asset versions meant the cache hit rate was low anyway. A CDN with DCs in a number of locations and appropriate DNS setup at least has the advantage of local delivery which can have more than zero significance if you have an international audience and you really need low latency. But if you are in that category then you probably won't (or shouldn't) be loading a bunch of stuff from a CDN or otherwise. And I wouldn't source script from a 3rd party anyway, I never saw the security tradeoff as worth it.
    - ptx 5y ago
      > And I wouldn't source script from a 3rd party anyway, I never saw the security tradeoff as worth it. Doesn't subresource integrity [1], i.e. specifying the expected hash of the script, solve those security issues? Unless you need to support Internet Explorer, I suppose. [1] https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
      - dspillett 5y ago
        I want aware that had become so well supported. Something to remember for later. Though for personal projects I'll stick with self-hosting, and in DayJob we unfortunately still have to support IE11 to an extent (and beyond that some of our clients strictly whitelist everything and will reject a 3rd party they can't fully audit, ruling out CDNs for those at least, every with SRI).
- octoberfranklin 5y ago
  Except that we live in a security "first" world.
  - eternityforest 5y ago
    Cache partition does very little for security, it's a matter of privacy. They're overlapping but somewhat distinct.
tick_tock_tick 5y ago
> Using a CDN for resources is strictly worse, now, performance-wise. It's still normally significantly better if only for the fact the CDN's servers are physically closer to the client.
- deleted 5y ago
  [deleted]
- lelandfe 5y ago
  "Normally," i.e. when the origin itself is not behind a CDN, right?
- r1ch 5y ago
  Not necessarily even then. Connecting to a new domain has the overhead of a DNS lookup, TCP connection and TLS handshake before you can even send the request (and be stuck in slow start for the first few RTTs).
- idop 5y ago
  From my experience CDNs degrade performance. For most websites, they are the resources that are loaded the slowest, and are usually loaded synchronously, thus blocking page interaction. I should note that I live in Israel, and geograpical distribution by CDNs may be at fault here. Regardless, as others have noted, I have already connected with the website, third party connections have a high chance if impacting perfotmance for the worse.

eternityforest 5y ago

I really hate that you can't disable the cache partition. Every megabyte counts in a mobile first world.

earthboundkid 5y ago
> Every megabyte counts in a mobile first world. I manage a normal looking regional news site. First load is 691KB. Megabytes don't come into it. (I cheat by not having Google Ads on the page, but lol, Google is the one who sucks. Our house ads are fine.)
- eternityforest 5y ago
  If saves 2 hits like that a day, it's over 30MB a month. Not extreme, it's still 1% monthly data saved, for something that likely would have been easy to make into a setting.
  - MrJohz 5y ago
    That estimation seems pretty suspect though. Firstly, once you've visited the site personally, the assets will be cached for you anyway. Assuming the site updates its CDN'd assets once a month, the shared cache might possibly save you the first hit each month if you've visited another site that uses the same exact assets beforehand. (But given that the asset has just been updated, this seems unlikely.) So we're not talking about two hits a day. Secondly, the vast majority of the site will not be on shared CDNs, because it's specific to that site. Images are usually the biggest offender in terms of page load, and those are very unlikely to end up in a shared cache. In a busy marketplace like that of news media, brand identity is very important, so I would guess that most of the CSS is either custom or customised, and therefore not in a shared cache. I don't know how much JS the site uses, but I'll be generous to your argument and assume they use jQuery, which is hosted on a shared CDN. Custom JS is obviously not used on other sites, so won't be in the shared cache. And thirdly, there's a reasonably high chance, even if the jQuery stuff is hosted on a shared CDN and you've visited another page that uses jQuery before, that either the CDN host is different, or the version of jQuery being downloaded is different. It's unlikely that everyone updates immediately when a new version is released, which leaves you with a long tail of different versions being spread out over different hosts. A better estimate probably like like this: * Assume only one hit per month - the rest would have been cached anyway after the first visit to the site. * Assume only a minified version of jQuery is hosted via a shared CDN. * Assume that half the time, the version of jQuery used on this particular site is so unique that it wouldn't have been found in the shared cache. According to Bundlephobia, the gzipped, minified size of the latest jQuery package is about 30kB. Assuming we would have had to download it anyway on about 50% of requests, and given that every request after the first would is cached anyway, you're saving around 15kB a month on average. Assuming 3GB data a month (based on your 1% figure), that's about 0.0005% of your data each morning getting a successful cache hit that it would not otherwise have got if the shared cache was not there.
    - eternityforest 5y ago
      https://developers.google.com/web/updates/2020/10/http-cache-partitioning https://developers.google.com/web/updates/2020/10/http-cache... Google claims a 4% increase in bytes over the network.
mro_name 5y ago
so why not cut it from image cruft, videos or bloated code and frameworks? What kind of pages are we talking? Print-ready image archives?
- eternityforest 5y ago
  Because for whatever reason, they seem to have no interest in turning down the quality slider on the JPG you will look at for 0.5 seconds by even one point. If web designers don't care, at least the browser can try to clean up the mess.
lelandfe 5y ago
It's for the best. Cache partitioning solves a browser history leak described in Timing Attacks on Web Privacy[0] The permutations of different CDNs and asset versions meant the cache hit rate was low anyway.[1][2] [0] https://www.cs.umd.edu/~jkatz/TEACHING/comp_sec_F04/downloads/web-timing.pdf https://www.cs.umd.edu/~jkatz/TEACHING/comp_sec_F04/download... (PDF) [1] https://zoompf.com/blog/2010/01/should-you-use-javascript-library-cdns/ https://zoompf.com/blog/2010/01/should-you-use-javascript-li... [2] https://web.archive.org/web/20111123170325/http://statichtml.com/2011/google-ajax-libraries-caching.html https://web.archive.org/web/20111123170325/http://statichtml...
- dspillett 5y ago
  > The permutations of different CDNs and asset versions meant the cache hit rate was low anyway. A CDN with DCs in a number of locations and appropriate DNS setup at least has the advantage of local delivery which can have more than zero significance if you have an international audience and you really need low latency. But if you are in that category then you probably won't (or shouldn't) be loading a bunch of stuff from a CDN or otherwise. And I wouldn't source script from a 3rd party anyway, I never saw the security tradeoff as worth it.
  - ptx 5y ago
    > And I wouldn't source script from a 3rd party anyway, I never saw the security tradeoff as worth it. Doesn't subresource integrity [1], i.e. specifying the expected hash of the script, solve those security issues? Unless you need to support Internet Explorer, I suppose. [1] https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
    - dspillett 5y ago
      I want aware that had become so well supported. Something to remember for later. Though for personal projects I'll stick with self-hosting, and in DayJob we unfortunately still have to support IE11 to an extent (and beyond that some of our clients strictly whitelist everything and will reject a 3rd party they can't fully audit, ruling out CDNs for those at least, every with SRI).
octoberfranklin 5y ago
Except that we live in a security "first" world.
- eternityforest 5y ago
  Cache partition does very little for security, it's a matter of privacy. They're overlapping but somewhat distinct.

tick_tock_tick 5y ago

> Using a CDN for resources is strictly worse, now, performance-wise. It's still normally significantly better if only for the fact the CDN's servers are physically closer to the client.

deleted 5y ago
[deleted]
lelandfe 5y ago
"Normally," i.e. when the origin itself is not behind a CDN, right?
r1ch 5y ago
Not necessarily even then. Connecting to a new domain has the overhead of a DNS lookup, TCP connection and TLS handshake before you can even send the request (and be stuck in slow start for the first few RTTs).
idop 5y ago
From my experience CDNs degrade performance. For most websites, they are the resources that are loaded the slowest, and are usually loaded synchronously, thus blocking page interaction. I should note that I live in Israel, and geograpical distribution by CDNs may be at fault here. Regardless, as others have noted, I have already connected with the website, third party connections have a high chance if impacting perfotmance for the worse.