You should consider prioritizing by pageviews; while it's good to get the set you did as a first cut of interesting sites, dealing with a site like ru.wp is going to have returns greater in absolute magnitude even if they're further down the relative load. See below. (There's an argument for doing some of the smaller languages first, which I anticipate do not have the luxury of 5G networks.)

I also wonder if your numbers include the additional load from Common.css/js/skin.css/js pages? If you were checking safemode before and not after, then they do.

Speaking specifically on Meta, just skimming the defaults

1. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-CentralAuthInterlinkFixer.js 60 lines. Not really certain what links this is "fixing". Maybe anon don't need general access.
2. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-wm-portal-preview.js 120 lines. This one looks like it can be deleted entirely since the portals are now in Git. But at best it should be opt in for all user groups.
3. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-wm-portal.js / .css 500 lines of JavaScript and another 500 of CSS. Same story.
4. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-addMe.js / addMe.css. 600 lines of JS and 130 lines of CSS. This looks used at least annually (CommTech survey). I'm not sure how used it is besides that.
   1. Requires https://meta.wikimedia.org/wiki/MediaWiki:Gadget-relaxed-json.js 600 lines of JS.
5. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-AddTopic.js 20 lines. Seems fine to have by default though I'm not a personal fan. Maybe it's obsolete in Vector22 due to the sticky header new topic button with DiscussionTools and could be restricted to not-that-skin (which means it still loads everywhere else). (I thought there was a specific task in DT for what this one does?)
6. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-formWizard.js / -core.js / .css 1000 lines of JS, 200 lines of CSS. Besides being generally useful, I think the initialization of the core functionality using mw.loader.load could be moved to the formWizard.js page and then this would be much cheaper.

WRC and related

1. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-aaq.js 170 lines JS. Used on a single page and that page gets maybe a couple uses a month. Can this be rewritten to use FormWizard?
2. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-wrcEditor.js / -core.js . 700 lines of JS in -core, which is loaded conditionally. But it looks like it's doing a lot of work that could be fixed below.
3. Uses https://meta.wikimedia.org/wiki/MediaWiki:Gadget-luaparse.js 2300 lines to parse Lua on by default. Used by the various wrc gadgets listed below but I don't think it needs to be on by default if -core is already loaded conditionally, but moreover if https://meta.wikimedia.org/wiki/Module:Wikimedia_Resource_Center/Content and other gadgets that use it was adjusted to be a JSON content page they wouldn't even need luaparse at all??? (i.e., a gadget made before there were JSON content pages.)
4. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-wrcCollapsible.js 50 lines, doesn't work -- headings aren't collapsed (probably since headings got reworked last year), and I'm pretty sure it's strictly not necessary, since one could do something like https://en.wikipedia.org/wiki/Wikipedia:Good_articles/Media_and_drama instead directly in the wikitext.
5. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-wrcAddNewIndividual.js 700 lines JS, again on by default for changing a single page.
6. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-wrcAddNewGroup.js Almost a literal copy paste of NewIndividual except for groups. And I think these both are copy-pastes of wrcEditor-core?

Others that are default on but have some other reasonable restriction for read, so probably don't need any work (80/20 rule, focus on the big hitters for all users at all times):

1. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-CharInsertButtons.css Only loads on edit page. Not a personal fan of this one's existence but at least it's restricted.
2. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-globalSuppress.js Only loads for renamers.
3. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-renameQueueReason.js Same story.
4. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-GlobalRenameQueueCheckAntiSpoof.js Same story.
5. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-GlobalRenameQueueHomewikiHelper.js Same story.
6. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-wadpGadgetsLoader.js loader gadget (does seem to edit Lua when again it could be doing stuff directly in JSON).

Seems fundamentally fine.

1. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-susaresources.js

Not sure why this is a hidden gadget, it's not default... Created in 2017 before the apparent rewrite done last year. Probably could just be deleted?

1. https://meta.wikimedia.org/wiki/MediaWiki:Gadget-addMe-wrapper.js

I think there's some real obvious savings in that wrc direction (which I would guess could be using formWizard instead for a deep change and just not loading luaparse.js by default in the general case), and that relaxed-JSON dependency is sus.

Anyway, a lot of these have "should only load on certain pages" written all over them, which have some stuff of interest T63007 direction.

*In general*, Meta looks like there hasn't been a strong, er, "steward" (some might say gatekeeper) for what gets default and what doesn't. Which is the same as its formerly 17k Common.css page, so I'm not surprised. I'd guess that most of the wikis in that list are in the same boat.

Speaking of Common.css, Common.js is loading quite a chunk of stuff itself. @MarcoAurelio and I talked about some of those on that talk page. 360 lines of JS loading another

1. 300 lines of JS from https://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-LanguageSelect.js
2. 150 lines of JS from https://meta.wikimedia.org/w/index.php?title=MediaWiki:Tabs.js
3. 60 lines of JS from https://commons.wikimedia.org/w/index.php?title=MediaWiki:InterProject.js

The thing with en.wiki is probably that they get most of the stuff done by WMF. For example, many enhancements were made in the new Vector specifically after the mutiny on en.wiki. This is not a reproach; it just partly explains why they have fewer default gadgets. This also might explain why Wikisource usually has more gadgets than Wikipedia. WS has weaker support in general, and more features need to be added by the community.

As an example, I did this thingy when the old Vector was rolling out, which I did to calm the community down:
https://pl.wikipedia.org/w/index.php?title=Specjalna:Strony_wed%C5%82ug_prefiksu&namespace=8&prefix=Gadget-vector4monobookies

Just an insider story ;)

