Page MenuHomePhabricator

ResourceLoader 2018 Review
Closed, ResolvedPublic

Description

This task tracks actionables that came out of the ResourceLoader 2018 Review between @Catrope and myself.

Objective

Improve "time to interactive" and mediaWikiLoadEnd metric, by reducing the number of serial requests from 3 to 2.

Current state

(Sizes based on measures from en.wikipedia.org, desktop.)

Req 1: Startup module

Current size: 29 KB (network transfer) - 85 KB (uncompressed).

  • Defines mwNow, mwPerformance, isCompatible.
  • Fetches "Base modules request" (Req 2).
  • Once completed:
    • Registers sources, modules, and site config.
    • Process RLQ, which will initiate fetch for "Page modules request" (Req 3).
Req 2: Base modules

Current size: 49 KB (network transfer) - 178 KB (uncompressed).

  • "jquery" (41 KB).
  • "mediawiki" (8 KB).
  • "wikibits" (0.4 KB).

Problem

The startup module should be able to, on its own, start to handle mw.loader.load() calls from the page HTML, instead of having to make a second request first and waiting for that to come back.

Plan

In a nut shell:
  1. Make the "mediawiki.loader" client simple and small enough to simply include in the "startup" module.
  2. Load "jquery" and "wikibits" as a default-dependency implied for all regular modules.

The mediawiki.loader is already quite simple in terms of JavaScript logic. This is good because that means it won't be a problem to be compatible with the restrictions put on code in the startup module, namely that its syntax has to parse without errors in older browsers. Older browsers will never execute it, so usage of ES5 or ES6 methods is fine at run-time, but syntax-wise an older browser needs to be able to download and parse it, after which it essentially runs !isCompatible() and then returns gracefully.

The other requirement is for "mediawiki.loader" to not depend on jQuery. This is mostly done already, but there's a couple of call sites left that we have to migrate.

Once done, "jquery" can become a regular module that is loaded as dependency (in Req 3), thus eliminating Req 2.

For regular modules to be able to continue to assume jQuery, we need to re-introduce a concept of "default dependencies". And we should do it differently than what we did back in 2015 ("Default modules: mediawiki.user, mediawiki.util"), which (in retrospect) was implemented rather poorly (with a separate web request, using the synchronous top-queue).

High-level steps:

  1. Refactor mediawiki.js to not require jQuery. (Sub tasks below)
  2. Split off the "mediawiki.base" module from "mediawiki".
  3. Remove "mediawiki" module from the base module's request, and instead embed it directly the startup module response.
  4. Implement "default dependencies" concept.
  5. In Startup module, remove "Base modules request", instead listing those modules as "default dependencies". Then, in startup.js simply call startUp(); directly at the end of the closure.

Sub tasks for "Refactor mediawiki.js to not require jQuery"

startup.js:

wikibits.js:

