8 ms·

Say goodbye to resource-caching across sites and domains

74 points by stefanjudis 6y ago

arkitaip 6y ago
One of the benefits of using cdn resources is that it enables prototyping with, say, bootstrap so fast because you could essentially upload a single html file instead of a bunch of css, is,l and graphics. I mean, that will still be possible but there are more benefits to CDNs that just performance.
- ocdtrekkie 6y ago
  But the cost of it is making your site which normally only depends on one server depend on several. That inherently lowers the reliability of your site. I see no problem with using remotely hosted resources for prototyping. But you should never let a link to remotely hosted fonts or scripts make it into production code.
  - wolco2 6y ago
    In isolation 1 is better than two. But when each of those servers is on new equipment with expert techs getting an alert if things go down the risk gets reduced. Unless your support on the single server is on par multiple managed may be safer.
    - TonyTrapp 6y ago
      It doesn't help your website if your own server has issues while the CDN has the best experts ensuring its 99.999% uptime. The probability of a failure is still a multiplicative factor of both uptimes, so it's strictly worse. Your user won't care if the CDN serving JS files is up while the website itself is unreachable. The only uptime that is relevant is that of your own server. Edit: Typo
      - dathinab 6y ago
        But what if you also put you static content (e.g. blog-post) onto the CDN and as such your site is still operating to >50% of it's features when your sever is down. (Just missing comments, new posts, announcements etc. but not the main content).
      - kevincox 6y ago
        Yup. Unless your site is so unreliable that it is likely to fail between serving the homepage and the assets the CDN will only hurt your availability.
        dathinab 6y ago
        You are forgetting that under high load availability of local servers is likely to degrade and serving non small parts of you content via CDN can noticeable reduce the load and as such improving local availability potentially improving total availability.
      - dragonwriter 6y ago
        > It doesn't help your website if your own server has issues while the CDN has the best exports ensuring its 99.999% uptime. That's certainly true of the server on which your APIs, if any, reside, but isn't it typical for your website itself to also leverage the CDN for distribution?
        ocdtrekkie 6y ago
        Distributing your website on a CDN is fine, but then, all of your fonts and JS belong on that same CDN. Basically, you should never have a production website which calls out to cdnjs.cloudflare.com or ajax.googleapis.com or fonts.googleapis.com, you should be hosting all of your site's dependencies in the same place or set of places. As a side perk, your site also will stop looking like trash for users who use browser extensions to block such external calls. ;)
      - wolco2 6y ago
        If you put 100% of the load on the local server you increase your chance of failure. Moving the bulk of the load to a cdn can reduce the load. You are only as good as your local server. Having a cdn means you need a better local server.
- thomasfromcdnjs 6y ago
  Yeah, I've said it here before but I created cdnjs.com 10 years ago or so. I use webpack and other more secure/performant strategies for all my JS needs when working in a serious environment. But when I am building something personal/light, I still load up cdnjs.com and drop something in. It's just easier than thinking about how I will serve files etc
viraptor 6y ago
I'm curious if this will result in any popular CDN folding. After a decent chunk of users update, they'll be hit with much more traffic than usual - and possibly more than they can afford in some cases.
- dathinab 6y ago
  Very unlikely IMHO. There is still caching, just not caching of the same resource used by different domains. Most people most times visit a small set of domains. All for which the resource still is cached from the previous visit. Combine it with the small likely hood to get a hit on cross domain caching the change in traffic is likely negligible.