And also what Izno said:

I also wonder if your numbers include the additional load from Common.css/js/skin.css/js pages? If you were checking safemode before and not after, then they do.

On pl.wiki, we moved some old stuff from Common.css/js to gadgets to ensure a more sustainable development of extra features. This included recently moving collapsible tables, which you might remember as it initially threw some errors 🙃. We still have some stuff there though. Additionally, Wikisource has Epub.css, which is specifically designed for e-books. Although this might be out of scope for this task, I thought I should mention it because Epub readers are quite sensitive to heavy CSS.

I have added targets=desktop to some gadgets because I was receiving reports from users and seeing some errors in consoles after this change, and now I have to ask: what to do, for example, about https://ru.wikipedia.org/wiki/MediaWiki:Gadget-collapserefs.js if targets=desktop goes away? Like, I would be perfectly fine with throwing it away entirely, but since I don’t have that power, outside of that: it is a gadget that allows some users to collapse references by default. It doesn’t make sense to have it in mobile Minerva since it collapses all sections, but people can use desktop Minerva and expect this gadget to be there. Unless we’re giving up on the plan to remove targets=desktop, of course, then disregard my comment.

In T340705#8986782, @stjn wrote:

I have added targets=desktop to some gadgets because I was receiving reports from users and seeing some errors in consoles after this change, and now I have to ask: what to do, for example, about https://ru.wikipedia.org/wiki/MediaWiki:Gadget-collapserefs.js if targets=desktop goes away? Like, I would be perfectly fine with throwing it away entirely, but since I don’t have that power, outside of that: it is a gadget that allows some users to collapse references by default. It doesn’t make sense to have it in mobile Minerva since it collapses all sections, but people can use desktop Minerva and expect this gadget to be there. Unless we’re giving up on the plan to remove targets=desktop, of course, then disregard my comment.

@stjn in the case of https://ru.wikipedia.org/wiki/MediaWiki:Gadget-collapserefs.js I would suggest limiting it to Minerva skin. Very few people use desktop Minerva and I doubt those that do would care for this gadget.

