It's ResourceLoader loading a bunch of CSS.

@Peter wrote in the task description:

[…] test on my Alacatel One phone and see that we have a really long task that happens late when testing https://en.m.wikipedia.org/wiki/Barack_Obama [that] lasts for 881 ms = the user can't do anything = if the user presses a key etc it causes a first input delay. My guess is that this is the biggest cause of high FID on mobile.

Dec 2019

In T241139#5756313, @Gilles wrote:

It's ResourceLoader loading a bunch of CSS.

Actually, it's not. This is pure JavaScript execution, wholly attributed to mobile.init.js. There is virutally no time spent at all in mw.loader in this screenshot.

The wide pink bar (mw.loader) seems significant, and it's an easy to mistake to make given that we're used to thinking about execution from left to right. But, when a callback is involved, a flame graph always shows the "next" code below the previous one instead of besides it.

When the browser receives a module with CSS and JS, the flushCssBuffer is called to apply the styles, and then it calls runScript to let the browser execute the module's JavaScript code, in this case mobile.init.js.

With that information in mind, the screenshot is quite clearly spending more than half a second in the various JavaScript functions bundled with mobile.init.js.

To illustrate, below I've added a magnifying glass to show where the time actually spent in flushCssBuffer is visualised, and where it is not:

I've taken a new capture today of https://en.m.wikipedia.org/wiki/Barack_Obama in latest Chrome with emulated mobile CPU, and it seems it's still spending quite lot of time in mobile.init.js, with uninterrupted back-to-back synchronous calls doing expensive work in JS during page load, whilst the device is frozen for user input.

24 Aug 2021

2023 update — this is still an issue. Here is the profile from my $100 Xiaomi Redmi 9A phone:

Mo's out this week, but since this is performance related it would be good to get him involved in this task!

Change 908333 had a related patch set uploaded (by Nray; author: Nray):

[mediawiki/extensions/MobileFrontend@master] Remove ~250ms of unnecessary JS execution

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

Step 1: Remove unnecessary JavaScript

In Toggler.js, there was a small block of JavaScript that wasn't working correctly and was taking ~250ms to execute on my xiaomi redmi 9a phone. Therefore, I'm removing it in https://gerrit.wikimedia.org/r/908333. For long pages like the "United_States" page, this small step cuts the task's JS execution time by nearly half.

Before: {F36948677}

After:: {F36948678}

Change 908333 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Remove ~250ms of unnecessary JS execution

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

Change 908588 had a related patch set uploaded (by Nray; author: Nray):

[mediawiki/extensions/MobileFrontend@master] Split toggling code into a smaller task

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

Change 908674 had a related patch set uploaded (by Nray; author: Nray):

[mediawiki/extensions/MobileFrontend@master] Add 'getThumbnail` method to PageHTMLParser

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

Change 908675 had a related patch set uploaded (by Nray; author: Nray):

[mediawiki/skins/MinervaNeue@master] Replace slow thumbnail init code with event delegation

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

Change 908588 abandoned by Nray:

[mediawiki/extensions/MobileFrontend@master] Split Toggler.js initialization into a smaller task

Reason:

I think this may interfere with code that depends on mobile.init's toggling initialization being synchronous such as https://github.com/wikimedia/mediawiki-extensions-DiscussionTools/blob/master/modules/controller.js#L450 . If I have time at end of sprint, I will circle back to this

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

Change 908588 restored by Nray:

[mediawiki/extensions/MobileFrontend@master] Split Toggler.js initialization into a smaller task

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

Change 908674 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Add 'getThumbnail` method to PageHTMLParser

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

Change 908588 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Read browser width at beginning of Toggler _enable method

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

Change 908675 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] Replace slow thumbnail init code with event delegation

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

Results

I think this work resulted in a ~50% reduction in JavaScript execution time for the task on long pages like the "Barack_Obama" page which represents around ~260ms improvement in Total Blocking Time on the Moto G (5) phone that our synthetic tests use:

https://grafana.wikimedia.org/goto/0ZaWBSsVz?orgId=1

On my $100 Xiaomi Redmi 9A phone, there is roughly a ~450ms improvement in total blocking time going from a ~725ms task to one that takes ~280ms:

Before:

After:

Future work

Note that any task greater than 50ms is considered a "long task" and can affect the usability and responsiveness of a website. Therefore, on low-end devices, this task is still too long, but much improved. I cut away at some of the lowest hanging fruit by removing unnecessary JavaScript and using event delegation, but there are ways that this can be reduced further:

1. A costly forced synchronous layout can still happen as a result of the mobile.init module/Resource Loader appending a stylesheet and then the Toggler.js reading the browser's width. Ideally, the browser width check would happen at the beginning of the frame and before any invalidation (e.g. DOM mutations) so that the browser can simply read the values from the previous frame.
2. The toggling code persists sections that the user opens using sessionStorage. When it tries to expand them during page load it can lead to a massive task (e.g. ~2s on my MacBook Pro using 6x CPU throttle testing the "United_States" page with all sections open) from the recalc style/layout it causes:

I think we should reconsider how valuable this feature is relative to its performance/user experience penalty. If it is valuable, perhaps there is a way that we can open the sections before the page is rendered so that the browser doesn't have to do expensive layout calculations multiple times during page load.

@pmiazga's dared me to write a blog post about this experience during our super happy dev time meeting, so it's at https://www.nray.dev/blog/300ms-faster-reducing-wikipedias-total-blocking-time/ 🙂