User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

goto web page www.ntv.com.tr.

Actual results:

1. Page is not loaded in a respectful time (1-2 mins although high speed internet available)
2. Also all other tabs stopped responding even in private mode.
3. Restarting firefox doesn't help either

Expected results:

1. Able to see the webpage and no other tabs are affected.

Hi, I reproduce the issue with device Huawei MediaPad M3 Lite10(Android 7.0) on Firefox Nightly 68.0a1(2019-07-01), Firefox Beta 68.0b14, Firefox Release 67.0.3 and Firefox Nightly 69.0a1(2019-07-03).

Diana does it reproduce using other mobile browsers? How about with Preview/Fenix?
ercan, did you try contacting the site to report the problem to them?

Hi,

• On Chrome - version 75.0.3770.101 - the page is rendered in a couple of seconds 3-5 seconds.
• In Firefox Preview - version 1.0.0 - the page also loads on an average of 40-50 seconds.

Sending this bug to [qf] performance triage.

I can reproduce this on my Moto G5 Plus. The ntv.com.tr home page loads in about about 4 seconds in Chrome, but 1+ minutes in Fennec 68 and Fenix. It would be helpful if someone would record a Gecko profile.

https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler

https://perfht.ml/2Yd8D0w , I see mozilla::PresShell::DoFlushPendingNotifications was extremely busy.

DoFlushPendingNotifications is just what happens when the page requests layout/style information and we have to flush the results of their prior layout/style mutations.

At first glance, it seems the page is doing a whole bunch of layout/style-flushing APIs during its DOMContentLoaded event (e.g. reading .clientWidth), and I'm guessing they're modifying styles between those.

After that, we thrash a lot when servicing deviceorientation events. Bug 1515780 will probably help with that.

I'll take a closer look here and see if there's anything obvious (beyond bug 1515780) that we can do/suggest here...

(In reply to Daniel Holbert [:dholbert] from comment #6)

At first glance, it seems the page is doing a whole bunch of layout/style-flushing APIs during its DOMContentLoaded event (e.g. reading .clientWidth), and I'm guessing they're modifying styles between those.

They are indeed doing a tight "modify style / flush layout" sort of loop. Here's one illustrative section, filtered for "CSS2Properties" (which I believe indicates that they're using elem.style.[whatever] e.g. to modify style):
https://perfht.ml/2YdQ6Rx
...and here's that exact same section, filtered for offsetWidth which flushes style/layout changes:
https://perfht.ml/2Y6mwNX

Notice that they're doing both quite a lot, and doing it in an interleaved way, which means that there's guaranteed to be pending work to be flushed every time.

It's possible that we should be able to optimize away much of the work -- e.g. I do notice that many of the layout-flushes have a sample in nsFlexContainerFrame, so it's possible that flexbox layout optimizations will reduce the cost of these layout flushes.

Anyway -- for now, triaging as [qf:p2:pageload]

Moving this bug from the GeckoView Bugzilla component to Layout.

I can't reproduce any significant delay, using latest Firefox Preview Nightly on my Pixel 3 device. The site loads in around 5-10 seconds, about the same amount of time as Chrome on the same device.

Diana, would you mind retesting and see if you're still seeing delays? (It sounds like you were seeing significant delays as compared to Chrome a little while back, per comment 3. I'm curious if my results today are an indication that this has been fixed, vs. if my device/conditions simply aren't sufficient to trigger the issue.)

Hey, sure, with:
Samsung Galaxy S9 (Android 8)

• Fennec 68.9.0 - first load 29 seconds and reload of the page 39 seconds
• Firefox Preview Beta 5.2.0-beta.1 - first load and reloads of the page 9 to 12 seconds
• Firefox Preview Nightly 6/15 - first load and reloads of the page, 9 to 12 seconds

Pixel 3 XL (Android 9)

