A shared CDN URL does not mean a shared browser cache

Loading a popular library from a public CDN needs a better justification than the hope that another website already put it in your visitor's browser cache. Browser privacy partitioning weakens that cross-site assumption. Choose asset hosting by comparing the request path your visitors actually face, the delivery service you receive and the responsibility you retain.

This November 2026 retrospective returns to the week of 8 January 2025. Addy Osmani's explanation dated 7 January prompted renewed discussion of an older browser change. January was a useful moment to revisit a familiar optimization argument, rather than the date browsers suddenly stopped sharing cached resources across sites.

Identify which cache is supposed to help

The old argument was attractive. If unrelated websites requested exactly the same library URL, a visitor might arrive with those bytes already stored locally. The library's popularity could therefore appear to be a performance feature of your own website. That depended on the browser being allowed to reuse an entry across those contexts.

Chrome's implementation account describes partitioning beginning with Chrome 86, with rollout through late 2020. Its cache key includes the resource URL and an isolation key involving the top-level site and current-frame site. This is more specific than a universal formula saying every browser keys only by URL and top-level origin. Site, origin and frame context should not be treated as interchangeable terms.

The privacy purpose is to stop one site learning about another site's activity through shared cache state. For an asset-hosting decision, the consequence is narrower: an identical public URL does not establish that a cached response from an unrelated top-level site will be reused. A design should not count that presumed hit as a guaranteed saving.

That leaves two other useful kinds of reuse. A visitor may reuse assets within a compatible same-site context, subject to the browser's cache rules. Separately, a CDN edge can cache bytes near visitors and serve them without returning to the origin each time. Partitioning the browser cache does not eliminate the provider's edge cache. A network request that reaches a nearby edge is still different from no network request at all.

Compare an actual first visit

Consider an illustrative business application loading a font and a small JavaScript library. One option puts both assets on the application's own delivery infrastructure. Another uses a third-party public host. Compare the first visit without assuming either asset is already in the relevant browser partition. That exposes the request dependencies the application must really support.

A separate host can require separate connection work, depending on the connection and protocol conditions. The font may also depend on a stylesheet request before its own URL is known. These are reasons to inspect the path, not a claim that self-hosting always wins. Existing connections, asset sizes and the delivery arrangement can change the result.

The comparison should include the return visit to the application. Stable asset URLs and appropriate cache instructions can support reuse there even when cross-site reuse is unavailable. If every deployment unnecessarily changes an asset's identity, changing the hosting company alone will not solve that problem. Versioning and update behavior remain application decisions.

Ownership belongs in the performance decision

Self-hosting gives the application owner a direct place to decide which version is released and when it changes. It also creates work: obtain the files lawfully, retain the relevant licence information and keep dependencies updated. Moving an asset into the repository does not make its security or licensing obligations disappear.

Using a managed host changes that responsibility boundary. The team should understand version pinning, availability dependencies and what request information the third party receives. These are questions for the actual provider and project, not evidence that every CDN collects the same data or provides the same guarantees.

For the business owner, the useful consequence is a clearer account of what can delay the page and who can fix it. A dependency that is difficult to replace may deserve more attention than a tiny transfer difference. This article offers no measured latency saving, conversion increase or hosting-cost reduction for either option.

A CDN can still be the right choice

The strongest counterargument is geographic delivery and managed optimization. A provider may offer distribution, compression or asset variants that the application team would otherwise have to operate. Those benefits can justify using a CDN even if every new top-level site begins without a usable browser-cache entry for that resource.

Compare those benefits against the complete alternative. A self-hosted asset can itself be distributed through the site's CDN, so the choice is not always a remote edge versus a distant origin. Equally, recreating a provider's useful optimization pipeline may be unnecessary work. The decision should name the service being bought rather than borrowing an obsolete cache-sharing story.

The historical implementation account is evidence of the browser boundary it describes. It is not a permanent compatibility table for every browser available in November 2026. Recheck the browsers relevant to a real project before estimating impact. The January discussion also says nothing about Next.js application-data caches, which solve a different problem at a different layer.

For custom software development, write down the first-visit path, expected same-site reuse and delivery responsibilities before choosing where assets live. Keep a public CDN when its actual service earns its place. Remove the cross-site cache-hit assumption from the argument unless you have evidence that the relevant browser context can use it.