Define the "Preload Cache"

[yoavweiss]

We need to define the preload cache, as currently it is not defined and different implementations are doing observably different things.

This issue was opened on the Preload spec, but as the cache would mostly sit inside Fetch and it's not clear what action would be needed on the preload spec side, I'm "moving" it here.

Related previous discussion here was at #354 where @jakearchibald made a proposal to address this. I open this as a separate issue as I think the H2 push cache and the preload cache are inherently different things in different layers.

I think that anything we define here should, to some extent, look at how the different implementations tackle this today. The logic that they apply for this (e.g. in Blink or in WebKit) seems a bit complex, but was created for the "memory cache" case. We need to think if it can be safely simplified for the preload case. (and if memory cache itself should be standardized)

[wanderview]

What preload cache behavior is desired when document.open() is called? It seems the document is preserved, but "reset" in this case. The spec and firefox also create a new global. Should preload cache be cleared or preserved across document.open()?

[annevk]

I think we should just pick something and make sure it's tested. If we can get away with not creating a new global for document.open() (which would simplify matters quite a bit, as a document can then only ever be associated with a single global) it would probably be most natural that the cache is kept.

[igrigorik]

I open this as a separate issue as I think the H2 push cache and the preload cache are inherently different things in different layers.

From a developer ergonomics perspective, it would be nice if that wasn't the case. As it stands, there are subtle (potentially) observable differences in behavior between pushing and preloading a resource — one ends up in h2 push cache, other in renderer's memory cache, at least for Chrome. It would be nice to normalize all this, for everyone's sanity.. if we can.

(and if memory cache itself should be standardized)

Given that, afaik, every implementation has one. Yes? Which is what we're after here.. :)

[wanderview]

Given that, afaik, every implementation has one. Yes? Which is what we're after here.. :)

Gecko at least does not have a memory cache like chromium. We have things like image cache, but that is defined in the html spec.

From my perspective the thing I want to know about these caches is:

Do they sit above or below the network stack where service worker interception occurs?

SW sits above the http cache and below the image cache in the spec today.

[kinu]

Wanted to know if people expect that preload cache we're trying to define here also covers the prefetch case or not. From impl perspective they sit at different layers and behave slightly different (i.e. they have different lifetime), but from developers perspective the behavior may look pretty similar.

To give more context Chromium's current impl is like this: preload cache sits next to a memory cache, i.e. it's above the network stack and also above SW. Prefetch basically just puts things in HTTP cache (and never put them in memory cache or preload cache equivalent thing in Chromium). Both preload and prefetch allow subsequent fetches to succeed regardless of the Cache control up to a certain period, but that effect doesn't stick across different navigations / different fetch groups for preload, while it does for prefetch.

[sleevi]

@wanderview wrote:

Do they sit above or below the network stack where service worker interception occurs?
SW sits above the http cache and below the image cache in the spec today.

The H/2 PUSH cache sits above the network and above the HTTP cache, below SW.
The Preload cache sits above SW and below/beside the image cache.

[yoavweiss]

The H/2 PUSH cache sits above the network and above the HTTP cache, below SW.

I think it's conceptually below the HTTP cache at least as implemented today (as resources don't get committed to the HTTP cache until they are "claimed" from the H2 push cache)

[yoavweiss]

Looking back at this, I think this work was simplified by @yutakahirano's recent(ish) refactoring of Chromium's implementation, which split the preload cache from the memory cache.
I'll try to find the time in the next few days to document what the current Chromium logic is.

[annevk]

Oh, I missed that the memory cache and the preload cache got separated. It seemed kinda preferable to me if all these mechanisms would end up in the same cache. I think at least that in Firefox that's what we're planning to use for rel=preload.

cc @smaug---- @emilio @mayhemer @ddragana

[youennf]

I think at least that in Firefox that's what we're planning to use for rel=preload.

I believe WebKit does the same thing.