mediawiki.js (to become "mediawiki.loader"):

  • mediawiki.errorLogger.js: Fine as-is (small, dependency-free, es3-compat).
  • mediawiki.requestIdleCallback.js: Fine as-is (small, dependency-free, es3-compat).
  • mw.Map: Keep (used for mw.config). But remove use of isPlainObject(). Decide to either use all own keys regardless of type, or just all keys plainly.
  • Message class: Not used by loader, and depends on mediawiki.html and mw.format Move to base.
  • mw.message: Not used by loader, move to base.
  • mw.msg: Not used by loader, move to base.
  • mw.messages: Keep (mw.Map-based registry for loaded messages).
  • mw.log: Keep (used by loader).
  • mw.format: Move to base. Has one call in loader, but trivial to avoid.
  • mediawiki.track: Move to base. (Depends heavily on special features of $.Callbacks) Maybe leave a stub in mw.loader for track(), given it's used for error reporting.
  • mw.loader:
    • addEmbeddedCSS: Fix to use plain array instead of $.Callback.
    • getMarker: We can remove this in favour of simply append to head if absent. – https://gerrit.wikimedia.org/r/429124
    • register: Remove or deprecate "dependencies as a function" feature. – https://gerrit.wikimedia.org/r/428406
    • addScript: Replace $.ajax with plain script.onload/onerror and callback. Promise only used in one place, with ".always()".
    • queueModuleScript: Replace overkill $.Deferred with simple callback parameter.
    • addLink: Use plain append/insert instead of jQuery.
    • checkCssHandles: Find a way to change mw.loader.using( ['site'] ) to a job so that it we won't need using() and $.Deferred.
    • doRequest: Inline simple version of $.param().
    • asyncEval: Uses $.globalEval() (easy to replace for our current browsers, per jQuery 3).
    • execute: Idem, uses $.globalEval().
    • execute: Fix $ reference to be window.$ to avoid ref-error when RL loads jQuery itself.
    • using: Depends on $.Deferred(), not used in loader, move to base. – (Blocked on: Internal callers)
  • mw.inspect(): Not used by loader. Move to base.
  • mw.html: Not used by loader, move to base.
  • mw.hook: Not needed, move to base.
  • $j alias: Not needed, move to base.
  • mwLoadEnd: Depends heavily on mw.loader.using(), and jQuery for when(), Deferred(), and more... Not needed here though, can be moved to the navtiming extension. – https://gerrit.wikimedia.org/r/#/c/434618/

Other stuff:

  • Simplify mediawiki.log.js

Startup response size breakdown

Moved to T202154

Details

SubjectRepoBranchLines +/-
mediawiki/coremaster+16 -2
mediawiki/corewmf/1.32.0-wmf.18+1 -1
mediawiki/coremaster+1 -1
mediawiki/coremaster+160 -116
mediawiki/coremaster+22 -4
mediawiki/coremaster+6 -9
mediawiki/coremaster+27 -24
mediawiki/coremaster+37 -18
mediawiki/extensions/CodeReviewmaster+4 -7
mediawiki/coremaster+27 -35
mediawiki/coremaster+10 -21
mediawiki/coremaster+60 -90
mediawiki/coremaster+86 -70
mediawiki/coremaster+59 -54
mediawiki/coremaster+127 -93
mediawiki/coremaster+11 -5
mediawiki/coremaster+4 -4
mediawiki/coremaster+35 -11
mediawiki/coremaster+1 -1
mediawiki/coremaster+227 -226
mediawiki/coremaster+154 -110
mediawiki/coremaster+256 -253
mediawiki/coremaster+13 -2
mediawiki/extensions/NavigationTimingmaster+61 -1
mediawiki/coremaster+1 -349
mediawiki/coremaster+0 -36
mediawiki/coremaster+4 -5
mediawiki/coremaster+1 -6
mediawiki/coremaster+43 -50
mediawiki/extensions/UploadWizardmaster+55 -413
mediawiki/coremaster+4 -5
mediawiki/coremaster+18 -33
mediawiki/coremaster+13 -2
mediawiki/coremaster+24 -13
mediawiki/coremaster+23 -46
mediawiki/coremaster+19 -68
mediawiki/coremaster+13 -15
mediawiki/coremaster+9 -5
mediawiki/coremaster+5 -9
mediawiki/coremaster+5 -13
mediawiki/coremaster+19 -26
mediawiki/coremaster+8 -5
mediawiki/coremaster+8 -10
mediawiki/coremaster+0 -12
Show related patches Customize query in gerrit

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Thanks :)

I just found it was cumbersome to manage different versions of scripts, depending on MediaWiki version, swimming on short intervals like 6 months.
Moving to forward-compatbility implying to break backward-compatibility even for recent and supported MediaWiki versions.