• Fennec 68.9.0 - first load 18 to 20 seconds and reloads of the page 7 to 10 seconds
• Firefox Preview Beta 5.2.0-beta.1 - first load 7 to 9 seconds and reloads of the page 9 to 16 seconds
• Firefox Preview Nightly 6/15 - first load 16 to 17 seconds and reloads of the page, 5 to 7 seconds

Thanks! Sounds like our latest versions (Preview Nightly) are way better than 1-2min as originally reported here.

For comparison, could you try with Chrome as well? (on either or both of those same devices)

Yes of course:
Chrome 83.0.4103.101

• Google Pixel 3 XL (Android 9) - first run 5 to 11, for reloads from 2 to 5 seconds
• Samsung Galaxy S9 (Android 8) - first run 4 to 6, for reloads from 7 to 12 seconds

Thanks, Diana!

Last question for now: for your measurements, were you watching the browser's "loading bar" (and calling it "complete" when that bar disappeared), or were you watching for the page to stop having pieces appearing/loading?

I'm asking because: when I load the page (on my Pixel 3) in Firefox Preview Nightly vs. Chrome, it feels like they take approximately the same time to get to "visually complete" (when pieces stop visually loading/appearing). BUT, Chrome's "load bar" stops pulsing really early, while parts of the page are still blank, whereas Firefox's load bar continues pulsing until all of the page has stopped loading. That's interesting & may be part of the reason for the timing-differences reported above (if my observation about this wasn't just a one-off).

My takeaways:

• It sounds like Firefox Preview Nightly might still be a few seconds slower than Chrome in some tested configurations, and on-par in others (particularly on the Samsung Galaxy 9 "reload" case -- note that it's bizarre for Chrome's first-load to have been faster than reload there, so I'm a bit suspicious something weird may have happened there) -- though this might be entirely explainable by the load-bar differences, if that's what Diana was using for her metrics.

• In any case, the magnitude of difference is way down vs. the original reports here (where our load times were 1-2min [with a full-browser-lockup] in comment 0, and 40sec in comment 3).

• So: any relatively-small timing differences that exist now are almost certainly unrelated to what was originally slowing us down here.

So I think we can say this bug (as-reported) is WORKSFORME, and I'm going to spin off a followup bug on the load-bar differences.

(In reply to Daniel Holbert [:dholbert] from comment #14)

• It sounds like Firefox Preview Nightly might still be a few seconds slower than Chrome in some tested configurations, [... ]though this might be entirely explainable by the load-bar differences, if that's what Diana was using for her metrics.

Following up on this: Chrome and Firefox both agree that there's still a bit of background pageload action going on, even after the page is visually complete. In both browsers, you can see this by opening the "kebab menu" (three-dot-menu) and watching for the "x"-icon stop-button to change to a reload icon. For me, there's a few seconds of delay between when the page stops loading stuff & when this change happens. (See e.g. my Chrome screencast in https://bugzilla.mozilla.org/attachment.cgi?id=9157126 - the stop/reload icon-swap happens at around ~0:20 in that screencast.)

In Firefox Preview Nighlty, the browser's loadbar happens to be synchronized with this stop/reload icon-change; in Chrome, the loadbar disappears long before that, for some reason. This is what bug 1646191 is filed to investigate, anyhow -- just noting it here since it is likely part (or all) of the reason for the measurement differences between comment 11 and comment 13.

Hi Daniel,

Last question for now: for your measurements, were you watching the browser's "loading bar" (and calling it "complete" when that bar disappeared), or were you watching for the page to stop having pieces appearing/loading?

For this i didn't watch after the loading bar, as you said it stops way to early and elements from the page are not completely loaded, so on Chrome I checked when the elements from the page have been loaded and also for the change in Chrome's menu, where the reload button is (which will have an "X" mark until loading is finished).

I can check a bit and see whether i can have a more precise measure through a logcat, there must be a line there which can indicate when the loading of a page stops, let me know.