1465205 - Nested grid/flex layout is slow in mobile UI at http://www.wikia.com/fandom

Status: NEW

(Core :: Layout, enhancement, P3)

Description

[Daniel Holbert [:dholbert]]

Per bug 1458079, we're slower than WebView (WebKit/Blink) at loading http://www.wikia.com/fandom on mobile.  I'm spinning this off for the layout parts of that. Some of the below is copypasted from bug 1458079 comment 6.

In a profile that cpeterson captured, there's a single initial reflow that takes 106ms: https://perfht.ml/2kwk2mi
(That time -- 106ms -- is what's reported in the tooltip when I hover the blue "reflow" bar.  The "Running Time" samples only total up to 49ms, but I'm assuming that some of those are missing, or they're recorded with the wrong duration or something, since I know that happens on some platforms.  I'm assuming I should trust the measurement on the blue "Reflow" bar more than the sample times.)

The reflow includes nested block -> grid -> flex -> flex containers.  It's hard to know where precisely the issue is coming from, but I'm guessing we're probably re-measuring the same content several times when technically we don't need to.  It's possible bug 1377253's flex-item-size-caching will help with this, and/or we might need to cache size measurements for grid items more aggressively as well.

I think you can view the mobile UI on desktop by visiting http://www.wikia.com/fandom in Responsive Design Mode.  Looking at that rendering in devtools, I do see:
 - a div with class="feed-layout__container" that is display:grid
 - ...which has grandchildren that have class="feed-item" that are display:flex
 - ...which have descendants with class="card__content" that are display:flex
This probably roughly corresponds to the grid->flex->flex nested layout that can be seen in the profile backtrace.

Comment 1

[Jonathan Watt [:jwatt]]

P3, unless you think otherwise.

Comment 2

[Daniel Holbert [:dholbert]]

I'm less sure that this is an explanation for our difference vs. Chrome/WebView in original bug 1458079.  I'm going to ask for another test over there to see if things have changed...

To test this locally, I just recorded some 4 profiles (on Linux desktop) and I'm consistently seeing that Firefox's initial reflow much faster than Chrome's

Firefox initial "reflow" timing:
 23.6ms
 33.6ms
 41.2ms
 47.9ms
Average: 36.6ms

Chrome initial "Layout" timing (looking at the first bar labeled "layout" in a Chrome profile):
 56.1ms
 115.24ms
 76.4ms
 131.11ms
Average: 94.7ms

My process was to start at https://example.org in responsive design mode (w/ Galaxy S5 as the spoofed UA/size in Chrome vs. Galaxy S9 in Firefox), start profiling, visit http://www.wikia.com/fandom, and stop profiling.  I also turned off firefox's content blocking, to avoid getting an unfair advantage from that.

Here are the Firefox profiles I recorded (on "marker table", with the first/longest reflow listed at the top, consistently in the 23ms-33ms range):
https://perfht.ml/2TavMLx
https://perfht.ml/2T7rLYp
https://perfht.ml/2TcDEfm
https://perfht.ml/2T8vEfr

So from my testing, we seem to be ~3x as fast as Chrome on this initial layout, on desktop at least.  Also notable: the long initial reflow that cpeterson captured on mobile (106ms) is actually about as long as a typical initial "layout" on Chrome desktop.