On the longer term, with Parsoid, we'd be looking to collapse references by default on Minerva anyway (also note: mobile Minerva if viewed on desktop browser will not collapse so it's not so black and white). Alternatively, either 1) load the code on both mobile and desktop and add a check to exit early when Minerva has already collapsed or 2) write a new gadget for Minerva desktop (if it's needed)

@Izno I agree this needs to be prioritized by page views. For now I just wanted a placeholder to record the issue and remember to do something about this.

I also wonder if your numbers include the additional load from Common.css/js/skin.css/js pages? If you were checking safemode before and not after, then they do.

For now I have a very loose methodology - I wrote a script that checks Gadget-definitions and works out the default gadgets and constructs URLs which it checks the gzip size for. My hope is to get more clearer idea of what the size is when you include Common.css and skin.css. Focusing on gadgets as a starting point seems like enough work for us for now though - I'm hoping others can follow the example of enwiki on TemplateStyles adoption to solve that part of the problem.

In T340705#8979966, @Nux wrote:

The thing with en.wiki is probably that they get most of the stuff done by WMF. For example, many enhancements were made in the new Vector specifically after the mutiny on en.wiki. This is not a reproach; it just partly explains why they have fewer default gadgets.

I don't think is true at all. If you skim the history first of en.wp/Common.css even from inception here and there and certainly post 2010ish, and then various other gadget related discussion fora (WP:IANB recently, Gadgets-definition prior, WP:VPT and WP:VPR), you'll see general resistance to introduction of more styles without pressing need. Common.js has had a similar approach.

Where Stuff has been merged upstream and thus "fixed", it has tended toward the uncontroversial rather than "en.wp has this one specific need".... like "here, we need this one liner upstreamed that actually fixes the website to look the way it was intended". Well, except for mediawiki.hlist :) .

Particular to styles (rather than JS) now of course, we've done a ton of work in the past few years to get most of our Common.css styles into TemplateStyles. So that may no longer count against us. (Well, apparently it doesn't count against everyone else in the above numbers -- wrote this message several days ago. :)

The Italian Wikisource discussion can be found here.

@TheDJ That description update seems really useful, thanks! I wonder if it already exists in a common docs location, or if it could be added to https://www.mediawiki.org/wiki/Gadget_kitchen (and perhaps elsewhere)?
(I'm not a dev, hence am not boldly editing anything myself!)

I have applied many optimizations on it.wikisource gadgets, using "actions", "rights", and in a few cases "package". The situation should be much improved now.

It would be great to have another option called "namespaces", so that a gadget could be loaded only on one or few selected namespaces. This would be particularly useful for Wikisources, because we use many content namespaces: ns0, Page, Index, Author, and many gadgets operate only on one of these. Right now this is possibile only through "packaged" gadget, am I correct?

Thanks for the work @Candalua. It does look like itwikisource is still loading a significant amount of resources for anonymous users however. In an incognito window loading https://it.wikisource.org/wiki/Pagina_principale transfers 548kb of resources compared to 491kb in safe mode.

The package option doesn't optimize the module. In this mode, only the first JavaScript page will be executed but all the code will still be loaded. A namespace option does seem like a good idea and is captured in T63007. I'll follow up there to try to get this prioritized to improve the situation - thanks for flagging this!

• pa.wikisource
• pa.wikisource

Apparently pa.wikisource is so bad it counts as two. 😎 I'd edit the description directly but I'm guessing this is a typo for pa.wikipedia or another of the pa. sisters that you might want to include.

In T340705#8975269, @Izno wrote:

1. Uses https://meta.wikimedia.org/wiki/MediaWiki:Gadget-luaparse.js

Is that… Is that a Lua parser written in JS?!? I'm… If the Performance Inquisition ever comes after me for my sloppy coding I'll just point them at the existence of m:MediaWiki:Gadget-luaparse.js and go take a nap. That's… It's… It deserves to be remarked upon. Repeatedly.

In T340705#9006917, @Jdlrobson wrote:

In T340705#8986782, @stjn wrote:

I have added targets=desktop to some gadgets because I was receiving reports from users and seeing some errors in consoles after this change, and now I have to ask: what to do, for example, about https://ru.wikipedia.org/wiki/MediaWiki:Gadget-collapserefs.js if targets=desktop goes away? Like, I would be perfectly fine with throwing it away entirely, but since I don’t have that power, outside of that: it is a gadget that allows some users to collapse references by default. It doesn’t make sense to have it in mobile Minerva since it collapses all sections, but people can use desktop Minerva and expect this gadget to be there. Unless we’re giving up on the plan to remove targets=desktop, of course, then disregard my comment.

@stjn in the case of https://ru.wikipedia.org/wiki/MediaWiki:Gadget-collapserefs.js I would suggest limiting it to Minerva skin. Very few people use desktop Minerva and I doubt those that do would care for this gadget.

This is true in numbers, but interestingly I recently noticed a WMF staff member recommending a user to use desktop Minerva to have a mobile-like experience on their phone but also get navboxes: https://en.wikipedia.org/w/index.php?title=Template_talk%3ANavbox&oldid=1173910368#When_will_mobile_visibility_be_fixed%3F

While the task says enwiki is already doing fine, let me just note that EditNoticesOnMobile includes a 1K (after gzip) compression library that could be removed if T312720 would be completed. I could technically load it when needed, but considering the HTTP overhead and how splitting complicates things I decided against that.

One thought on that matter, but I'm unsure if it's technically feasible: if I could load JS using a path relative to the script path, I'd be more inclined to do that. When a script is a user script on some wikis and a gadget on others, splitting it into multiple files is a nightmare. This is one of the reasons Factotum (opt-in gadget on sqwiki, user script elsewhere) is an eye-watering single-page 818K script. This strategy has served me well though: it's easy to maintain, export to other projects and gadget-ify.

Side note: this is something for another task (which maybe already exists? please link if so), MediaWiki includes third-party JS libraries and uses, at least in case of Pako, the non-minified variant. Resourceloader doesn't minify it as efficiently as the pre-minified variant which has obfuscated (shorter) variable names. All I'm saying is: low hanging fruit?

In another task there is a text, that the template styles for heavy used templates are not the best choose: T343131#9140322

splitting gadgets brings in some cost as new (resourceloader) script modules are part of the startup module and increase that size.

In T340705#9144911, @AlexisJazz wrote:

Side note: this is something for another task (which maybe already exists? please link if so), MediaWiki includes third-party JS libraries and uses, at least in case of Pako, the non-minified variant. Resourceloader doesn't minify it as efficiently as the pre-minified variant which has obfuscated (shorter) variable names. All I'm saying is: low hanging fruit?

This could be worth doing. Let's try the minified Pako as an experiment: T346075: Use a minified version of the 'pako' library

You might find running https://en.wikipedia.org/wiki/User:Alexis_Jazz/EverybodyLikesPie.js to be of some help on these projects. See https://it.wikisource.org/w/index.php?title=Utente:Alexis_Jazz/Sandbox&oldid=3227820 for example.

@Candalua a patch just got merged to add support for limiting to namespaces. That should be available from Wednesday 27th if everything goes to plan :-) you should be able to add this before then if you want to get this in place beforehand:

