== Steps to reproduce
# Go to https://en.m.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units on a mobile device (also reproduced on https://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units)
# Attempt to scroll or tap the menu
== Expected results
menu opens, page scrolls, etc
== Observed results
Page is unresponsive
== Environments observed
- Browser version: Chrome 73.0 , Firefox 66.0.2
- OS version: Android 9
- Device model: reproduced on Moto g7 plus, unsure of device of original report
== Notes:
- originally reported via email
- original reporters noticed a javascript task running for a really long time (~7s)
{F28619495}
- It appears this is at least in large part due to the pageIssues.js code in Minerva and is most noticeable when a page has a lot of nodes (the reported pages on this ticket each have over 18,000 nodes). As seen from the screenshot of the profiler, the initPageIssues function takes around 2.5 seconds to complete and blocks the main thread. During this time, many `this.$el.find( HEADING_SELECTOR )` calls from `Page.js` are made each taking around 30ms. If that call is cached as done in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/503130/, this blocking from the pageIssues.js code is greatly reduced (from ~2.5s to 78ms, but it also increases the execution of the Toggler.js code (from ~7ms to 700ms)! This may be because Toggler.js code [[ https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/aba6ac0b55d59ad9aaff513629649f6baba6daf0/src/mobile.startup/Toggler.js#L262 | stores the instance of Page in each heading ]]. More investigation is needed as to why this is happening to best to approach this.
- Basically, the cause of this jank is multifactorial and there are multiple performance optimizations we can make in the MF code