Page MenuHomePhabricator

Lazy loading images causes performance issues with section uncollapsing on Firefox for Android
Closed, ResolvedPublic


Since MediaWiki 1.30, on large pages under a mobile device, MobileFrontend+MinervaNeue takes a noticeable time to open sections (like 1 or even 2 seconds!), specially on Firefox (in Google Chrome this is less noticeable), to the point to be really annoying.

This wasn't the case in MediaWiki 1.29 with MobileFrontend (Minerva integrated), opening such sections were reasonably fast. Trust me, I've just upgraded to MediaWiki 1.30 and that's why I've noticed it.

This is happening on our wiki (see example, section "Movimientos", but others as well ).

I've tried to replicate it also on (less links and templates, substituting images): here, which is a bit less noticeable, probably because of less links and styles.

My device is Alcatel OneTouch Idol 3 5.5' (CPU Snapdragon 615 1.5GHz, 8 cores, 2GB RAM)

Another thing that also I've noticed (may probably be worth creating a new task), is that the time it takes is increased when you try to open a section just after you scrolled. Also, sometimes, after scrolling, it opens the wrong section (this is random and not easy to reproduce, but happens sometimes)

Event Timeline

Mm strange. There's nothing I can think of that may cause slow down.

Are you seeing this issue on Firefox mobile or Firefox desktop and is this just on the Alcatel OneTouch? When I try your site now I'm not noticing anything unusual so this is likely to be a browser specific problem.

Firefox mobile (on mobile device). On firefox desktop emulating a mobile device doesn't cause this issue, but probably because I have a high performance computer.

The problem is noticeable also on chrome mobile, but less significantly.

I suspect the problem is related to the lazy loading of the images, because other pages don't have this issue (and that specific page has lots of them). When I was using MediaWiki 1.29 the images weren't lazyloaded (and there were no slowdown).

Can you disable lazy loading images to see if the problem goes away? Would be useful to know!

wgMFLazyLoadImages = ['base'=>false, 'beta'=>false];

Yep, that's indeed the problem. It opens sections instantly now.

Jdlrobson renamed this task from Collapsible sections take a noticeable time to open/close (specially on Firefox) to Lazy loading images causes performance issues with section uncollapsing on Alcatel OneTouch Idol 3 5.5.Jan 29 2018, 8:47 PM

I've done some testing on that page to see if the lazy loading scripts were the culprit.

Here's a profile of the Chrome devtools timeline with cpu throttling of 6x:

If you load it you can see that there is a huge style recalculation after expanding the section, so it is possible the lazy loading images code has some impact.

It is strange though, since images smaller than 50px are not lazy loaded, so all those small images shouldn't be even touched by the code.

For reference:

After all of this, I'm not sure that lazy loading images is actually the culprit of this, there may be some other factor triggering style recalculations on a lot of the DOM but it doesn't make much sense that it is the fault of this feature.

There may be other features introduced in the last version, so maybe something else is the culprit.

Can you test ? I can see it lazy loading the images of the same section. There may be some logic problem on that script and it's not doing what's supposed to do.

@Ciencia_Al_Poder Those two pages are not showing the same images:

  • Wikidex, See in Chrome: view-source:
    • Find lazy-image-placeholder
    • 0 results
  • Your test page, See in Chrome: view-source:
    • Find lazy-image-placeholder
    • 459 results

So your page actually lazy loads the small images while the wikidex one doesn't right now.

I think he enabled skipping lazy loading small images.

From what I've seen, lazy loading small images actually has better performance than not lazy loading them, see these two chrome profiles (6x cpu throttling, galaxy s5 profile, just measuring opening the "Movimientos" section):

So just to understand, does behave performantly on your device now? Or ? Or none? Because that may be counter intuitive to the tests I've been running.

If that is the case, we may have to switch to real device analysis for this one.

Indeed, both pages don't display the same images. This is because I wanted to create a test page on a WMF wiki (running a near-master version of MediaWiki and extensions), but also I didn't want to upload all the required images to make the test close to the original problem, so I searched for small images in commons with similar sizes to replace the ones used on our wiki. Note also that the test page on WMF is more simple, as I stripped all internal links (which would render red links otherwise). This of course makes the DOM more simple and may cause a bit gain in performance.

And yes, I've disabled lazy loading images as suggested by Jdlrobson. I can enable it on a test site if you want (will probably do when I arrive at home) does not behave performantly on my device, or at least not in FIREFOX (latest update). didn't behave performantly before disabling lazy load of images. It now does behave performantly after disabling lazy load of images. Again, on Firefox.

I think it has nothing to do with my device, but with Firefox browser for Android (on a mobile device). On Google Chrome for Android the performance is hardly noticeable. On Firefox for Android it's highly noticeable (1 second aprox. when clicking on the section header until it's opened/closed)

Ciencia_Al_Poder renamed this task from Lazy loading images causes performance issues with section uncollapsing on Alcatel OneTouch Idol 3 5.5 to Lazy loading images causes performance issues with section uncollapsing on Firefox for Android.Jan 31 2018, 10:37 AM
ovasileva triaged this task as Medium priority.Feb 6 2018, 3:24 PM

@Ciencia_Al_Poder could you try turning back on lazy loading images but also set the following:

wgMFLazyLoadSkipSmallImages = true;

I think this will give you the best of both worlds.

Ok, thanks. I've done this and the performance has improved a lot.

Jdlrobson claimed this task.

Seems like the solution here was to use wgMFLazyLoadSkipSmallImages = true;