ThePadawan 6y ago
So what we actually need is - a decentralized way to store these libraries - by a source with established trust (so it can't be misused for tracking) JS/CSS library blockchain?
- drran 6y ago
  So we need something like Fedora organization to make trusted distribution of javascript libraries for the web. As bonus, these libraries can be precompiled to native code ahead of time.
  - ThePadawan 6y ago
    Or just ship the libraries with the browsers. (Obviously also not ideal)
- viraptor 6y ago
  Like this? https://www.localcdn.org/ https://www.localcdn.org/ (Without the fancy / bs bingo technology)
- MaxBarraclough 6y ago
  From a quick search, there's apparently already a way to have the browser verify the cryptographic hash of a resource loaded from an external source: Subresource Integrity (SRI). [0] Can anyone comment on whether it's practical, and whether it could help here? [0] https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
  - majewsky 6y ago
    Define "help". With the new caching rules, there is just no way two sites with different TLDs can share asset caches, so it wouldn't help in the sense that double downloads could be avoided.
    - dathinab 6y ago
k_sze 6y ago
Assuming all browsers are going to implement this partitioning, doesn’t it give web devs even more reason to use 3rd-party CDNs? You’re not paying for the traffic and you don’t have to worry about users’ privacy.
Cloudef 6y ago
ipfs and bittorrent v2 solves this problem by addressing content with hashes rather than URL.
- freeone3000 6y ago
  it does not solve this problem at all, and in fact has the same problem -- it is possible to detect if content has been loaded before with ipfs in the same way as this. the remapping of content-id => content-data is not only trivial, it is required for ipfs to function in the first place.
newscracker 6y ago
> I have mixed feelings about these changes. I feel for those on low bandwidth and low data limit connections. Website developers should focus on bloat and address that. That doesn’t seem to be happening on a larger scale though. > It's excellent that browsers consider privacy, but it looks like anything can be misused for tracking purposes these days. Of course. Every bit of information you provide to a site will be misused to track and profile you. That’s what the advertising fueled web has gotten us to (I don’t blame it alone for the problems). I wasn’t aware that Safari had handled the cache privacy issue in 2013. It seems like it has always been way ahead on user privacy (thought it’s not perfect by any means). I’ve been a long time Firefox user who has always cleared the caches regularly, and I’m curious to know if any browser has consistently provided more privacy out-of-the-box than Safari.
titzer 6y ago
Unfortunately security and efficiency are at odds here. We faced a similar dilemma in designing the caching for compiled Wasm modules in the V8 engine. In theory, it would be great to just have one cached copy of the compiled machine code of a wasm module from the wild web. But in addition to the information leak from cold/warm caches, there is the possibility that one site could exploit a bug in the engine to inject vulnerable code (or even potentially malicious miscompiled native code) into one or more other sites. Because of this, wasm module caching is tied to the HTTP cache in Chrome in the same way, so it suffers the double-key problem.
jrochkind1 6y ago
Can anyone find any data on how often cache hits happened for shared resources from CDNs anyway? How useful was this actually? I'm not confident it was a non-trivial portion of bytes fetched by a typical session. But maybe it was. Has anyone found a way to measure in any way?
- eli 6y ago
  My sense is that it was always pretty low. What are the odds two sites use the same exact version of jquery and same third party cdn while the cache is still warm?
  - rpastuszak 6y ago
    I guess it really depends on the use case and the library. I can imagine a tonne of WP sites referencing jQuery from the Google CDN, e.g.: https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.mi... Looking at the headers the JS asset would be cached for 1 year.
    - dathinab 6y ago
      There are always a few exceptions. But you also must consider that most people most times visit a small set of domains. Which means that most times they will have jquery and similar cached even without cross domain caching.
  - aitchnyu 6y ago
    I guess the CDNs assume people should use libraries without version pinning, ie "latest".
- lopis 6y ago
  I feel that for a long time this has greatly lost it's usefulness. In a time when more websites are "webapps" built using webpack and other similar tools, we've seen a big decline in the use of CDNs.
- danShumway 6y ago
achairapart 6y ago
I wonder how long it will take for browsers to go beyond the cache concept and implement an integrated package repository so I can upload my manifest + my 3kb app.js and tell the browser to download (and store) all the dependencies I need. It will not only help with performance, but will also stop the absurd tooling madness that front-end has become.
- Ciantic 6y ago
  How does that differ from cache manifest (see link [1])? It's now being replaced with service workers, but largely storing the dependencies on first refresh is what it does. [1]: https://en.wikipedia.org/wiki/Cache_manifest_in_HTML5 https://en.wikipedia.org/wiki/Cache_manifest_in_HTML5
  - achairapart 6y ago
    This still works on a single website level. A common package manager will help every website that need the same deps (at least in the same semver range) with the benefit of a download once/available to everyone, true immutable, cache. Edit: The most common example. Let's say you need jQuery. The browser download the repo once and then it will be ready and available for maybe millions of website. Just think about the benefit of the saved bandwidth alone. I cannot stop to think how stupid is to download the same assets again and again and again for every website you visit.
    - ktpsns 6y ago
      Yep, this is kind of npm but for browsers. But already the sheer size of npm shows how this is hardly possible: http://www.modulecounts.com/ http://www.modulecounts.com/ -- I expect the npm repository to be at the size of two to three letters in gigabytes. This is quite large compared to the total hard disk cache of your browser (which also includes images, CSS, HTML, etc).
      - achairapart 6y ago
        Of course you don't need to download the whole repository as with npm. But just the links of the optimized distributable assets. In short, your /dist folder.
user5994461 6y ago
My guess is the impact of cross site caching is negligible. We're losing nothing here. 1) Cache hit must be extremely low because of different versions/variants/CDN for each library. (Have you seen how many jquery there are?). 2) It's irrelevant outside of the few most popular libraries on the planet, maybe jquery/bootstrap/googlefonts. 3) Content is cached once on page load and the saving are happening over the next tens or hundreds pages you visit. That's where the gain of caching is (10x - 100x). Saving 1 load when changing site is negligible in the grand scheme of things.
kreetx 6y ago
Perhaps using content security policy headers for trusted CDNs could fix this?
- speedgoose 6y ago
  One issue is privacy. With a common shared cache, a website can detect if you visited another specific website by loading the exact same resources from the same CDN and checking whether it's very fast to load because it's cached.
