Contact emails
Explainer
Spec
https://tools.ietf.org/html/rfc5861
Tag Review
Summary
Enable handling of stale-while-revalidate in HTTP Cache-Control header allowing the browser cache to return a stale resource while asynchronously revalidating the resource.
We conducted a finch trial and 11-12% of network requests for the hosts were actually stale and returned a response before revalidating it. Overall these resources were very well cached already (81% increased to 82%).
The results show a reduction of FCP by about 2.43% at the 50th percentile, and 2.96% at the 99th percentile.
Link to “Intent to Implement” blink-dev discussion
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Risks
Interoperability and Compatibility
This is an optimization of handling of requests so the risk is low that a user would see unintended results.
Edge: No signals
Firefox: No signals
Safari: No signals
Web / Framework developers: Positive. We have large partners already serving up stale-while-revalidate headers and are excited to see this ship.
Ergonomics
There is some risk since stale while revalidate handling is only for subresource requests and not the main document. This should not cause observable issues to the end user but could be an unexpected result from the web developer.
Secondly there is some risk with Service Workers. The fetch API doesn't have an extension to load a resource with stale revalidation. It does have an API to fetch resources from the cache without any staleness check. So it is possible to implement stale while revalidate handling already today in a service worker but there is no functionality to take advantage of the built in behavior.
Activation
No. Relatively easy to activate. Adjust Cache-Control HTTP Header.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
No. This is an implementation detail of caching behavior not testable in WPT.
Entry on the feature dashboard
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZXecWHSnv-Ph3s_CRr9Bc3e_j91xZaFv8dUC13yZnQT5A%40mail.gmail.com.
Spec
https://tools.ietf.org/html/rfc5861
Tag Review
Summary
Enable handling of stale-while-revalidate in HTTP Cache-Control header allowing the browser cache to return a stale resource while asynchronously revalidating the resource.
We conducted a finch trial and 11-12% of network requests for the hosts were actually stale and returned a response before revalidating it. Overall these resources were very well cached already (81% increased to 82%).
The results show a reduction of FCP by about 2.43% at the 50th percentile, and 2.96% at the 99th percentile.
Link to “Intent to Implement” blink-dev discussion
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Risks
Interoperability and Compatibility
This is an optimization of handling of requests so the risk is low that a user would see unintended results.
Edge: No signals
Firefox: No signals
Safari: No signals
Web / Framework developers: Positive. We have large partners already serving up stale-while-revalidate headers and are excited to see this ship.
Ergonomics
There is some risk since stale while revalidate handling is only for subresource requests and not the main document. This should not cause observable issues to the end user but could be an unexpected result from the web developer.
Secondly there is some risk with Service Workers. The fetch API doesn't have an extension to load a resource with stale revalidation. It does have an API to fetch resources from the cache without any staleness check. So it is possible to implement stale while revalidate handling already today in a service worker but there is no functionality to take advantage of the built in behavior.
Activation
No. Relatively easy to activate. Adjust Cache-Control HTTP Header.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
No. This is an implementation detail of caching behavior not testable in WPT.
--
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZWdmNYy4UxKEqEBd8%3DWVv6rOeHNCOq4EsrH5FwmRro-dA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2BkXJMJ_wiiXw8swm%2B%3Db9LgiKTFx75vr0ChZvum-bVX%3DQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZXND%2B7c7fz62pxvKNH2jorJ_RvZghVEiEC8%2B1o76n%2BCHg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZXuNiEY%2B5CB%3DO5qSitLCc3%3D0yqqn0yLkw-E23%3DFrxCW1w%40mail.gmail.com.
A Pull request will be submitted against the fetch spec hopefully this week. Thanks to Josh's hint I've been able to rewrite the layout tests in WPT format here: https://chromium-review.googlesource.com/c/chromium/src/+/1383297 up for review.
dave.On Wed, Dec 19, 2018 at 10:33 AM Ben Kelly <wande...@chromium.org> wrote:On Mon, Dec 10, 2018 at 1:37 PM Dave Tapuska <dtap...@chromium.org> wrote:Do you have links to other spec discussion or PRs? The following behavior is not defined in this linked spec document AFAICT:1. Feature disabled for fetch/xhr2. Feature exposes additional observable entries in ResourceTiming3. Interaction (or lack of interaction) with service workersI just want to make sure other browsers can implement this feature in an inter-operable way without reverse engineering chrome.Thanks.Ben
--
The PR against the fetch spec is here. My intention is to hook the html spec that delegates to the fetch spec indicating the cache-mode is "stale-while-revalidated" for specific cases. Does that answer your question?
return type == ResourceType::kMainResource || type == ResourceType::kRaw || type == ResourceType::kTextTrack || type == ResourceType::kAudio || type == ResourceType::kVideo || type == ResourceType::kManifest || type == ResourceType::kImportResource;
So that essentially means all fetches that aren't the main document, audio, video, import resource loads, preconnects, downloads. Do you have an alternate way I can make this simpler? I imagine it will be difficult to articulate in the HTML spec.
dave.
Yes I'm referring to the commit.>In that commitYes you are correct in what I was trying to do. If you have alternate suggestions please provide them.>Can you elaborate on which cases the flagIn Chrome we currently are allowing only GETs, that aren't the following resource types:return type == ResourceType::kMainResource || type == ResourceType::kRaw || type == ResourceType::kTextTrack || type == ResourceType::kAudio || type == ResourceType::kVideo || type == ResourceType::kManifest || type == ResourceType::kImportResource;
So that essentially means all fetches that aren't the main document, audio, video, import resource loads, preconnects, downloads. Do you have an alternate way I can make this simpler? I imagine it will be difficult to articulate in the HTML spec.
// Indicate whether the network stack can return a stale resource. If a // stale resource is returned a StaleRevalidation request will be scheduled. // Explicitly disallow stale responses for fetchers that don't have SWR // enabled (via origin trial), non-GET requests and resource requests that // are raw. We are explicitly excluding RawResources here to avoid // unintentional SWR, as bugs around RawResources tend to be complicated and // critical.It would be good to detail the reasoning here, ideally in a GH issue on the Fetch spec and/or in a spec note close to where the flag will be set.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZXhtNdnHqp%2BDBEOkB-yE19ur1EpRgQkPKdzpCEchrQWVg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZWSEpeytjYDJRZNPXc4XcFQLTpYybB%3DR2PPiD-WME054w%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEiDdvCeZeOkN3SNA6C2WSJ5CujfLW%3DxZTdMCHFw33BcMg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZW4M7nvNY081DyZwMZkpteojG8-NwJA4VBWEqR%3DOpGtOA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZVbLNnOri%3Dusc9iH-od1Woq4GSugVBh90hxtxNL1xHRQw%40mail.gmail.com.
On Wed, Mar 13, 2019 at 10:23 AM Yoav Weiss <yo...@yoav.ws> wrote:
> It makes it harder to keep track of the feature's evolution and have reasonable source control for it once it lands, as PRs typically tend to get squashed.
I'm not sure I understand this.
> It makes it hard for reviewers to understand where a feature currently stands
Which reviewers?
On Wed, Mar 13, 2019 at 10:40 AM Anne van Kesteren <ann...@annevk.nl> wrote:On Wed, Mar 13, 2019 at 10:23 AM Yoav Weiss <yo...@yoav.ws> wrote:
> It makes it harder to keep track of the feature's evolution and have reasonable source control for it once it lands, as PRs typically tend to get squashed.
I'm not sure I understand this.A single feature is typically worked on over multiple months, with multiple contributors. If we want all that feature work to live in a single PR until another implementation shows interest, it means that when that work will get merged, that history will likely not be reflected in the final spec's revision control.
> It makes it hard for reviewers to understand where a feature currently stands
Which reviewers?Browser engineers and browser vendors, as well as web developers interested in the feature. They need a convenient way to evaluate where the feature is (in the case of other vendors, in order to get their support), and right now, that's a challenge.
As far as standards are concerned, it's very similar
to v0 Web Components I'd say.
> One example of that: I'm currently working on Client Hints, did a bunch of work of unifying multiple PRs from multiple people into a single Fetch PR, and I'm still getting complaints that the state of the feature is currently not clear, as reviewers need to look at a couple of PRs (on Fetch and HTML) to understand the situation. Now I have a task on my plate to create a separate document that will monkey patch those specifications, to make it clearer for folks where things are and where the feature is going.
Yeah, the Client Hints situation hasn't been great. It was somehow
"done" without end-to-end integration.
> Also, let's talk about the elephant in the room while we're at it. With Edge/Chromium, is the assumption that it will no longer count as a separate implementation?
I think the elephant in the room is that Chrome is moving ahead with
things despite not having buy-in from others, reminiscent of the
Netscape days. Seems rather clear that Microsoft using the same engine
as Google would not count as a distinct implementation.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgnqPedAdOoq4DFJU3hzpzTrrz7oVYXStVJ8NQVLzRPbg%40mail.gmail.com.
On Wed, Mar 13, 2019 at 9:38 AM Anne van Kesteren <ann...@annevk.nl> wrote:On Tue, Mar 12, 2019 at 7:28 PM Chris Harrelson <chri...@chromium.org> wrote:
> The situation with policy about when it's ok to land spec changes in HTML is not so good, this needs to improve somehow.
This isn't HTML, it's Fetch, though the same policy applies to both.
What's not good about it? It seems to me that if there's no two
implementations it's not really a standard. (And the bar is lower than
that, only need interest.)I agree with that general sentiment.However, the current situation where shipping features are backed by PRs is not ideal:
- It makes it harder to keep track of the feature's evolution and have reasonable source control for it once it lands, as PRs typically tend to get squashed.
- It makes it hard for reviewers to understand where a feature currently stands
- One example of that: I'm currently working on Client Hints, did a bunch of work of unifying multiple PRs from multiple people into a single Fetch PR, and I'm still getting complaints that the state of the feature is currently not clear, as reviewers need to look at a couple of PRs (on Fetch and HTML) to understand the situation. Now I have a task on my plate to create a separate document that will monkey patch those specifications, to make it clearer for folks where things are and where the feature is going.
- Other specifications (e.g. SXG loading) seem to be going down a similar path ( +Jeffrey Yasskin for Opinions™)
On Wed, Mar 13, 2019 at 2:23 AM Yoav Weiss <yo...@yoav.ws> wrote:On Wed, Mar 13, 2019 at 9:38 AM Anne van Kesteren <ann...@annevk.nl> wrote:On Tue, Mar 12, 2019 at 7:28 PM Chris Harrelson <chri...@chromium.org> wrote:
> The situation with policy about when it's ok to land spec changes in HTML is not so good, this needs to improve somehow.
This isn't HTML, it's Fetch, though the same policy applies to both.
What's not good about it? It seems to me that if there's no two
implementations it's not really a standard. (And the bar is lower than
that, only need interest.)I agree with that general sentiment.However, the current situation where shipping features are backed by PRs is not ideal:
- It makes it harder to keep track of the feature's evolution and have reasonable source control for it once it lands, as PRs typically tend to get squashed.
- It makes it hard for reviewers to understand where a feature currently stands
- One example of that: I'm currently working on Client Hints, did a bunch of work of unifying multiple PRs from multiple people into a single Fetch PR, and I'm still getting complaints that the state of the feature is currently not clear, as reviewers need to look at a couple of PRs (on Fetch and HTML) to understand the situation. Now I have a task on my plate to create a separate document that will monkey patch those specifications, to make it clearer for folks where things are and where the feature is going.
- Other specifications (e.g. SXG loading) seem to be going down a similar path ( +Jeffrey Yasskin for Opinions™)
So far, I like the approach SXG loading is taking, and I think I'd like it even if we'd decided to block shipping on Mozilla or Apple deciding the feature is a good idea. Specifically, living in a document lets us do code reviews on changes to that document, which lets us at least ask if changes to the proposal make Mozilla and Apple incrementally happier. Having the proposal live in a PR wouldn't give them that ability to comment on or see changes.There's always going to be a speed bump in tracking history across the actual merge: for a separate document, people have to find the original repository and annotate there. For a PR, the PR author has to do a lot of extra work to keep the sequence of changes meaningful across merges from (or rebases onto) the main spec, and the merge has to either happen as a merge, or the person trying to search the history has to jump over to Github. So I don't feel like the question of how much history is preserved really helps decide between these options.
On Wed, Mar 13, 2019 at 10:40 AM Anne van Kesteren <ann...@annevk.nl> wrote:On Wed, Mar 13, 2019 at 10:23 AM Yoav Weiss <yo...@yoav.ws> wrote:
> It makes it harder to keep track of the feature's evolution and have reasonable source control for it once it lands, as PRs typically tend to get squashed.
I'm not sure I understand this.
> It makes it hard for reviewers to understand where a feature currently stands
Which reviewers? As far as standards are concerned, it's very similar
to v0 Web Components I'd say.
> One example of that: I'm currently working on Client Hints, did a bunch of work of unifying multiple PRs from multiple people into a single Fetch PR, and I'm still getting complaints that the state of the feature is currently not clear, as reviewers need to look at a couple of PRs (on Fetch and HTML) to understand the situation. Now I have a task on my plate to create a separate document that will monkey patch those specifications, to make it clearer for folks where things are and where the feature is going.
Yeah, the Client Hints situation hasn't been great. It was somehow
"done" without end-to-end integration.
> Also, let's talk about the elephant in the room while we're at it. With Edge/Chromium, is the assumption that it will no longer count as a separate implementation?
I think the elephant in the room is that Chrome is moving ahead with
things despite not having buy-in from others, reminiscent of the
Netscape days. Seems rather clear that Microsoft using the same engine
as Google would not count as a distinct implementation.I wasn't around to see the shipping process in the Netscape days, but the bar for shipping new features in Blink is quite high in terms of work required. In order to make it as easy as possible for other vendors to implement and ship, we ask for a spec and test suite that matches the implementation. By contrast, lots of stuff shipped in the Netscape/IE is called DOM appeared to have unspec'd and untested, leaving that for decades later.We rely on the code review process for spec and test quality, just like for the implementation. I'm sure you'd be able to find exceptions, but when I've taken a deep dive on an intent both spec and tests tend to be there by the time the intent has 3xLGTM.
On Wed, Mar 13, 2019 at 12:26 PM Philip Jägenstedt <foo...@chromium.org> wrote:On Wed, Mar 13, 2019 at 10:40 AM Anne van Kesteren <ann...@annevk.nl> wrote:On Wed, Mar 13, 2019 at 10:23 AM Yoav Weiss <yo...@yoav.ws> wrote:
> It makes it harder to keep track of the feature's evolution and have reasonable source control for it once it lands, as PRs typically tend to get squashed.
I'm not sure I understand this.
> It makes it hard for reviewers to understand where a feature currently stands
Which reviewers? As far as standards are concerned, it's very similar
to v0 Web Components I'd say.
> One example of that: I'm currently working on Client Hints, did a bunch of work of unifying multiple PRs from multiple people into a single Fetch PR, and I'm still getting complaints that the state of the feature is currently not clear, as reviewers need to look at a couple of PRs (on Fetch and HTML) to understand the situation. Now I have a task on my plate to create a separate document that will monkey patch those specifications, to make it clearer for folks where things are and where the feature is going.
Yeah, the Client Hints situation hasn't been great. It was somehow
"done" without end-to-end integration.
> Also, let's talk about the elephant in the room while we're at it. With Edge/Chromium, is the assumption that it will no longer count as a separate implementation?
I think the elephant in the room is that Chrome is moving ahead with
things despite not having buy-in from others, reminiscent of the
Netscape days. Seems rather clear that Microsoft using the same engine
as Google would not count as a distinct implementation.I wasn't around to see the shipping process in the Netscape days, but the bar for shipping new features in Blink is quite high in terms of work required. In order to make it as easy as possible for other vendors to implement and ship, we ask for a spec and test suite that matches the implementation. By contrast, lots of stuff shipped in the Netscape/IE is called DOM appeared to have unspec'd and untested, leaving that for decades later.We rely on the code review process for spec and test quality, just like for the implementation. I'm sure you'd be able to find exceptions, but when I've taken a deep dive on an intent both spec and tests tend to be there by the time the intent has 3xLGTM.After kind off-list feedback I want to walk this back a bit. While it's not possible to get test or implementation changes merged without review, there's no such requirement in place for getting things published at w3c.github.io
or wicg.github.io URLs.
I don't have any stats, but it would be possible to just push to master and self-review PRs all the way. You can also get yourself a whatpr.org URL without anyone actually having reviewed it.This is something that +Domenic Denicola, +Johnny Stenback and I have been discussing a bit lately. At a technical level what would be required is branch protection with required review for all spec repos, and maybe a review step for moving repos into certain GitHub orgs.
On Thu, Mar 14, 2019 at 11:29 AM Philip Jägenstedt <foo...@chromium.org> wrote:On Wed, Mar 13, 2019 at 12:26 PM Philip Jägenstedt <foo...@chromium.org> wrote:On Wed, Mar 13, 2019 at 10:40 AM Anne van Kesteren <ann...@annevk.nl> wrote:On Wed, Mar 13, 2019 at 10:23 AM Yoav Weiss <yo...@yoav.ws> wrote:
> It makes it harder to keep track of the feature's evolution and have reasonable source control for it once it lands, as PRs typically tend to get squashed.
I'm not sure I understand this.
> It makes it hard for reviewers to understand where a feature currently stands
Which reviewers? As far as standards are concerned, it's very similar
to v0 Web Components I'd say.
> One example of that: I'm currently working on Client Hints, did a bunch of work of unifying multiple PRs from multiple people into a single Fetch PR, and I'm still getting complaints that the state of the feature is currently not clear, as reviewers need to look at a couple of PRs (on Fetch and HTML) to understand the situation. Now I have a task on my plate to create a separate document that will monkey patch those specifications, to make it clearer for folks where things are and where the feature is going.
Yeah, the Client Hints situation hasn't been great. It was somehow
"done" without end-to-end integration.
> Also, let's talk about the elephant in the room while we're at it. With Edge/Chromium, is the assumption that it will no longer count as a separate implementation?
I think the elephant in the room is that Chrome is moving ahead with
things despite not having buy-in from others, reminiscent of the
Netscape days. Seems rather clear that Microsoft using the same engine
as Google would not count as a distinct implementation.I wasn't around to see the shipping process in the Netscape days, but the bar for shipping new features in Blink is quite high in terms of work required. In order to make it as easy as possible for other vendors to implement and ship, we ask for a spec and test suite that matches the implementation. By contrast, lots of stuff shipped in the Netscape/IE is called DOM appeared to have unspec'd and untested, leaving that for decades later.We rely on the code review process for spec and test quality, just like for the implementation. I'm sure you'd be able to find exceptions, but when I've taken a deep dive on an intent both spec and tests tend to be there by the time the intent has 3xLGTM.After kind off-list feedback I want to walk this back a bit. While it's not possible to get test or implementation changes merged without review, there's no such requirement in place for getting things published at w3c.github.ioThat depends on the WG, ATM. Maybe the W3C can impose that as a general rule for all WGs?
or wicg.github.io URLs.I think we can impose PR review as a rule in the CG, by fellow editors.OTOH, at least at the moment, having a document live on the WICG org does not automatically give it extra authoritativeness, other than indicate that there was some industry interest in resolving that problem.Are we interested in changing that?+Marcos Caceres +Chris Wilson for their opinions.
I don't have any stats, but it would be possible to just push to master and self-review PRs all the way. You can also get yourself a whatpr.org URL without anyone actually having reviewed it.This is something that +Domenic Denicola, +Johnny Stenback and I have been discussing a bit lately. At a technical level what would be required is branch protection with required review for all spec repos, and maybe a review step for moving repos into certain GitHub orgs.Yeah, if we enforce reviews as part of the WICG GH org, we'd need a review step when importing incubated work from external repos. It's not clear who will conduct those reviews though.
I think it could be a good idea to require review at a technical level, but I'd certainly want to survey the people who have pushed commits to WICG repos over the last year to see if that would have unexpected downsides. Yoav, are you interested in exploring this?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78g1Qdh%3Da7ZoyBKrRQQehz_jT2J7SdFy1icK%3DkquSFv0aA%40mail.gmail.com.
In WebApps WG, I'm trying to enforce this via this template:
https://github.com/w3c/screen-orientation/blob/gh-pages/.github/PULL_REQUEST_TEMPLATE.md
Core is:
```
The following tasks have been completed:
• Modified Web platform tests (link to pull request)
Implementation commitment:
• WebKit (https://bugs.webkit.org/show_bug.cgi?id=)
• Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=)
• Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=)
```
We should do the same for all WICG repositories.
At the other extreme of the spectrum: we ditch the idea of doing specs at the WICG, and only do explainers and prototypes: If the explainer/prototype excites people, then we can get more serious about doing a real specs with a proper QA and review process in the W3C or WHATWG.
Just throwing that out there as a straw-person.