Open Bug 1472941 Opened 6 years ago Updated 2 years ago

Slow loads and performance at dvhn.nl, compared to Chrome

Categories

(Core :: Layout, enhancement, P3)

60 Branch
Unspecified
Android
enhancement

Tracking

()

Performance Impact medium

People

(Reporter: karlcow, Unassigned)

References

()

Details

(Keywords: perf:pageload, Whiteboard: [webcompat])

1. Go to  http://www.dvhn.nl/
2. Accept Cookies
3. Monitor how long it takes to load the page
4. Scroll quickly toward the bottom

Try these with Firefox Android and Chrome Android.

Notice the difference. Chrome is a lot more performant.
Hey karlcow, is it possible to post a profile from your device running Firefox Android on this page?

Guide: https://perf-html.io/docs/#/./guide-remote-profiling
Flags: needinfo?(kdubost)
Sure thing.

At my first attempt, Firefox crashed when scrolling. I will try again.
Hmm I tried a couple of times (~10) and this is crashing my device.

Let's change strategy. I will first do a performance profile after the first load, when scrolling if possible.

OK this! worked. 
* Scrolling https://perfht.ml/2Nnq464


Let's see if I can do the first load only.
Nope… no luck… crashing each time. I guess my device has not enough memory and it takes too long?! I have no idea.
Flags: needinfo?(kdubost)
Dan, please investigate this for QF. Thanks!
Component: General → Layout
Flags: needinfo?(dholbert)
(In reply to Karl Dubost :karlcow from comment #2)
> Let's see if I can do the first load only.
> Nope… no luck… crashing each time. I guess my device has not enough memory
> and it takes too long?! I have no idea.

I captured first load in the profiler on Android.  The load took the better part of a full minute.
  https://perfht.ml/2LPkyvS

Unfortunately there are no symbols, but we can see that there are a bunch of ~1-second-long DOM "load" events (probably for images?), with most of the event-landler time spent in relatively short synchronous DoReflow calls, to handle a call to Element.getBoundingClientRect for some jquery "offset" function.

It looks like Karl's profile has roughly the same characteristics under the hood (long DOM Event handlers, for "resize" in his case, with most time spent in many small synchronous reflows to service getBoundingClientRect calls).

So it looks like they're doing lots of "change style and then query layout" operations inside of these handlers, which is kind of a performance anti-pattern. :(

Presumably some of these reflows can be optimized (and/or some of the style changes may not actually require dirtying layout), which is how Chrome is getting away with being faster here...

I captured a profile of pageload on Desktop, too (in Responsive Design Mode with Google Nexus 5 as my "device"): https://perfht.ml/2vugshF

The load is faster there, but it shows the same characteristics as my Android profile (lots of long load handlers, particularly towards the end), and it's got symbols as well.  Looks like nested table/block reflow, at first glance.
Bas, do you have any idea about the usage of this website in the Netherlands?

Anyway, tentatively calling this a QF p1 for now, in the hopes that there's some optimization that we could be making here to avoid / speed up these many short reflows...
Flags: needinfo?(dholbert) → needinfo?(bas)
Summary: Slow loads and performance on Firefox Android compared to Chrome → Slow loads and performance at dvhn.nl, compared to Chrome
Whiteboard: [webcompat][qf] → [webcompat][qf:p1:f67]
(In reply to Daniel Holbert [:dholbert] from comment #5)
> Bas, do you have any idea about the usage of this website in the Netherlands?
> 
> Anyway, tentatively calling this a QF p1 for now, in the hopes that there's
> some optimization that we could be making here to avoid / speed up these
> many short reflows...

It's a local newspaper. It covers 2 fairly sparsely populated provinces, the paper version circulates about 100 000 on work days. I would say it's a 'fairly important' local news site as far as local news sites go, but it does serve a population of only ~1 million.
Flags: needinfo?(bas)
Whiteboard: [webcompat][qf:p1:f67] → [webcompat][qf:p1:pageload]

For what it's worth, Tracking Protection seems to help a decent amount here. (And it seems to prevent an complex ad that currently seems to be the final thing that blocks pageload and occupies the top ~1/3 of my phone's screen.)

Here are 2 loads with Tracking Protection enabled (both under 15 seconds):
https://perfht.ml/2VFAH8F (pageload takes ~6-7 seconds)
https://perfht.ml/2VLV9Ey (pageload takes ~13 seconds

...vs with Tracking Protection disabled:
https://perfht.ml/2VGKwD3 (pageload takes ~19 seconds)

Chrome is still much faster, though. (And for some reason, its loading bar completes before the "top-1/3-of-the-screen" ad even appears, whereas in Firefox-with-no-tracking-protection, that ad seems to be one of the things preventing the loadbar from finishing.)

Unlike in comment 4, I've got symbols for my new Android profiles now (hooray!). Here's a little bit of analysis of my "tracking protection disabled" profile...

  • We're still spending quite a long time in Element.getBoundingClientRect calls (7.6 seconds): https://perfht.ml/2VR4cV4

  • That still looks like nested table/block reflow

  • For the last ~5 seconds of load time, we're much less reflow-heavy -- only 300ms out of the final 5.6 seconds: https://perfht.ml/2VIGOJf
    I think we're just running script for most of that time (?)

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

I tested the site on Moto G5. I think there wer two problems here, page load and scrolling after the page is loaded;

The scrolling experience seems to be comparable to Chrome on my Moto G5 now, however the page load is definitely slower.

GVE page load profile: https://perfht.ml/2Yof5la

Whiteboard: [webcompat][qf:p1:pageload] → [webcompat][qf:p2:pageload]
Webcompat Priority: ? → ---
Performance Impact: --- → P2
Keywords: perf:pageload
Whiteboard: [webcompat][qf:p2:pageload] → [webcompat]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.