(TBH, I'm quite tired of the incessant and short-notice javascript deprecations. Case in point, wikis are full of broken scripts, even amongst the most used ones, only because of the deprecations...)

(TBH, I'm quite tired of the incessant and short-notice javascript deprecations. Case in point, wikis are full of broken scripts, even amongst the most used ones, only because of the deprecations...)

Can you please provide one or two examples of short-notice deprecations and how which wiki was full of broken scripts due to this? I can count on one hand, the number of deprecations and removals we have performed in JavaScript in 10 years. They are far from short-notice.

Change 441586 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] mediawiki.hook: Move mw.hook tests to new mediawiki.base.test.js file

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

Not strictly deprecation/removal, but off the very top of my head:

  • Requiring to add the mediawiki.util dependency. This made many scripts significantly more cumbersome, not to mention the insane amount of work to update the scripts. As more, this module is nevertheless always loaded at some point in practice, and it is quite short (also, you could compare this with the removal of the "mediawiki.api.*" submodules, where "a small size increase is acceptable in order to simplify").
  • Implementing jQuery UI, then deprecating it and switching to that "OOUI-JS" thing. Not to mention I hate it (complicated code, lacks flexibility, very slow), some scripts still use jQuery UI and don't switch that OO-JSUI because the code is complicated and often doesn't let do some required things.
  • Many markup changes introduced by that OO-UIJS, that broke many scripts.
  • A lot of ranting because of that OOuiJS (just a few examples: 144171441, 144171817, 144172971)
  • Another one: 141529955 (in edit summary: "class has been removed. script already broken three months after. f***.")
  • Bonus: giving the precious $ global name to jQuery. jQuery is slowly dying, and the day it will be to be removed, we're fucked. Already as of now, all documentation should make use the jQuery global name, using an IIEE to get the $ name.

TL;DR: Off the top of my head: explicit mediawiki.util dependency, everything involving OOUIjs (mainly the markup changes). I miss probably some, I just can't think of them right now.

This long message is going slightly off-topic, and I don't really have time to further discuss about it. Just consider it as some feedback, which I hope might be useful in some way.

I'll just also mention toolbar customization, which has been modified several times, and has become a real pain for users.

See this past discussion, and the addCustomButton function I had to add in the Common.js so that it becomes back sanely usable.

@Od1n Thanks for taking the time to document these points. I understand your frustration. Having said that, I will provide some details behind these changes that I think are important.

Gadgets provide (virally elected) users the ability to develop and deploy software with no requirements, no technical limitations, and no review from professional developers. This is a big risk in terms of performance, security, privacy and usability. Yet, we grant users this power. But power comes with responsibility. And developing software, regardless of whether as a hobby or professional, comes with the responsibility to maintain it. Volunteer and staff developers that contribute to MediaWiki software, perform maintenance. This ensures our wikis remain secure, user-friendly, compatible with constantly changing browsers and devices, and (hopefully) fast for everyone.

Sometimes this maintenance must change code in a way that is not backward compatible, due to mutually exclusive requirements. When requirements are not mutually exclusive, we follow a deprecation phase in one of two ways:

  • Build a new bridge that allows references to the old code to keep working by automatically mapping to newer code.
  • Or; by keeping a copy of the old code unchanged.

However, sometimes the requirements are mutually exclusive in a way that the old code cannot work anymore. When this happens, the deprecation happens before adding the new code, instead of after adding the new code. We do this by building a new bridge to the old code in a way that is prepared for the new requirement. Then code is updated to this new bridge, and once we can remove the old, we can add the new code and point the bridge to that. This means during the transitional period code must find a common ground that requires neither the old nor the new behaviour specifically.

All of this costs time, money, and (sometimes) affects site performance for all other users. This is considered worth it, because it is important to have a transitional period to allow existing code to be migrated. This applies to both core and extensions (maintained by MediaWiki volunteer and staff developers) as well as to gadgets and user scripts (maintained on-wiki).

However, these bridges cannot be maintained forever. Doing so would cause the performance to get worse every time, would cause to cost increasingly more time and money, which is not sustainable. Even if it were sustainable, it would be insecure, because old code often relies on old libraries from other organisations which will not find or fix security flaws in their older versions and web pages would need to load multiple versions of logically equivalent code, which makes performance even worse.

With that, I'll respond to three of your examples.

  1. Requiring to add the mediawiki.util dependency made many scripts significantly more cumbersome, not to mention the insane amount of work to update the scripts. [..] this module is nevertheless always loaded at some point in practice, and it is quite short.

It was never supported for users to write code using mw.util without a dependency added. Using modules without depending on them was never announced or allowed in documentation. Writing code in this way is a mistake. Fortunately, fixing it needs only one line of code to change.

Despite this mistake, such code worked by accident due to a race condition whereby your code coincidentally runs after unrelated other code that in turn did specify a dependency. This means broken code "works" as long as at least one other gadget that needs the same module, is not broken and also happens to load before yours loads.

In other words, your module without a dependency was working because someone else's module did have the dependency.

This is true for all modules, but you are right that mediawiki.util is very commonly used. This is why, despite it not being supported by the documentation, people that tried this did not always get an error. But... as expected, it did not work always, and sometimes it did cause an error.

We never added a requirement to add it. In fact, we did the opposite. Following reports at T35746 in 2012 from some people getting an error, I added a special feature for "mediawiki.util" called $wgPreloadJavaScriptMwUtil which, when turned on, will load it always, before anything else. This comes at a performance cost, because it delays everything on the page, including parts that do not need it. It also makes tampers with automated load order and prevented us from making other improvements, which had to wait for many years.

After three years, $wgPreloadJavaScriptMwUtil was removed in 2015. But, alas, mediawiki.util was still loading by default for gadgets because we also have the feature "$wgIncludeLegacyJavaScript" for wikibits.js, which was still turned on, and wikibits depended on mediawiki.util. The legacy wikibits.js migration that started in 2011 and was still not completed after four years in 2015.

Before I continue, let me address the second part of your point:

  1. [..] this module is [..] quite short.

The mediawiki.util.js file is 5.5 KB (minified). One such thing is fine, but many of them add up. Also, the cost of mediawiki.util is more than this one file.

For four years (2012 – 2016) mediawiki.util was manually loaded by default specifically to help gadgets. During these years, we reached out via Wikitech-l, Wikitech-ambassadors, Tech-News, and console deprecations. In addition to reaching out via these ways to users that maintain gadgets, @Krenair, @matmarex, @Legoktm and myself also spent hundreds of volunteer hours ourselves to look on all 900 wikis and proactively help address this migration in most gadgets that needed it.

In 2016, I decided to allow wikibits to continue for one more year. But optimise it so that it does not need mediawiki.util. This improved performance significantly because it allowed us to remove one layer of indirection. This was a relative improvement, but really just restored how things were in 2012.

I hope that later this year (in 2018), we will finally be able to remove one more layer of indirection (current task is about that), which would make number of network steps finally better than before 2012.

  1. Implementing jQuery UI, then deprecating it. [..] complicated OOUI code, lacks flexibility, very slow [..]

jQuery UI was first introduced to MediaWiki in 2009, with provision through ResourceLoader in 2011. In 2014 (four years later) we upgraded from jQuery UI 1.8 to jQuery UI 1.9, which included a compatibility layer for jQuery UI 1.8 (T49076).

Several gadget authors in the community, staff engineers, and other developers have asked for an upgrade to jQuery UI 1.10, or jQuery UI 1.11. However, we have not done so despite the bugs that exist in jQuery UI 1.9, and despite the improvements the newer versions have. This, because it means ending the compatibility with jQuery UI 1.8. (Each jQuery UI version has compatibility for the previous version.)

In August 2016, after actively using jQuery UI for seven years, we marked it as deprecated in favour of OOUI. Today, two years since the deprecation started, jQuery UI 1.8 code still works in production. We have still not removed it. You shouldn't, but if you don't have time yet or still have not found an adequate replacement, it can continue to work with jQuery UI at this time.

If you have specific issues with OOUI, please create a task with a specific need and expectation under OOUI so that the team looking after it can help you.

jQuery UI 1.9 is now so old, the jQuery Team no longer supports our version. This means for the past four years, I have had the additional responsibility (distracting me from other duties) to manually customise our old version of jQuery UI to be compatible with current browsers and current jQuery core 3.0 version.

  1. giving the precious $ global name to jQuery. jQuery is slowly dying, and the day it will be to be removed, we're fucked. Already as of now, all documentation should make use the jQuery global name, using an IIEE to get the $ name.

This is incorrect.

jQuery's official alias is $ and is part of jQuery. This is not something we gave it. In either case, we support the alias, and neither name is deprecated. Both are 100% supported, current and stable.

There is no need for an IIFE for that. As long as jQuery exists on a Wikimedia page, $ will exist and point to jQuery. If for some bizarre reason we find a really good reason to change $ to something else, there will be deprecation warnings, announcements, and many years of transition before anything changes. This is not a concern.

Also, jQuery is not dying. Slow, or otherwise.

I'll just also mention toolbar customization, which has been modified several times, and has become a real pain for users.

See this past discussion, and the addCustomButton function I had to add in the Common.js so that it becomes back sanely usable.

The Classic toolbar API was modified two or three times over the course of a decade. That is very low frequency for software, even for Wikipedia where things usually change slowly.

The supported interface actually only changed once (from mwCustomEditButtons to mw.toolbar, with a three-year deprecation phase). The other two changes you saw were internal, but affected some users that invented their own unofficial ways which then stopped working. If there is no manual explaining how to do something, ask a developer. If you decide to do yourself without documentation for your purpose, then be prepared that it can stop working without announcement or deprecation. (More likely, it changes with an announcement that sounds unrelated.)

If two changes per year is a problem, I recommend thinking about whether you really want to contribute to program code. Also, if something unofficial does stop working, you can still ask and someone will still help (I recommend Phabricator or Wikitech-l mailing list). That is considered a success, not a pain.

Wow, that's quite an impressive reply! Thank you. Pinned.

I do understand the need to move forward and break legacy drags.
Problem is, there are thousands of user scripts, stacked for over a decade. Some time ago, I spend a lot of time and efforts on fixing such scripts, and there is a lot remaining to do. If I had not fixed them, probably no one else would have done it. And as I'm not planning to, and can't, spend more time on it, the rest will probably just stay indefinitely broken...

About the now widespread trend of fast updates, here's some of my PHP development experience: some PHP frameworks are great, but they now require to update the application every 6 f— months. For just one project, it's already annoying, but acceptable. But if you have dozens of projects, constantly updating them is just insane and beyond feasibility. So you have to either let them rot, or change paradigm (e.g. centralize apps, or change framework).

Just my thoughts. Your message above is a much more elaborate and accurate description of the situation.

@Od1n Thanks, I now understand where the frustration comes from, and I think we agree. I've had the same experience with scripts. Probably many of them were not created by you, but they seem broken, and nobody else would fix it?

I believe we (as community members) need to discuss and decide how we want to solve this problem. I think it is okay for global interface editors, sysops, and stewards to maintain common gadgets on many wikis, and to maintain a few local scripts on small number of wikis they actively care for. But I do not think we can maintain all local scripts on all wikis, right? The math is simple. If a wiki wants custom logic, somebody needs to create it, and it needs to be actively looked after by someone.

Perhaps we (community) can organise some way for local communities to help find volunteers that know JavaScript and speak their language.

Change 441217 merged by jenkins-bot:
[mediawiki/core@master] resourceloader: remove internal use of using() in mediawiki.js

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

Change 441218 merged by jenkins-bot:
[mediawiki/core@master] resourceloader: move using() from mediawiki.js to the base module

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

Change 441220 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@master] resourceloader: spin base module code out as a proper module

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