The syntax is like so:

...|namespace=0,1|...

Some months ago I had applied many optimizations on it.wikisource using the |rights=purge syntax. However, right now the Special:Gadgets page is showing me this error: "The following right does not exist: purge". Did something change in user rights? Maybe the "purge" right does not exist anymore and I have to use something else?

In T340705#9493354, @Candalua wrote:

Some months ago I had applied many optimizations on it.wikisource using the |rights=purge syntax. However, right now the Special:Gadgets page is showing me this error: "The following right does not exist: purge". Did something change in user rights? Maybe the "purge" right does not exist anymore and I have to use something else?

As can be seen on https://it.wikisource.org/w/index.php?title=Speciale:ElencoPermessiGruppi the (purge) right does not exist anymore. To load a gadget for logged-in users only, you can use for example (minoredit).

In T340705#9161969, @AlexisJazz wrote:

You might find running https://en.wikipedia.org/wiki/User:Alexis_Jazz/EverybodyLikesPie.js to be of some help on these projects. See https://it.wikisource.org/w/index.php?title=Utente:Alexis_Jazz/Sandbox&oldid=3227820 for example.

This isn’t much help because this script assumes that all default gadgets load in the current skin, which isn’t true for Minerva.

Also fair warning to anyone trying it out: it posts on a page without user’s permission.

In T340705#9574638, @stjn wrote:

In T340705#9161969, @AlexisJazz wrote:

You might find running https://en.wikipedia.org/wiki/User:Alexis_Jazz/EverybodyLikesPie.js to be of some help on these projects. See https://it.wikisource.org/w/index.php?title=Utente:Alexis_Jazz/Sandbox&oldid=3227820 for example.

This isn’t much help because this script assumes that all default gadgets load in the current skin, which isn’t true for Minerva.

The current skin has no effect on the result AFAIK? But it's true that the script doesn't filter for skins. If there's a Vector-only default gadget but you're using CologneBlue, well, that gadget isn't loading for you. If there's a Minerva-only gadget but you're using Vector, same. For the purpose of finding low-hanging fruit this doesn't really matter IMHO.

