Evaluate using 'stale-while-revalidate' HTTP cache control
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Krinkle
	Apr 12 2016, 3:33 AM

Description

Blog post with background information at https://www.mnot.net/blog/2014/06/01/chrome_and_stale-while-revalidate.

I noticed that the Google Font API uses this header. (e.g. https://fonts.googleapis.com/css?family=Open+Sans:400,300,700 on https://performance.wikimedia.org/)

cache-control: private, max-age=86400, stale-while-revalidate=604800

As of writing, no browsers have implemented this yet (Chrome was experimenting, but no milestone yet. Firefox has a tracking bug but no signals yet.) But, various web proxies and CDNs do support stale-while-revalidate.

This would give us an immediate improvement in cache-miss latency for ResourceLoader. And, once browsers implement it, it would also take away the latency of common requests throughout a session such as the startup module - which is referenced in all pages, but expires every 5 minutes.

ResourceLoader design doc: https://www.mediawiki.org/wiki/ResourceLoader/Features#Startup_Module

Browsers:

Chrome platform status: https://www.chromestatus.com/feature/5050913014153216
Chrome launch bug: https://bugs.chromium.org/p/chromium/issues/detail?id=348877
Firefox launch bug: https://bugzilla.mozilla.org/show_bug.cgi?id=995651

Proxies:

Fastly CDN https://www.fastly.com/blog/stale-while-revalidate-stale-if-error-available-today
Varnish 4.1.0 (https://github.com/varnishcache/varnish-cache/commit/bab12263b1) - as default value of obj.grace.
Squid 2.7
Nginx 1.11.10 https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_use_stale, https://github.com/nginx/nginx/commit/da2b2cf1e0, https://www.nginx.com/blog/mitigating-thundering-herd-problem-pbs-nginx/

Details

Related Changes in Gerrit:

	Subject	Repo	Branch	Lines +/-
	ResourceLoader: Add 1min grace via stale-while-revalidate Cache-Control	mediawiki/core	REL1_39	+7 -1
	ResourceLoader: Add 1min grace via stale-while-revalidate Cache-Control	mediawiki/core	master	+7 -1

Customize query in gerrit

Related Objects

Mentioned Here: T175087: Create a navtiming processor for Prometheus

Event Timeline

Krinkle created this task.Apr 12 2016, 3:33 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 12 2016, 3:33 AM

Krinkle renamed this task from Evaluate use of 'stale-while-revalidate' HTTP cache control to Evaluate using 'stale-while-revalidate' HTTP cache control.Apr 12 2016, 3:33 AM

Krinkle moved this task from Inbox to Backlog on the MediaWiki-ResourceLoader board.Apr 18 2016, 12:27 AM

ori triaged this task as Medium priority.Apr 18 2016, 6:45 PM

ori moved this task from Inbox, needs triage to Backlog: Maintenance, non-prioritized on the Performance-Team board.

(From Team Offsite)

This might be interesting for thumbnails as well. About 1/30 thumbnail fetches results in a 304 - which blocks rendering of those images. stale-while-revalidate would make this asynchronous, a lot like the offline-first fetch as used in Service Worker code.

Krinkle moved this task from Backlog: Maintenance, non-prioritized to To-do: Goals prioritized current Quarter on the Performance-Team board.Dec 6 2016, 12:13 AM

• Gilles assigned this task to Krinkle.Dec 7 2016, 5:27 PM

Krinkle moved this task from To-do: Goals prioritized current Quarter to Doing (old) on the Performance-Team board.Mar 8 2017, 1:47 AM

Krinkle moved this task from Backlog to Assigned on the MediaWiki-ResourceLoader board.

Krinkle updated the task description. (Show Details)Mar 8 2017, 2:02 AM

Krinkle updated the task description. (Show Details)Mar 8 2017, 2:16 AM

Krinkle updated the task description. (Show Details)Mar 8 2017, 2:33 AM

Krinkle updated the task description. (Show Details)Mar 8 2017, 2:35 AM

Change 341733 had a related patch set uploaded (by Krinkle):
[mediawiki/core] resourceloader: Add 1 minute stale-while-revalidate (Cache-control)

https://gerrit.wikimedia.org/r/341733

gerritbot added a project: Patch-For-Review.Mar 8 2017, 2:38 AM

Krinkle updated the task description. (Show Details)Mar 8 2017, 2:44 AM

Peter subscribed.Mar 8 2017, 9:50 AM

Krinkle updated the task description. (Show Details)Mar 13 2017, 2:46 AM

Krinkle updated the task description. (Show Details)Mar 22 2017, 4:03 AM

Paladox subscribed.Mar 31 2017, 8:34 PM

Change 341733 abandoned by Krinkle:
resourceloader: Add 1 minute stale-while-revalidate (Cache-control)

Reason:
Per Task.

https://gerrit.wikimedia.org/r/341733

Haven't had an opportunity to figure out why this breaks in Varnish, but either way that would make it unsuitable for including in MediaWiki by default if something major as Varnish won't work with it by default without some workaround or VCL change.

In addition, I'm not comfortable shipping this in ResourceLoader when no browser has implemented support for it yet. It would mean that it gets silently adopted once they do implement it, which may not be bug-free. Last time we did that (with requestIdleCallback) we ran into major problems and had to back it out unexpected because Chrome started to enable the feature in a Chrome stable release but the feature didn't actually work properly.

Once at least one browser implements this we can revisit it and then we can also figure out what's wrong in how it interacts with Varnish.

Chrome is shipping this as of Chrome 75. Time to reconsider!

https://twitter.com/dtapuska/status/1174784809148829705
https://twitter.com/addyosmani/status/1107182279032340481
https://www.chromestatus.com/feature/5050913014153216

Krinkle removed a project: Patch-For-Review.Sep 19 2019, 10:25 PM

Krinkle moved this task from Assigned to Backlog on the MediaWiki-ResourceLoader board.

Krinkle moved this task from Doing (old) to To-do: Goals, prioritized next 4 Quarters on the Performance-Team board.

Krinkle removed Krinkle as the assignee of this task.Sep 20 2019, 7:11 PM

Krinkle moved this task from Backlog to Accepted Enhancement on the MediaWiki-ResourceLoader board.Sep 29 2019, 6:47 PM

ori subscribed.Sep 2 2022, 6:59 PM

In T132418#5508073, @Krinkle wrote:

Chrome is shipping this as of Chrome 75. Time to reconsider!

Firefox too, as of Firefox 68 (2019)
https://bugzilla.mozilla.org/show_bug.cgi?id=1536511

Krinkle moved this task from To-do: Goals, prioritized next 4 Quarters to Backlog: Maintenance, non-prioritized on the Performance-Team board.Oct 4 2022, 7:02 PM

Change 341733 restored by Krinkle:

[mediawiki/core@master] resourceloader: Add 1 minute stale-while-revalidate (Cache-control)

https://gerrit.wikimedia.org/r/341733

gerritbot added a project: Patch-For-Review.Oct 27 2022, 10:38 PM

In T132418#8351473, @gerritbot wrote:

Change 341733 restored by Krinkle:

[mediawiki/core@master] resourceloader: Add 1 minute stale-while-revalidate (Cache-control)

https://gerrit.wikimedia.org/r/341733

I cherry-picked this to the Beta Cluster and confirmed that after waiting for the existing cache to roll-over, the directive makes it way through the traffic layers (ATS, Varnish) and out to the browser. This is important since we have a number of transformations in VCL/ATS that modify Cache-Control response headers.

Observed in Firefox when browsing random page views:

GET https://en.wikipedia.beta.wmflabs.org/w/load.php?lang=en&modules=startup&…

HTTP/2 200 OK
server: deployment-mediawiki12.deployment-prep.eqiad1.wikimedia.cloud
x-powered-by: PHP/7.4.30
cache-control: public, max-age=300, s-maxage=300, stale-while-revalidate=60
date: Thu, 27 Oct 2022 23:44:34 GMT
expires: Thu, 27 Oct 2022 23:49:34 GMT
age: 0
..
x-cache: deployment-cache-text07 hit, deployment-cache-text07 pass
x-cache-status: hit-local
..

As before, the browser re-uses this offline and unconditionally for 5 minutes with e.g. the network panel in devtools showing "200 OK (cached)" with an effective 0 ms roundtrip attributed to the non-request.

After this period, the next page view despite taking place after the expiry shows the same "200 OK (cached)" response with the same past-date response header showing, but alongside it a second request that goes to the server for a fresh roundtrip that receices a HTTP-304 response to renew the cached response for another 5 minutes — this renewal roundtrip would normally block page rendering but is now async.

Also important of note is that this background request has HTTP/2 bandwidth priority of Lowest which should reduce chances of it affecting the speed of other late resources such as async/lazy JS and below the fold images.

capture-200-cached.png (894×2 px, 181 KB)

capture-304-roundtrip.png (822×2 px, 167 KB)

Krinkle claimed this task.Oct 28 2022, 1:11 AM

Change 341733 merged by jenkins-bot:

[mediawiki/core@master] ResourceLoader: Add 1min grace via stale-while-revalidate Cache-Control

https://gerrit.wikimedia.org/r/341733

ReleaseTaggerBot added a project: MW-1.40-notes (1.40.0-wmf.14; 2022-12-12).Dec 7 2022, 11:01 PM

alistair3149 subscribed.Dec 17 2022, 7:18 PM

I wasn't able to conclusively see any major change (up or down) in domComplete, loadEventEnd, or mediaWikiLoadEnd. I checked the global metrics, mobile/desktop metrics, and the p75/p95 of several major browsers that I know support it (Chrome, Chrome Mobile, Firefox; but not Safari/iOS).

This benefit is limited to the 6th minute of a page view session. In the first minute, the startup manifest is naturally fetched. It doesn't block rendering, but as being a subresource, async or not, it does count towards domComplete/loadEventEnd, and is a delay to interactive code (mediaWikiLoadEnd). The five minutes following that first one, we allow it to be used completely offline. It can't get any better than that during those minutes. In the sixth minute, the new state-while-revalidate the browser to use the cached manifest offline as-is without any server roundtrip, just like the previous minutes. From the seventh minute on-wards, both max-age and SWR are expired, and so the browser has to do a light 304-Not-Modified roundtrip that transfers 0 response body bytes but is a roundtrip nonetheless.

I decided to check the session length dataset (docs) using hive (wmf)> SELECT * FROM wmf.session_length_daily WHERE year=2022 AND month=12 AND day=17 AND wiki="en.wikipedia" ORDER BY session_length LIMIT 10;. For 17 December 2022, on en.wikipedia.org, the first ten minutes break down as follows:

en.wikipedia	0	100%
en.wikipedia	1	26%
en.wikipedia	2	14%
en.wikipedia	3	9%
en.wikipedia	4	6%
en.wikipedia	5	5%
en.wikipedia	6	4% <!-- should benefit from stale-while-revalidate
en.wikipedia	7	3%
en.wikipedia	8	3%
en.wikipedia	9	3%

As such, it would not be surprising if the p95 doesn't reflect those 4% of browsing sessions. It might of course, since there's potential for some of the navtiming fragments (e.g. Chrome browser, Firefox browser, Minerva skin) to perhaps be more represented, or have more page views within the same time duration etc. But it's certainly close enough that it may also very well be lost in the noise.

Tooting the usual horn, I believe with navtiming on prometheus the higher percentiles like p99 would actually become meaningful as we could apply them to larger time periods like a day or a week instead of a single minute only, and thus carry enough signal to help us notice these differences. Ref T175087: Create a navtiming processor for Prometheus. I'll close this as resolved and working in intended based on my lab test at T132418#8351613, and as not having caused a regression in RUM data.

Change #1037907 had a related patch set uploaded (by Alistair3149; author: Krinkle):

[mediawiki/core@REL1_39] ResourceLoader: Add 1min grace via stale-while-revalidate Cache-Control

https://gerrit.wikimedia.org/r/1037907

Restricted Application added a project: MediaWiki-Platform-Team. · View Herald TranscriptJun 1 2024, 9:33 PM

Change #1037907 merged by jenkins-bot:

[mediawiki/core@REL1_39] ResourceLoader: Add 1min grace via stale-while-revalidate Cache-Control

https://gerrit.wikimedia.org/r/1037907

ReleaseTaggerBot added a project: MW-1.39-notes.Jun 10 2024, 2:00 PM

Evaluate using 'stale-while-revalidate' HTTP cache controlClosed, ResolvedPublicActions

Description

Details

Related Objects

Event Timeline

Evaluate using 'stale-while-revalidate' HTTP cache control
Closed, ResolvedPublic
Actions