Change 441586 merged by jenkins-bot:
[mediawiki/core@master] mediawiki.hook: Move mw.hook tests to new mediawiki.base.test.js file

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

Change 441220 merged by jenkins-bot:
[mediawiki/core@master] resourceloader: spin base module code out as a proper module

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

Change 440605 merged by Krinkle:
[mediawiki/core@master] resourceloader: Embed 'mediawiki' directly in startup response

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

Change 445462 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] [WIP] resourceloader: Combine base modules and page modules requests

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

Change 445462 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] [WIP] resourceloader: Combine base modules and page modules requests

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

In a meeting with @Catrope we found one blocking issue we need to resolve, with RLQ. The most prominent use of RLQ is MediaWiki OutputPage calling mw.loader.load() with the modules to load on this page. Previously, mw.loader.load() depended on jQuery, and thus RLQ could only be processed after the base modules. With the above commit, RLQ will happen directly after the startup module arrives, and mw.loader.load() works without jQuery.

Consumers of RLQ using it to call mw.config, mw.loader.load(), mw.loader.implement() will continue to work fine

Consumers currently using RLQ to call jQuery, or mw.loader.using() would break. We need to provide an alternate means for that code to do what it wants to do.

Micro audit, based on results from Codesearch for window.RLQ, makeLoaderConditionalScript and makeInlineScript in MediaWiki core and tarball/WMF-deployed extensions:

