1504121 - carlsen.porschedealer.com - Site is nearly unresponsive

Status: RESOLVED WORKSFORME

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Karl Dubost💡 :karlcow]

This is a spin-off of webcompat.com https://webcompat.com/issues/20636

Attempt at a performance profile, when clicking on the photo and trying to slide to the next photo.
https://perfht.ml/2QajwZz


* Site is very slow with occasional warning on the top of the viewport.
* CPU goes high
* Gallery takes a long time to open
* Sometimes gallery arrow to move to the next photo doesn't work

Comment 1

[Daniel Holbert [:dholbert]]

Emilio, looks like we're spending a lot of time in getComputedStyle & stylo resolution.  Mind taking a look? (Shot in the dark: maybe helped by bug 1381071, though I'm not sure if there's a display:none subtree involved here.)

Comment 2

[Emilio Cobos Álvarez (:emilio)]

I won't try to understand why loading this page loads a bunch of different jQuery versions and React...

Looking at the site in Chrome also takes forever to load and such, fwiw, so it's not a case of "it's snappy on other browsers, but it sucks in Firefox", at least...

I took a look at the modal issue, and they're using an old version of fancybox, which has code like:

		beforeShow : function(opts, obj) {
			var scrollV, scrollH;

			if (obj.locked) {
				if (this.margin !== false) {
					$('*').filter(function(){
						return ($(this).css('position') === 'fixed' && !$(this).hasClass("fancybox-overlay") && !$(this).hasClass("fancybox-wrap") );
					}).addClass('fancybox-margin');

					this.el.addClass('fancybox-margin');
				}

				scrollV = W.scrollTop();
				scrollH = W.scrollLeft();

				this.el.addClass('fancybox-lock');

				W.scrollTop( scrollV ).scrollLeft( scrollH );
			}


So yeah, they're calling getComputedStyle on literally every node in the document, and getting the position value out of it.

This:

  $("*").filter(function() { return $(this).css("position") === "fixed" });

Takes ~2s in Nightly, >1s in Chrome, probably because of the missing optimization which is bug 1381071. Chrome also is much faster in subsequent runs, but I think it'd be defeated in practice because they're adding a class to all of the elements.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

I couldn't repro the other bits, but from the profile it looks like some sort of injected code that is doing stuff with mutation observers, grepping from the source. Blink and WebKit don't support some kinds of mutation events, so if they're using them they may be getting less mutations or what not...

Karl, do you know if there's a reliable way to repro that (slowness from hideFromAT and such?)

Comment 4

[Karl Dubost💡 :karlcow]

Emilio, same here. 
I'm not sure if they modified the code or if we released something in the last 5 days, but the user experience seems to be a lot better. At least for me today.

Comment 5

[Oana Arbuzov [:oanaarbuzov]]

It is working fine for me too. 

[Tested with:]
Browser / Version: Firefox Nightly 65.0a1 (2018-11-06)
Operating System: Windows 10 Pro

Comment 6

[Daniel Holbert [:dholbert]]

Let's close this as this worksforme then, per comment 3 - 5. (I just retested in Nightly on linux, too, and the site seems reasonably responsive, including the photo viewer UI that was mentioned in the webcompat issue.)