deleted 6y ago
[deleted]
llarsson 6y ago
So the natural progression here is that only big sites with their own CDN solution will be fast? And for most people and companies that will mean "rely on a large service to actual host your content for you", because they are not operating their own CDN. Because speed matters when it comes to search ranking. So they are then beholden to major platforms such as Google to host sites for them from a global cache? Similar to what AMP does, but for all kinds of content? Hmm.
- garganzol 6y ago
  Just as planned by a monopoly.
- dathinab 6y ago
  > So the natural progression here is that only big sites with their own CDN solution will be fast? No. This is about disabling cross domain caching. Which rarely has a cache hit already by now (see many other posts on this site). > "rely on a large service to actual host your content for you" This is the case anyway even with cross domain caching as the source you cache still needs to have the exact same URL including domain. The cross domain only refers to the site loading the resource. So e.g. `foo.example/jquery-3.2.1` and `bar.example/jquery-3.2.1` where never treated as the same at any point in time. The only think changed is that if `foo.example` and `bar.example` both depended on `cdn.example/jquery-3.2.1` and you visited `foo.example` before `bar.example` it might already have been cached when you visit `bar.example`. Through most times it wasn't as e.g. `bar` used a different CDN a different URL to the same resource or a different version. So this change doesn't really affect small sites more then any other side. And the effect is generally negligible.
