Re: [whatwg/fetch] Add Stale While Revalidate Handling (#853)

> 
> 
> The fetch changes are done as proposed in Chrome but to merge the PR into the formal specification WHATWG requires two browser vendors to commit to it (otherwise it remains a PR indefinitely). And that is the question I'm asking.

To properly answer: the fetch changes look good to me, I agree with them as they are stated in the proposed diff at the time of writing this comment.

There are two small things to add/note: 

1. as the background revalidation request's only constrain is to run at the original request's browsing context and be aborted with destruction of the context, we (Gecko) intend to lower its priority to a minimum to minimize its effect on the page load time during the critical loading phase.  It means, the revalidation request will hit the network likely no sooner than after the page load is finished, if a request for a stale-while-revalidate response is made early.

2. there is nothing said about possible coalescing of more than one such revalidation request.  the initial implementation for Gecko will not do any explicit coalescing, only implicit when two or more revalidation requests to the same URI happen to be started at the same time and race the common cache entry.  I intend to add telemetry probes on how this whole mechanism is going to work and if we find coalescing should but does not happen in significant(tm) amount of time, explicit coalescing may be implemented.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/853#issuecomment-479469294