And from third-party extensions: (TODO: Announce on Wikitech.)

  • [QuizGame] SpecialQuizGameHome.php assumes jquery and mediawiki.base from an inline script.
  • [StlHandler] StlHandler_body.php assumes mediawiki.base to call a function.
  • [UserGroups] SpecialUserGroups.php assumes jquery to run inline UI code after dom-ready.

Change 451072 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] startup: Add support for module-requirement to RLQ

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

Change 451073 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] EditPage: Declare 'mediawiki.toolbar' needed for inline script

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

Change 451074 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/extensions/CodeReview@master] Use makeInlineCodeWithModule() instead of assuming 'mediawiki.base'

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

Change 451082 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] SpecialJavaScriptTest: Use makeInlineCodeWithModule() for 'mediawiki.base'

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

Change 451072 merged by jenkins-bot:
[mediawiki/core@master] startup: Add support for module-requirement to RLQ

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

Change 451199 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] resourceloader: Output state for non-raw modules on only=scripts

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

Change 451199 abandoned by Krinkle:
resourceloader: Output state for non-raw modules on only=scripts

Reason:
Never mind, will have to squash into the I17cd13dffebd6a commit because outputting state() is not allowed. If we do output it, then the mw.loader.register() call registering mediawiki.base throws because it was already registered implicitly by state().