Also fair warning to anyone trying it out: it posts on a page without user’s permission.

True, it dumps the pie chart on User:YourUserName/Sandbox. I added a warning comment near the top.

In T340705#9574643, @AlexisJazz wrote:

The current skin has no effect on the result AFAIK? But it's true that the script doesn't filter for skins. If there's a Vector-only default gadget but you're using CologneBlue, well, that gadget isn't loading for you. If there's a Minerva-only gadget but you're using Vector, same. For the purpose of finding low-hanging fruit this doesn't really matter IMHO.

The current skin has no effect, which is a problem for figuring out what contributes to payload on mobile. E. g. I got this in ruWP https://ru.wikipedia.org/?oldid=136342483 but most are gadgets for a namespace/action/etc. or do not load in Minerva.

In T340705#9574658, @stjn wrote:

In T340705#9574643, @AlexisJazz wrote:

The current skin has no effect on the result AFAIK? But it's true that the script doesn't filter for skins. If there's a Vector-only default gadget but you're using CologneBlue, well, that gadget isn't loading for you. If there's a Minerva-only gadget but you're using Vector, same. For the purpose of finding low-hanging fruit this doesn't really matter IMHO.

The current skin has no effect, which is a problem for figuring out what contributes to payload on mobile. E. g. I got this in ruWP https://ru.wikipedia.org/?oldid=136342483 but most are gadgets for a namespace/action/etc. or do not load in Minerva.

But this task isn't about figuring out what contributes to payload on mobile. And that pie chart seems very useful to me: it shows instantly that https://ru.wikipedia.org/wiki/MediaWiki:Gadget-wikibugs is the largest default gadget.

If you wish to filter out namespace-specific default gadgets or only see default gadgets that load on a particular skin, that's a feature request for EverybodyLikesPie.js.

One rather clean way to do this is to inject the gadget on page view that actually have a pie chart. That's how TMH adds js for loading videos, if the article has a video, it gets injected.

Regardless, I'll try to clean up fa wikis. Probably on the weekend.

While fixing Persian Wikis I realized Persian wikinews loads a lot of JS in default mode: https://fa.wikinews.org/wiki/%D8%AF%D8%B1%D8%AE%D8%B4%D8%B4_%D9%88%D8%B1%D8%B2%D8%B4%DA%A9%D8%A7%D8%B1%D8%A7%D9%86_%D8%A7%DB%8C%D8%B1%D8%A7%D9%86%DB%8C_%D8%AF%D8%B1_%D8%B1%D9%88%D8%B2_%D9%BE%D9%86%D8%AC%D9%85_%D8%B1%D9%82%D8%A7%D8%A8%D8%AA%E2%80%8C%D9%87%D8%A7%DB%8C_%DA%AF%D9%88%D8%A7%D9%86%DA%AF%E2%80%8C%DA%98%D9%88?safemode=1

Something in the software is making it serve 1,15 MB (277,12 kB compressed). Maybe the google news extension?

Thanks for improving Persian Wikipedia!

I see Persian Wikinews is loading ooui on page load. Is that the cause?

In T340705#9677822, @Jdlrobson wrote:

Thanks for improving Persian Wikipedia!

I did all persian wikis except Persian Wikipedia. That wiki has been quite clean for a while now.

I see Persian Wikinews is loading ooui on page load. Is that the cause?

It does load ooui but the problem is that it gets loaded with safemode as well. I don't know which mw piece is loading that.

In T345960#9680112, @stjn wrote:

In T345960#9680099, @Jdlrobson wrote:

It's already a thing for WMF developers: https://phabricator.wikimedia.org/T360590

Are there any metrics showing what contributes the most to the JS payload? I tried to look into that issue in Russian Wikipedia as a result of the T340705: [performance budgeting] Improve JS payload for projects with gadgets that lead to a 30%+ increase after gzip task, but we ended up with an impression that default gadgets contribute far less into the JS size than the default modules did.

@stjn there are two factors here:

1. Size of gadgets themselves
2. dependencies they pull in.