- danShumway 6y ago
  > is that only big sites with their own CDN solution will be fast? No, not at all. This change gets rid of global caches. A) Your site caches will still work, they just won't be shared across sites. A cold-cache load of Gmail will go through the exact same process as the cold-cache load of your site, and subsequent loads of both sites will be just as fast. B) If your site's initial load time on a cold cache is unacceptable, you are already making an engineering mistake and you need to cut back on the Javascript. C) Most large sites are already choosing to bundle their own libraries or serve them from dedicated CDNs instead of trying to coordinate with each other to make sure the same resource location is used across multiple websites. D) Even in a theoretical world these changes were going to make the web a lot slower (and reminder, that world doesn't exist), the risk of library domination in that world would be larger than the risk of website domination. Imagine a world where you write a competitor to JQuery that's just as good, maybe even smaller and more efficient, but nobody uses it because "we have to use the popular library that's likely to be already in the user's cache." While we're on the subject of D, the fact that nobody says that -- that we don't see smaller JS libraries thrown aside in favor of libraries/versions that are more likely to be already cached -- is strong evidence that your site sharing a JQuery cache with someone like Google or the NYT is not an important performance concern.
donatj 6y ago
What is the most nightmare case of private information leaking here? I can't seem to come up with anything that horrible from my own imagining, especially not worth throwing away the advantage of cross domain resource caching. The example that they give, that you're logged into Facebook, doesn't seem very useful other than maybe fingerprinting? But even then 90 some percent are going to be logged in, so the only real fingerprinting there is on the people who aren't.
- WJW 6y ago
  Probably finding out that people are logged into some sort of site which leads to blackmail opportunities? Imagine finding out that a straight, married politician of the strict "family first" type is logged into a gay dating site. That would lead to some interesting "opportunities" to get them to vote in ways they would not otherwise do. There is also the possibility of leveraging this type of information in social engineering scenarios. Imagine getting compromising information on a sysadmin at a major commercial port and blackmailing a root password out of them, then leveraging that to set up a persistent threat and deleting their database every hour for a few weeks until they finally manage to lock you out again. The damage would be in the hundreds of millions. You could potentially do all the usual interesting things to foundries and/or oil refineries too if you manage to compromise insiders. Really, the sky is the limit if you use your imagination a bit.
trampi 6y ago
For anyone asking what this means in numbers: > The overall cache miss rate increases by about 3.6%, changes to the FCP (First Contentful Paint) are modest (~0.3%), and the overall fraction of bytes loaded from the network increases by around 4%. You can learn more about the impact on performance in the HTTP cache partitioning explainer. [0] [0]: https://developers.google.com/web/updates/2020/10/http-cache-partitioning https://developers.google.com/web/updates/2020/10/http-cache... Additional metrics: https://github.com/shivanigithub/http-cache-partitioning#impact-on-metrics https://github.com/shivanigithub/http-cache-partitioning#imp...
- rektide 6y ago
  This is an incredibly problematic number to report, bordering downright deceitful, because it ignores that we have not been able to use CDNs (because we have had to bundle our many JS files together, first for CommonJS, then for an ES-Module 1.0 specification with fixed/non-modular import addresses). But just recently, we have finally begun to pay off the technical debt to let us once more build web pages that use many different JS files from CDNs[1]. We are finally emerging from this long dark sad road to return to the glory of using CDNs that can cache our assets for us, let us share widely across the web. And just just just before ES Modules finally get good & modular & helpful, we destroy the shared cache that would have made them helpful. We have been on this voyage for 10 years, starting from the pre-modules but cached days, through the long dark & violent seas of modules-but-no-caching, to finally finally get to modules-that-cache-well. We finally have standards & tools in place that would allow us to begin to cache modules effectively, across sites. Except no, not any more. Whatever numbers you see for this, they are lies. They don't represent any honest truth. They portray only a poor reflection of a bad place that we have been desperate to escape from. We have wanted to cache modules effectively with CDNs for years, but ES Modules had not been suitable to the task. To judge the impact based only on what we can see, without projecting to what the web we were all trying to make happen: that's incredibly sad. We'll never know. All possibility is being chopped off and cut down. This is an incredibly sad, incredibly tragic culmination to a long long struggle to make the web better, and frankly, I am disappointed beyond words that the teams have taken such an aggressive change of defaults so casually for such minimal proven harm. If there is a real security issue here, it should have been dealt with via more Content Security Policy flags, not by unweaving the web & making each site have it's own view of the world, unique from every other site. The security atmosphere is paranoid & delusional, & nothing tops their inquest for absolute security. [1] https://www.bryanbraun.com/2020/10/23/es-modules-in-production-my-experience-so-far/ https://www.bryanbraun.com/2020/10/23/es-modules-in-producti...
dbrueck 6y ago
The negative effect is probably overblown; keep in mind that subsequent visits by the user to the same site can still use the cached version they loaded previously, and the odds of a cache hit in that case are relatively high.
ofrzeta 6y ago
At work we can no longer load stuff from CDNs anyway, because GDPR. For customer projects that is. I guess there would be the possibility to include it into some disclaimer but then we would need to check with the CDN about their data retention policy and check with the customer and that's just not worth it.
jacobr 6y ago
Even more food for thought - what if the cache is slower than the network? https://simonhearne.com/2020/network-faster-than-cache/ https://simonhearne.com/2020/network-faster-than-cache/
cblconfederate 6y ago
No mixed feelings, this is unconditionally good. Who ever thought it was ok to force your users to download stuff from unrelated, commercial servers

74 points by stefanjudis 6y ago

One of the benefits of using cdn resources is that it enables prototyping with, say, bootstrap so fast because you could essentially upload a single html file instead of a bunch of css, is,l and graphics. I mean, that will still be possible but there are more benefits to CDNs that just performance.

ocdtrekkie 6y ago
But the cost of it is making your site which normally only depends on one server depend on several. That inherently lowers the reliability of your site. I see no problem with using remotely hosted resources for prototyping. But you should never let a link to remotely hosted fonts or scripts make it into production code.
- wolco2 6y ago
  In isolation 1 is better than two. But when each of those servers is on new equipment with expert techs getting an alert if things go down the risk gets reduced. Unless your support on the single server is on par multiple managed may be safer.
  - TonyTrapp 6y ago
    It doesn't help your website if your own server has issues while the CDN has the best experts ensuring its 99.999% uptime. The probability of a failure is still a multiplicative factor of both uptimes, so it's strictly worse. Your user won't care if the CDN serving JS files is up while the website itself is unreachable. The only uptime that is relevant is that of your own server. Edit: Typo
    - dathinab 6y ago
      But what if you also put you static content (e.g. blog-post) onto the CDN and as such your site is still operating to >50% of it's features when your sever is down. (Just missing comments, new posts, announcements etc. but not the main content).
    - kevincox 6y ago
      Yup. Unless your site is so unreliable that it is likely to fail between serving the homepage and the assets the CDN will only hurt your availability.
      - dathinab 6y ago
        You are forgetting that under high load availability of local servers is likely to degrade and serving non small parts of you content via CDN can noticeable reduce the load and as such improving local availability potentially improving total availability.
    - dragonwriter 6y ago
      > It doesn't help your website if your own server has issues while the CDN has the best exports ensuring its 99.999% uptime. That's certainly true of the server on which your APIs, if any, reside, but isn't it typical for your website itself to also leverage the CDN for distribution?
      - ocdtrekkie 6y ago
        Distributing your website on a CDN is fine, but then, all of your fonts and JS belong on that same CDN. Basically, you should never have a production website which calls out to cdnjs.cloudflare.com or ajax.googleapis.com or fonts.googleapis.com, you should be hosting all of your site's dependencies in the same place or set of places. As a side perk, your site also will stop looking like trash for users who use browser extensions to block such external calls. ;)
    - wolco2 6y ago
      If you put 100% of the load on the local server you increase your chance of failure. Moving the bulk of the load to a cdn can reduce the load. You are only as good as your local server. Having a cdn means you need a better local server.
thomasfromcdnjs 6y ago
Yeah, I've said it here before but I created cdnjs.com 10 years ago or so. I use webpack and other more secure/performant strategies for all my JS needs when working in a serious environment. But when I am building something personal/light, I still load up cdnjs.com and drop something in. It's just easier than thinking about how I will serve files etc

viraptor 6y ago

I'm curious if this will result in any popular CDN folding. After a decent chunk of users update, they'll be hit with much more traffic than usual - and possibly more than they can afford in some cases.

dathinab 6y ago
Very unlikely IMHO. There is still caching, just not caching of the same resource used by different domains. Most people most times visit a small set of domains. All for which the resource still is cached from the previous visit. Combine it with the small likely hood to get a hit on cross domain caching the change in traffic is likely negligible.

ThePadawan 6y ago

So what we actually need is - a decentralized way to store these libraries - by a source with established trust (so it can't be misused for tracking) JS/CSS library blockchain?

drran 6y ago
So we need something like Fedora organization to make trusted distribution of javascript libraries for the web. As bonus, these libraries can be precompiled to native code ahead of time.
- ThePadawan 6y ago
  Or just ship the libraries with the browsers. (Obviously also not ideal)
viraptor 6y ago
Like this? https://www.localcdn.org/ https://www.localcdn.org/ (Without the fancy / bs bingo technology)
MaxBarraclough 6y ago
From a quick search, there's apparently already a way to have the browser verify the cryptographic hash of a resource loaded from an external source: Subresource Integrity (SRI). [0] Can anyone comment on whether it's practical, and whether it could help here? [0] https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
- majewsky 6y ago
  Define "help". With the new caching rules, there is just no way two sites with different TLDs can share asset caches, so it wouldn't help in the sense that double downloads could be avoided.
  - dathinab 6y ago

k_sze 6y ago

Assuming all browsers are going to implement this partitioning, doesn’t it give web devs even more reason to use 3rd-party CDNs? You’re not paying for the traffic and you don’t have to worry about users’ privacy.

Cloudef 6y ago

ipfs and bittorrent v2 solves this problem by addressing content with hashes rather than URL.

freeone3000 6y ago
it does not solve this problem at all, and in fact has the same problem -- it is possible to detect if content has been loaded before with ipfs in the same way as this. the remapping of content-id => content-data is not only trivial, it is required for ipfs to function in the first place.

newscracker 6y ago

> I have mixed feelings about these changes. I feel for those on low bandwidth and low data limit connections. Website developers should focus on bloat and address that. That doesn’t seem to be happening on a larger scale though. > It's excellent that browsers consider privacy, but it looks like anything can be misused for tracking purposes these days. Of course. Every bit of information you provide to a site will be misused to track and profile you. That’s what the advertising fueled web has gotten us to (I don’t blame it alone for the problems). I wasn’t aware that Safari had handled the cache privacy issue in 2013. It seems like it has always been way ahead on user privacy (thought it’s not perfect by any means). I’ve been a long time Firefox user who has always cleared the caches regularly, and I’m curious to know if any browser has consistently provided more privacy out-of-the-box than Safari.

titzer 6y ago

Unfortunately security and efficiency are at odds here. We faced a similar dilemma in designing the caching for compiled Wasm modules in the V8 engine. In theory, it would be great to just have one cached copy of the compiled machine code of a wasm module from the wild web. But in addition to the information leak from cold/warm caches, there is the possibility that one site could exploit a bug in the engine to inject vulnerable code (or even potentially malicious miscompiled native code) into one or more other sites. Because of this, wasm module caching is tied to the HTTP cache in Chrome in the same way, so it suffers the double-key problem.

jrochkind1 6y ago

Can anyone find any data on how often cache hits happened for shared resources from CDNs anyway? How useful was this actually? I'm not confident it was a non-trivial portion of bytes fetched by a typical session. But maybe it was. Has anyone found a way to measure in any way?

eli 6y ago
My sense is that it was always pretty low. What are the odds two sites use the same exact version of jquery and same third party cdn while the cache is still warm?
- rpastuszak 6y ago
  I guess it really depends on the use case and the library. I can imagine a tonne of WP sites referencing jQuery from the Google CDN, e.g.: https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.mi... Looking at the headers the JS asset would be cached for 1 year.
  - dathinab 6y ago
    There are always a few exceptions. But you also must consider that most people most times visit a small set of domains. Which means that most times they will have jquery and similar cached even without cross domain caching.
- aitchnyu 6y ago
  I guess the CDNs assume people should use libraries without version pinning, ie "latest".
lopis 6y ago
I feel that for a long time this has greatly lost it's usefulness. In a time when more websites are "webapps" built using webpack and other similar tools, we've seen a big decline in the use of CDNs.
danShumway 6y ago

achairapart 6y ago

I wonder how long it will take for browsers to go beyond the cache concept and implement an integrated package repository so I can upload my manifest + my 3kb app.js and tell the browser to download (and store) all the dependencies I need. It will not only help with performance, but will also stop the absurd tooling madness that front-end has become.

Ciantic 6y ago
How does that differ from cache manifest (see link [1])? It's now being replaced with service workers, but largely storing the dependencies on first refresh is what it does. [1]: https://en.wikipedia.org/wiki/Cache_manifest_in_HTML5 https://en.wikipedia.org/wiki/Cache_manifest_in_HTML5
- achairapart 6y ago
  This still works on a single website level. A common package manager will help every website that need the same deps (at least in the same semver range) with the benefit of a download once/available to everyone, true immutable, cache. Edit: The most common example. Let's say you need jQuery. The browser download the repo once and then it will be ready and available for maybe millions of website. Just think about the benefit of the saved bandwidth alone. I cannot stop to think how stupid is to download the same assets again and again and again for every website you visit.
  - ktpsns 6y ago
    Yep, this is kind of npm but for browsers. But already the sheer size of npm shows how this is hardly possible: http://www.modulecounts.com/ http://www.modulecounts.com/ -- I expect the npm repository to be at the size of two to three letters in gigabytes. This is quite large compared to the total hard disk cache of your browser (which also includes images, CSS, HTML, etc).
    - achairapart 6y ago
      Of course you don't need to download the whole repository as with npm. But just the links of the optimized distributable assets. In short, your /dist folder.

user5994461 6y ago

My guess is the impact of cross site caching is negligible. We're losing nothing here. 1) Cache hit must be extremely low because of different versions/variants/CDN for each library. (Have you seen how many jquery there are?). 2) It's irrelevant outside of the few most popular libraries on the planet, maybe jquery/bootstrap/googlefonts. 3) Content is cached once on page load and the saving are happening over the next tens or hundreds pages you visit. That's where the gain of caching is (10x - 100x). Saving 1 load when changing site is negligible in the grand scheme of things.

kreetx 6y ago

Perhaps using content security policy headers for trusted CDNs could fix this?

speedgoose 6y ago
One issue is privacy. With a common shared cache, a website can detect if you visited another specific website by loading the exact same resources from the same CDN and checking whether it's very fast to load because it's cached.

deleted 6y ago

[deleted]

llarsson 6y ago

So the natural progression here is that only big sites with their own CDN solution will be fast? And for most people and companies that will mean "rely on a large service to actual host your content for you", because they are not operating their own CDN. Because speed matters when it comes to search ranking. So they are then beholden to major platforms such as Google to host sites for them from a global cache? Similar to what AMP does, but for all kinds of content? Hmm.

garganzol 6y ago
Just as planned by a monopoly.
dathinab 6y ago
> So the natural progression here is that only big sites with their own CDN solution will be fast? No. This is about disabling cross domain caching. Which rarely has a cache hit already by now (see many other posts on this site). > "rely on a large service to actual host your content for you" This is the case anyway even with cross domain caching as the source you cache still needs to have the exact same URL including domain. The cross domain only refers to the site loading the resource. So e.g. `foo.example/jquery-3.2.1` and `bar.example/jquery-3.2.1` where never treated as the same at any point in time. The only think changed is that if `foo.example` and `bar.example` both depended on `cdn.example/jquery-3.2.1` and you visited `foo.example` before `bar.example` it might already have been cached when you visit `bar.example`. Through most times it wasn't as e.g. `bar` used a different CDN a different URL to the same resource or a different version. So this change doesn't really affect small sites more then any other side. And the effect is generally negligible.
danShumway 6y ago
> is that only big sites with their own CDN solution will be fast? No, not at all. This change gets rid of global caches. A) Your site caches will still work, they just won't be shared across sites. A cold-cache load of Gmail will go through the exact same process as the cold-cache load of your site, and subsequent loads of both sites will be just as fast. B) If your site's initial load time on a cold cache is unacceptable, you are already making an engineering mistake and you need to cut back on the Javascript. C) Most large sites are already choosing to bundle their own libraries or serve them from dedicated CDNs instead of trying to coordinate with each other to make sure the same resource location is used across multiple websites. D) Even in a theoretical world these changes were going to make the web a lot slower (and reminder, that world doesn't exist), the risk of library domination in that world would be larger than the risk of website domination. Imagine a world where you write a competitor to JQuery that's just as good, maybe even smaller and more efficient, but nobody uses it because "we have to use the popular library that's likely to be already in the user's cache." While we're on the subject of D, the fact that nobody says that -- that we don't see smaller JS libraries thrown aside in favor of libraries/versions that are more likely to be already cached -- is strong evidence that your site sharing a JQuery cache with someone like Google or the NYT is not an important performance concern.

donatj 6y ago

What is the most nightmare case of private information leaking here? I can't seem to come up with anything that horrible from my own imagining, especially not worth throwing away the advantage of cross domain resource caching. The example that they give, that you're logged into Facebook, doesn't seem very useful other than maybe fingerprinting? But even then 90 some percent are going to be logged in, so the only real fingerprinting there is on the people who aren't.

WJW 6y ago
Probably finding out that people are logged into some sort of site which leads to blackmail opportunities? Imagine finding out that a straight, married politician of the strict "family first" type is logged into a gay dating site. That would lead to some interesting "opportunities" to get them to vote in ways they would not otherwise do. There is also the possibility of leveraging this type of information in social engineering scenarios. Imagine getting compromising information on a sysadmin at a major commercial port and blackmailing a root password out of them, then leveraging that to set up a persistent threat and deleting their database every hour for a few weeks until they finally manage to lock you out again. The damage would be in the hundreds of millions. You could potentially do all the usual interesting things to foundries and/or oil refineries too if you manage to compromise insiders. Really, the sky is the limit if you use your imagination a bit.

trampi 6y ago

For anyone asking what this means in numbers: > The overall cache miss rate increases by about 3.6%, changes to the FCP (First Contentful Paint) are modest (~0.3%), and the overall fraction of bytes loaded from the network increases by around 4%. You can learn more about the impact on performance in the HTTP cache partitioning explainer. [0] [0]: https://developers.google.com/web/updates/2020/10/http-cache-partitioning https://developers.google.com/web/updates/2020/10/http-cache... Additional metrics: https://github.com/shivanigithub/http-cache-partitioning#impact-on-metrics https://github.com/shivanigithub/http-cache-partitioning#imp...

rektide 6y ago
This is an incredibly problematic number to report, bordering downright deceitful, because it ignores that we have not been able to use CDNs (because we have had to bundle our many JS files together, first for CommonJS, then for an ES-Module 1.0 specification with fixed/non-modular import addresses). But just recently, we have finally begun to pay off the technical debt to let us once more build web pages that use many different JS files from CDNs[1]. We are finally emerging from this long dark sad road to return to the glory of using CDNs that can cache our assets for us, let us share widely across the web. And just just just before ES Modules finally get good & modular & helpful, we destroy the shared cache that would have made them helpful. We have been on this voyage for 10 years, starting from the pre-modules but cached days, through the long dark & violent seas of modules-but-no-caching, to finally finally get to modules-that-cache-well. We finally have standards & tools in place that would allow us to begin to cache modules effectively, across sites. Except no, not any more. Whatever numbers you see for this, they are lies. They don't represent any honest truth. They portray only a poor reflection of a bad place that we have been desperate to escape from. We have wanted to cache modules effectively with CDNs for years, but ES Modules had not been suitable to the task. To judge the impact based only on what we can see, without projecting to what the web we were all trying to make happen: that's incredibly sad. We'll never know. All possibility is being chopped off and cut down. This is an incredibly sad, incredibly tragic culmination to a long long struggle to make the web better, and frankly, I am disappointed beyond words that the teams have taken such an aggressive change of defaults so casually for such minimal proven harm. If there is a real security issue here, it should have been dealt with via more Content Security Policy flags, not by unweaving the web & making each site have it's own view of the world, unique from every other site. The security atmosphere is paranoid & delusional, & nothing tops their inquest for absolute security. [1] https://www.bryanbraun.com/2020/10/23/es-modules-in-production-my-experience-so-far/ https://www.bryanbraun.com/2020/10/23/es-modules-in-producti...

dbrueck 6y ago

The negative effect is probably overblown; keep in mind that subsequent visits by the user to the same site can still use the cached version they loaded previously, and the odds of a cache hit in that case are relatively high.

ofrzeta 6y ago

At work we can no longer load stuff from CDNs anyway, because GDPR. For customer projects that is. I guess there would be the possibility to include it into some disclaimer but then we would need to check with the CDN about their data retention policy and check with the customer and that's just not worth it.

jacobr 6y ago

Even more food for thought - what if the cache is slower than the network? https://simonhearne.com/2020/network-faster-than-cache/ https://simonhearne.com/2020/network-faster-than-cache/

cblconfederate 6y ago

No mixed feelings, this is unconditionally good. Who ever thought it was ok to force your users to download stuff from unrelated, commercial servers