And it kind of makes sense that we cannot change the state of the module before we know it exists.

After we remove the base module request and the concept for raw modules, this code can just be removed instead.

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

Change 451082 abandoned by Krinkle:
SpecialJavaScriptTest: Use makeInlineCodeWithModule() for 'mediawiki.base'

Reason:
To be squashed into I17cd13dffebd6ae476. ("resourceloader: Combine base modules and page modules requests")

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

Change 451073 merged by jenkins-bot:
[mediawiki/core@master] EditPage: Declare 'mediawiki.toolbar' needed for inline script

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

Change 451074 merged by jenkins-bot:
[mediawiki/extensions/CodeReview@master] Use makeInlineCodeWithModule() instead of assuming 'mediawiki.base'

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

Change 445462 merged by jenkins-bot:
[mediawiki/core@master] resourceloader: Combine base modules and page modules requests

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

Change 451536 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] resourceloader: Add to debug mode the same 'jquery' clause as for prod

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

Change 451536 merged by jenkins-bot:
[mediawiki/core@master] resourceloader: Add to debug mode the same 'jquery' clause as for prod

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

Change 451557 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/core@master] RCFilters: Export i18n messages as a config var instead of inline script

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

Change 451557 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Export i18n messages as a config var instead of inline script

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

Leaving open until this weeks' train completes.

