Does Google's JavaScript cache really work based on origin instead of domain?

What is the technical difference between origin-based caching and domain-based caching?

An origin combines three elements: the protocol (https), the domain (example.com), and the port (443 by default). Two URLs with different subdomains constitute two distinct origins. Thus, https://www.example.com and https://cdn.example.com represent two separate origins from the perspective of web security and — according to Martin Splitt — Google's cache.

This distinction is significant. Many SEOs believed that Google could share a cache of common resources (React, jQuery, Bootstrap) across different sites using the same public CDN. Splitt's assertion closes that door: each origin has its own storage space for JavaScript, CSS, and other assets. No pooling, no shortcuts.

How does this caching architecture impact crawling and rendering?

Googlebot crawls pages and downloads the resources necessary for rendering to understand the content generated through JavaScript. If your site loads JS from several different origins, Google will download and cache these resources separately for each origin. No reuse even if the file is strictly identical.

This means that spreading your resources across multiple subdomains or CDNs can increase the volume of requests and slow down the rendering process on the part of Googlebot. For a site with a limited crawl budget, every additional request counts. The more you fragment your origins, the more bandwidth and processing time you consume.

Does this logic also apply to common third-party resources?

Yes, and that’s where it gets tricky. Imagine your site loading jQuery from cdnjs.cloudflare.com. Millions of sites do the same. One might think that Google keeps this library cached and reuses it from one site to another. False. According to Splitt, each origin (here cdnjs.cloudflare.com for your site, but isolated from the cache of other sites) has its own cache.

This challenges the common belief that using a popular public CDN would speed up processing by Google. The benefit exists for your human visitors whose browsers indeed share cache between sites, but not for Googlebot. This nuance changes the game on the self-hosting vs third-party CDN arbitration.

• Origin = protocol + domain + port, not just the root domain
• No cache sharing between different sites even for identical resources
• Each subdomain constitutes a distinct origin with its own cache
• Spreading resources across multiple origins can increase Googlebot's rendering time
• Using public CDNs does not speed up processing on Google's side unlike regular browsers

Is this statement consistent with field observations?

It's hard to answer with certainty. We do not have access to Google's internal logs to verify whether the caching behavior matches exactly what Splitt describes. Empirical tests on rendering times show variations, but isolating the 'origin-based cache' variable remains complex in such an opaque system.

Some SEOs report that consolidating resources on a single origin does indeed improve the perceived rendering speed in Search Console. Others see no measurable difference. [To be verified] with rigorous A/B tests on high-volume sites to obtain statistically significant data. Meanwhile, we navigate between official theory and empirical observations.

Why wouldn't Google adopt a shared cache for common resources?

Let's be honest: technically, Google could absolutely implement a global cache for ultra-popular libraries like React or jQuery. Browsers have been doing it for years. Why does Google refrain from this? Several hypotheses — and this is where Splitt's statement lacks substance.

The first hypothesis: security and isolation. Sharing a cache between origins can create timing attack vectors or cache pollution. Google may favor a sealed architecture. The second hypothesis: technical simplicity. Maintaining a shared cache at web scale requires a complex infrastructure. The third, more cynical hypothesis: no strong commercial incentive for Google to optimize the crawling of third-party resources.

In what cases might this rule have exceptions?

Splitt mentions a 'caching system' without specifying whether this logic applies uniformly to all types of resources. Do web fonts, for example, follow the same model? And images hosted on third-party CDNs? The statement remains vague regarding the exact scope.

Additionally, Google has internal optimization mechanisms (resource hints, preload, HTTP/2 push) that can bypass or complement traditional caching. It's not impossible that some critical resources receive preferential treatment that is undocumented. Without complete transparency, we can only make cautious hypotheses.

What should you practically do with this information?

Auditing the dispersion of your resources is the first step. List all the origins from which your site loads JavaScript, CSS, fonts, and images. If you count more than 3-4 different origins for critical rendering resources, you could optimize.

Next, evaluate the cost/benefit ratio. Consolidating everything on a single origin can simplify Googlebot's cache, but if your third-party CDN offers latency far lower than your main server, the cache gain won’t compensate for the loss in network speed. Test, measure, compare. Search Console and mobile rendering tools will give you insights into real processing times.

What mistakes should be avoided when reorganizing resources?

Don't fall into the trap of blind self-hosting. Hosting jQuery or React on your own server to 'consolidate the origin' only makes sense if your infrastructure is performant, with HTTP/2, Brotli compression, and adequate bandwidth. Otherwise, you’ll degrade performance for your human users with no real gain for Googlebot.

Another common mistake: multiplying subdomains without reason. Creating cdn1.example.com, cdn2.example.com, assets.example.com just to 'balance the load' or 'look professional' unnecessarily fragments your origins. If you're using a single server behind, this dispersion brings no technical benefit and complicates caching according to Splitt's logic.

How can you check if your architecture is optimal for Google rendering?

Use the URL Inspection tool in Search Console and examine the rendering report. Google shows you the loaded resources and the time required. If you see abnormally long delays for resources hosted on secondary origins, that’s a signal.

Also, compare performance before and after an origin migration. If you centralize your critical JS on your main domain, monitor Core Web Vitals metrics and the indexing rate of JavaScript-heavy pages. Even a slight improvement can validate the hypothesis. If there's degradation, immediate rollback and reassessment of the strategy.

• Audit all third-party origins used for critical rendering resources
• Consolidate JavaScript and CSS resources across a minimal number of origins (ideally 1-2 maximum)
• Ensure your main server supports HTTP/2, Brotli compression and has acceptable latency
• Avoid multiplying subdomains without real technical justification
• Test the impact on rendering via Search Console URL Inspection before and after modification
• Monitor Core Web Vitals and indexing rates of JS pages to validate changes