Hacker News Reader

Comment by snowwrestler | Hacker News Reader

I always felt like this was mostly a dream anyway due to the diversity of libraries, versions, and CDNs across the web. Everything would have to line up perfectly, within the TTL, to get the performance advantage of loading from cache. And even then it was only really an advantage on the first page load of a site visit; subsequent pageloads would hit cache anyway from the first page.

And speaking of privacy... if everyone across the web is loading resources from one CDN, that seems like an interesting stream of data for that CDN.

View on HN

I think it may have had more benefit in the jQuery heyday. Things are much more fragmented now.

Absolutely. And resources like disk space and bandwidth have gotten much cheaper in the 13 years since jQuery was invented. Fewer cache hits, lower cache value, and less cost savings all point in the direction of retiring this feature.

You say this, but for people who have shit internet are acutely aware how cdn's no longer help things from the users' perspective beyond the mere "cdn's are better at delivering some assets than joe website."

It doesn't help that relative to everything else the churn in websites is immense, making the chance you'll have to pull in things more likely. And relative to everything is quite a statement, as churn in software is pervasive.

EDIT: that is, I'm just complaining, not claiming the status quo (or what was before) was better, obviously.

That’s what I found as well: every time I measured the benefits were much lower than hoped, and especially where you wanted it the most on mobile the cache sizes were small enough that they churned frequently. Way back in the day, the low per-host connection limits were a consideration but that era is firmly dead.

The other side was that people notice slow performance more than fast, and the failure modes were always worse than the savings when some fraction of connections would take, say, 2 seconds to connect to Google’s CDN even though their time to yours was much better. You don’t have an easy option for those slow clients hitting your property but you can at least reduce the number of dependencies to that one service.

One way to prevent a CDN from seeing every request for a shared resource could be a new attribute that allows serving the resource locally if the resource is not in the shared cache.

For example, <script src="/jquery-3.4.1.min.js" try-shared="https://code.jquery.com/jquery-3.4.1.min.js" try-shared="another-src">

@src can be locally hosted. If it's not in cache, the browser can try each @try-shared attr (without loading the resource from CDN). If no match, the browser downloads @src from your own domain.

Of course, this doesn't solve the Shared Cache issue raised by the article. Suppose the only way to solve that would require adding resources to the shared cache explicitly. The most effective way (I assume) would be a header provided by the CDN of a shared resource, eg, X-Shared-Cache: true, that a browser would recognize... Then @src/@try-shared could still get the benefits of the shared cache and developers don't have to worry about it.

If everyone would do it like that, the file would never be pulled from the CDN at all (since a cache miss pulls from the local src), therefore the try-shared attribute would never be useful.

Sure, if everyone decides to host their own files, a CDN would never be used. Although, there are benefits to using a CDN, so it's likely the try-shared value could exist and would be useful.

Note the proposed scheme doesn't prevent anyone from using a CDN as the src while also trying other CDNs to increase the chances of a cache hit, which has its own benefits.

For example, <script src="https://code.jquery.com/jquery-3.4.1.min.js" try-shared="https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.mi... try-shared="another-src">

The better way to do this is to specify the vendored location and hash of the resource.

That way, you can safely leverage any version regardless of its downloaded location.

Content digests are already used in the `integrity` HTML attribute; it could be used for a cache key too.

It still has the version fragmentation problem, but you don't have to worry about picking a popular CDN.

> if everyone across the web is loading resources from one CDN, that seems like an interesting stream of data for that CDN

And if big brother isn't balls deep in CloudFlare I'll eat my hat.

You don't even need to be considering outside/government intervention for this to be concerning. How many sites rely on JS from the Google JS CDN? (https://developers.google.com/speed/libraries/)

For the vast majority of people, the negative effects of Google tracking them is probably more concerning than the government tracking them.

Ironically the change described in this article will give the CDN more information as it now receives a request for each site and not just the first.

For many websites first load is all that matters. If user is hooked, he'll wait for subsequent loads.

If your perspective is only that of a developer, which is fine, this is a developers' website, then in fact it doesn't matter at all, because the whole space has this experience, so no one actor is at a disadvantage anymore unless you like self-host on your home PC.

For users on the other hand...

Reply on news.ycombinator.com