On Russian it looks like the bulk is coming from oojs-ui-core being loaded on page load. It does look like it's coming from a poorly optimized extension similar to Persian Wikinews (FlaggedRevs perhaps?) - we should identify the culprit and create a Phabricator ticket to stop that from loading on page load.

In terms of dependencies, you can work that out by visiting
https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0 and then run the following code:

localStorage.setItem('safemode=false', JSON.stringify(Object.keys(mw.loader.moduleRegistry).filter((key) => mw.loader.getState(key) === 'ready')))

and then go to https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0?safemode=1

and run..

(function(){
const safemode = Object.keys(mw.loader.moduleRegistry).filter((key) => mw.loader.getState(key) === 'ready');
const before = JSON.parse(localStorage.getItem('safemode=false'));
const diff = before.filter((x) => !safemode.includes(x));
 console.log(diff)   
}())

You can use mw.inspect() to check byte size. From what I can see ext.gadget.referenceTooltips would benefit most from optimizations as you are also loading ext.cite.referencePreviews for reference previews - these do the same thing!

The last note is the result of T282999: Enable Reference Previews on all wikis using the Popups extension, on Nov 21 to which you are privy. We never asked to have ext.cite.referencePreviews enabled, it was done without the community opt-in on an explicit promise that it should not add JS when the project doesn’t want to use it.

In T340705#9682602, @stjn wrote:

The last note is the result of T282999: Enable Reference Previews on all wikis using the Popups extension, on Nov 21 to which you are privy. We never asked to have ext.cite.referencePreviews enabled, it was done without the community opt-in on an explicit promise that it should not add JS when the project doesn’t want to use it.

Let's file a bug against Cite then. There is no reason to add both on wikis when the gadget is present.

I just copy-pasted Special:Version from fawikinews, ruwiki and enwiki into a file and checked the diff. Note that I replaced all times with 00:00 because fawiki shows different times.

Extensions that ruwiki has but enwiki doesn't:

• "Flagged Revisions – (a6b3492) 00:00, 25 March 2024", enwiki has "FlaggedRevs (Pending Changes) – (a6b3492) 00:00, 25 March 2024"
• CharInsert has a slightly different description (?)
• "Image suggestions 0.0.1 (8fd5e30) 00:00, 25 March 2024 GPL-2.0-or-later Alerts users of potentially useful images for articles Cormac Parle, Joseph Seddon, Marco Fossati and Matthias Mullie"
• "QuickSurveys 1.4.0 (f4bdc95) 00:00, 18 March 2024 MIT Displays configured surveys Bahodir Mansurov, Joaquin Hernandez, Jon Robson and Rob Moen"
• "SearchVue – (c2b9cf4) 00:00, 10 March 2024 GPL-2.0-or-later Vue.js feature additions and improvements to Special:Search Cormac Parle, Joseph Seddon, Marco Fossati, Matthias Mullie, Mark Shenoda and Volker E."

Also ruwiki has MariaDB 10.6.16-MariaDB-log while enwiki has MariaDB 10.4.26-MariaDB-log. They have the same MediaWiki version though.

Extensions that fawikinews has but enwiki doesn't:

• "Flagged Revisions – (a6b3492) 00:00, 25 March 2024 GPL-2.0-or-later Gives Editors the ability to review revisions and stabilize pages Aaron Schulz and Joerg Baach" (see above)
• GoogleNewsSitemap 2.1.0 (eac2925) 00:00, 11 March 2024 GPL-2.0-or-later Outputs an Atom/RSS feed as a Google News Sitemap Amgine and Brian Wolff
• CharInsert has a slightly different description (?)
• "DynamicPageList 1.7.0 (b82dae6) 00:00, 25 March 2024 GPL-2.0-or-later Outputs a bulleted list of the most recent items residing in a category, or an intersection of several categories Amgine and IlyaHaykinson"
• "Quiz 1.2.1 (781d2c1) 00:00, 20 March 2024 GPL-2.0-or-later Allows creation of quizzes Louis-Rémi Babe"
• "NewUserMessage 3.6.0, 2016-10-31 (159b07e) 00:00, 21 March 2024 GPL-2.0-or-later Adds a message to newly created user's talk pages Aran Dunkley and Siebrand Mazeland"

T361672 (subtask of T350514) is the main culprit here for the bloat on Russian Wikipedia from what I can see.