[00:09:02] TimStarling: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/851776/1 ; not quite as easy, but still removing lots of stuff [00:09:28] I just did that one. [00:14:05] AaronSchulz: modified comment, LGTY? [00:14:09] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/825410 [00:14:45] can https://phabricator.wikimedia.org/T320761 be resolved, or is there more you'd like to do within that task? [00:14:58] Krinkle: yep, +1ed [00:15:17] closed [01:21:20] AaronSchulz: merge conflicts.. https://gerrit.wikimedia.org/r/c/mediawiki/core/+/838872/ [03:17:42] Krinkle: amended [12:58:24] TimStarling: I've been trying to get https://github.com/php/doc-en/pull/435 landed for almost 2 years now :) [16:55:40] https://simonhearne.com/2020/network-faster-than-cache/ <- some interesting findings here. one more reason why the RL approach to loading assets is still quite competitive even in an HTTP/2 world [17:01:39] Yeah, I imagine it'd be non trivial during the critical path to hammer the disk with a ton of small requests cache hits. [17:02:10] Although with SSD and high concurrency cpu.. it is surprising at least. Depends a lot on how it's implemented I suppose. [17:02:34] But yeah we basically read it from JS memory. [17:16:48] yep, and with the smart client-side logic there are less requests even in case of an LS miss [17:17:20] I'm kind of surprised that most of the go-to advice on web caching appears to be "embed URLs to immutable versioned assets into your HTML" [17:17:38] which then either precludes caching the HTML itself or requires the use of a persistent storage backend for assets... [17:19:23] Yeah.. while not daily, it does happen regularly that I'm on some company's website trying to get something done, and it falls down because one of the lazy loaded webpack bundles is 404-ing. Presumably something from a previous deploy that was still in some html caches but the assets no longer were [17:21:15] this is why we use query parameters (for best-effort recovery to latest), and on top of that validate the query parameters server-side to avoid poisoning under races (e.g. server A sends html with ref to file.js?v2 which browser loads from server B where file.js is v1). so even seemingly clean /w/resources/foo.svg will go through /w/static.php to give those a 1min cache to let the CDN recover. [17:22:02] I'll also say that just in general anything JS is always best-effort. Nothing beats a solid Base layer underneath the optional JS pipeline. [17:22:15] I imagine 99% of readers won't even notice if our JS fails or is missing for any reason. [17:32:38] Pretty muchh [17:37:30] > Race Cache With Network (RCWN) is enabled on Android when cellular data isn't used. – https://wiki.mozilla.org/Firefox/Roadmap/Updates [17:37:32] That's nice of them [17:37:50] I had no awareness of RCWN. Its' been in Firefox for 3y [17:45:15] I take no credit here, but it is interesting that the two take-ways in 2020 there are exactly what we do. 1) batch when possible, and 2) avoid likely-cache hits concurrently with likely-miss requests as we basically only make miss/network reqs and the rest goes to LS. [17:45:39] thx for sharing :) [18:13:50] yeah, it generally seems that there were lots of quick conclusions drawn by folks after H2 came out & in hindsight some of those seem rushed [18:14:44] new isn't always better!?!!? [18:33:38] phedenskog: which channel do those 'ERROR' alerts go? [18:34:06] Krinkle: I'll invite you. [18:36:50] thx [18:37:18] There's some documentation missing for how that works, but I'm waiting to see that it really works 100% first. [21:54:45] Krinkle: anything else on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/838872? [21:57:26] nope, landing [22:10:43] AaronSchulz: could use CR on these little ones https://gerrit.wikimedia.org/r/c/mediawiki/core/+/842943 and https://gerrit.wikimedia.org/r/c/mediawiki/core/+/849185 [22:32:09] done