Browser caching across multiple subdomains impossible because of Vary: Origin response header for kit assets

[anthonyplopper]

After the initial load, unique WebAwesome assets are cached within the browser so on subsequent loads they are loaded from the browser cache. In our case, this can save in the ballpark of ~100 requests totaling ~500kb, and the first load takes noticeably longer to render as all the assets are fetched for the first time.

We are using this kit across multiple subdomains, like subdomain.example.com and www.example.com, and users regularly move between the two. Unfortunately, as currently configured, the assets are unable to be re-used between the two subdomains, slowing down the initial load time considerably.

The header Vary: Origin instructs the browser to partition its cache by requesting origin. Wondering if there is a specific reason it has been set to Vary: Origin. If this header could be removed, our users load time could be improved significantly. Thank you!

[claviska]

@KonnorRogers @robmadole @timcrowell do you folks see any issue removing the Vary: Origin header to alleviate this problem?

[anthonyplopper]

Looking forward to hearing back on this. We had done research for our own web app and come to the conclusion that as long as there is nothing sensitive in the js files, a setup allowing a browser to cache static js/css resources across domains was not an issue. The only sensitive information here appears to be the kit id, which is already present in the asset urls.
The performance gains for first time users on our signup subdomain clicking through from our main website are not insignificant, so I'm hopeful an adjustment can be made. Thank you!

[robmadole]

Hey there @anthonyplopper. I would like to draw your attention to a concept: double-keyed caching.

Addy Osmani has a good post about it here.

The short of it: even if we remove the Origin part of the Vary header the browser is still going to keep separate caches. So it won't help as far as I'm aware.

To @claviska's point, it is a security measure. By varying the cache on that header we're able to protect sites' Kits from unauthorized access.

[anthonyplopper]

@robmadole Thank you for the response. This article is very helpful to understand the security concerns.

However, in our case they both do share the same "topLevelSite" - our main domain, so shared caching is possible:
www.ourcompanydomain.com
and
signup.ourcompanydomain.com
So for both the topLevelWebsite would be: ourcompanydomain.com

We had to change the Vary: Origin on our own shared assets on these domains to allow them to be cached between the two domains on a user's browser, and it works perfectly.

In reading through the article, it seems he is saying at points that won't work, but we have verified it does at least on the most popular browsers

And indeed he lists browsers as having the following implementation for cache keys (in early 2025):
Chrome: Uses top-level site + frame site
Safari: Uses top-level eTLD+1
Firefox: Planning top-level scheme://eTLD+1

eTLD+1 in our case would be ourcompanydomain.com
and we've verified Chrome allows the two to share a cache, so it must be using a similar approach at the moment.

[robmadole]

@anthonyplopper Ah, I understand.

Unfortunately we can't implement the same thing as a system-wide option. Shared hosting platforms would break our security measures.

You might be at the point where it's time to download your Kit and self-host. Have you considered this option?

[anthonyplopper]

Would there perhaps be a way to add an option to specify white-listed topLevelSites within the specific WA project settings page
https://webawesome.com/teams/*/projects/*
and then have WA update the Vary: header if the request origin is on the white list?