Change 455753 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] resourceloader: Don't defer discovery of critical request via rIC()

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

Change 455754 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@wmf/1.32.0-wmf.18] resourceloader: Don't defer discovery of critical request via rIC()

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

Change 455753 merged by jenkins-bot:
[mediawiki/core@master] resourceloader: Don't defer discovery of critical request via rIC()

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

Change 455754 merged by jenkins-bot:
[mediawiki/core@wmf/1.32.0-wmf.18] resourceloader: Don't defer discovery of critical request via rIC()

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

Change 459261 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] resourceloader: Configure eslint to disallow $ and require inside startup

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

Change 459261 merged by jenkins-bot:
[mediawiki/core@master] resourceloader: Configure eslint to disallow $ and require inside startup

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

Timeline of some changes and their deployment date for group2 (en.wikipedia.org etc.):

  1. Thursday, 12 July (branch 32.0-wmf.12)
  2. Thursday, 23 August (branch 32.0-wmf.18)
  3. Friday, 24 August
  4. Tuesday, 28 August
  5. Tuesday 4 September
  6. Thursday, 28 September

The first comparisons below are from comparing the state after point 4 to the week prior. This resembles the final week-over-week change.

Localhost

From the commit message of https://gerrit.wikimedia.org/r/459256
BeforeAfterAvg diff
responseStart1044, 1001, 10161025, 1023, 1024+3ms
domInteractive2080, 2069, 20591872, 2101, 2050-61ms
domComplete4361, 4239, 39273691, 4023, 3981-227ms
loadEventEnd4366, 4244, 39323691, 4023, 3982-282ms
mwLoadEnd4524, 4416, 41133994, 4320, 4297-147ms

WebPageTest: Beta Cluster

The commit was merged at 13 September 23:30 UTC and auto-deployed to Beta Cluster between then and ~45min later (14 Sept 00:15 UTC).

From https://grafana.wikimedia.org/dashboard/db/webpagetest-drilldown?orgId=1&var-wiki=enwiki-beta-mobile&var-users=anonymous&var-page=Barack_Obama&var-location=us-east&var-browser=Chrome-emulateMobile&var-view=firstView&from=1536580269527&to=1536975120597

First visual changeUnchanged (alternating between 2.700s and 2.800s)
Screen Shot 2018-09-15 at 02.37.40.png (690×1 px, 124 KB)
Last visual changeMaybe improved (from 8-8.5s to 7.5-8s)
Screen Shot 2018-09-15 at 02.37.46.png (738×1 px, 136 KB)
Fully loadedMaybe improved (from ~8.7s to ~8.3s)
Screen Shot 2018-09-15 at 02.42.41.png (643×1 px, 97 KB)
DOMCompleteImproved (from 7.5s to 4s)
Screen Shot 2018-09-15 at 02.43.47.png (628×1 px, 94 KB)
CPU spent on scriptingMaybe improved (from ~1.8s to ~1.7s)
Screen Shot 2018-09-15 at 02.46.28.png (803×1 px, 107 KB)
Request count JSUnchanged (8 requests)
Transfer size JSUnchanged (~ 181 KiB)

TODO:

  • Now that the change is in production, also do a week-over-week comparison of production Wikipedia pages.
    • RUM: loadEventEnd, firstPaint, mwLoadEnd.
      • By mobile/desktop, and by various continents/countries.
    • WebPageTest, WebPageReplay: Visual changes, scripting CPU time, and script transfer size.
  • Then also do the same comparisons for the refactor in total for a week or month in June/July before we started, to now.