Change #1091774 merged by jenkins-bot:

[mediawiki/extensions/Popups@master] Stop using deprecated mediawiki.Uri module

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

For the late loading of banners, the performance team did a study 2019 how it affects user satisfaction: https://techblog.wikimedia.org/2019/06/13/performance-perception-the-effect-of-late-loading-banners/

Change #1091774 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/Popups@master] Stop using deprecated mediawiki.Uri module

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

I have deleted remaining Buster VMs.

I've have some input:

Here's desktop and mobile banners where we execute our entry point code but only mount the Vuejs banner component after the 7.5 second timeout:

Good news everyone! I thought about this a bit more and ran another test to confirm/falsify my hypothesis of "all that JavaScript execution increases the TBT". I created a test banner where I wrapped our current banner in a 7.5 second timeout. It'll still be loaded by CentralNotice, increasing the Page Transfer Size (which we could avoid for repeat visitors if CN supported sending HTTP cache headers for banners, but that's outside of WMDE's control and needs a separate ticket and discussion in the WMF team that maintains Central Notice), it'll still parse the JavaScript, but the initialization code for the banner would be run outside the "measuring window" (that measures the "Time To Interactive" and then some). The results of the test look very promising: The TBT went down by almost 100ms and is now at pre-banner levels. See for yourself in the comparison of the regular banner with the timeout-banner as the baseline. The cpu.lastLongTask and cpu.totalDuration show even greater improvements. You can of course also look at the individual result of the banner with timeout

Hi @gabriel-wmde thanks for the investigation. I agree with you that it doesn't look like quick fix and I like your idea that we all need to work together.

@AKanji-WMF to check in with central notice users and @Sheilakaruku

Thanks everyone for the support.

@WMDE-leszek and @gabriel-wmde - There is no current assignee for this ticket and no priority set. Given the issue lies in code you all maintain, I would request you set an owner and assignee to clarify next steps here. Please let me know if you have concerns with this, but given the magnitude of the performance impact I think it's important to have clear ownership and explicit priority. Thanks

Hi @kostajh, this one feels more like feature work, so I'll move it out of our Chaos board (bug fixing work) and leave it in the Fundraising Tech backlog to be triaged. Thanks!

Possibly caused by TranslateEventMessageGroupStateChange hook.

Hi all -
Firstly, thank you @Peter for catching and filing this issue, and providing further clarity! And thank you @gabriel-wmde for looking into this.

Hi @gabriel-wmde , sorry for being slow on this. Ok, let me explain the performance tests:

Thanks for the comment, @awight. Good idea to load banner asynchronously, I agree with your assessment and like your proposal.

(Wasn't sure which Fundraising Tech team tag to use)

Change #1085582 merged by jenkins-bot:

[mediawiki/extensions/CentralNotice@master] Add namespace description for Special:NamespaceInfo

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

Change #1085582 had a related patch set uploaded (by Msz2001; author: Msz2001):

[mediawiki/extensions/CentralNotice@master] Add namespace description for Special:NamespaceInfo

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

I wrote up a quick suggestion about wrapping <script> tags in banners with a named IIFE here: T361680#9965391

WMF doesn't use or maintain the Schema namespace in EventLogging anymore. The Data-Products team currently owns EventLogging, but I don't expect them to do any work here. I believe they'd like to one day deprecate EventLogging extension generally.

Change #1082128 merged by jenkins-bot:

[mediawiki/extensions/Translate@master] Add namespace description for Special:NamespaceInfo

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