SPA route alias caching

[dead-claudia]

What problem are you trying to solve?

SPAs with path-based routing have terrible initial-response caching right now. This lack of caching can be mitigated server-side by just remapping the cache key, and some of the client-side growth is tamed by history.pushState, but that doesn't prevent an ever-growing state explosion on clients that'll eventually need cleaned up as they load directly into routes like https://example.com/@some.user or https://example.com/p/a1b2c3d4.

What solutions exist today?

None, really. There's no way to deduplicate the caches for path-based SPAs.

How would you solve it?

Use <base href="/path" alias="/foo /bar/* ..."> to set the cache key to the href value and configure its aliases. This is ignored unless the current URL matches either the base href or one of the given aliases.

Shared cache hits first resolve aliases, and then revalidate by fetching href, not the alias.

Anything else?

This is a potential tracking vector, but it's not a good one.

• First party tracking is considerably less dangerous than third-party tracking, and this makes even first-party tracking difficult.
• This merely directs caching, and as caches are commonly cleared without clearing site data like localStorage and service workers, they already have better ways to track anyways, even assuming the user's IP constantly shifts around.

Third parties MITMing to inject their own cache tracking (without care for page breakage) is a concern in insecure and mixed contexts, so this request should also only be honored in secure contexts. Most SPAs are created using newer practices, so they're likely already in secure contexts anyways.