Page MenuHomePhabricator

2017 USA banners may freeze your browser for 1-2 seconds
Open, Needs TriagePublic

Description

According to a Firefox test and a Chromium test, the USA banners being currently tested delay page loading by about 1 second in Chromium and 2 seconds in Firefox.

Some users have reported that in this timespan their browser is frozen, and I had a similar experience (Firefox 55.0 and Chromium 59.0.3071.104).

Those banners tamper with the content in various ways; I guess the JavaScript they use has room for improvement. Their definition can be found somewhere among https://meta.wikimedia.org/w/index.php?title=Special:CentralNoticeBanners&offset=0&limit=100&filter=B1718_0823_en6C

Example url:

Event Timeline

Nemo_bis created this task.Aug 27 2017, 6:49 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 27 2017, 6:49 AM
This comment was removed by Zoranzoki21.

@Zoranzoki21: Please explain how you tested something (what?) and what your result was. Otherwise such comments are too vague and do not help developers.

This assessment is misleading, the difference is actually 200ms or less for displaying the article. Look at the Speedindex values for that. It's just that the banner appears a second later.

So the banner may be slow to load, or show up after a purposeful delay, but a single run on webpagetest.org showing a 200ms difference isn't enough to assess that there's a dramatic difference in loading the article itself. Webpagetest.org public instances are shared and subject to quite a bit of variation between runs as a result, we would need more data for this comparison to be conclusive.

Moreover, using the special URL parameters to invoke the banner isn't the same as the banner actually running live. One dramatic difference that I see immediately is that when the banner parameters are present, is that all Varnish caching is skipped, making the load akin to a loggedin view: https://www.webpagetest.org/result/170827_Z9_9a947c6c1ce845681b1295e678156ef6/2/details/#step1_request1 (look at the x-cache-status response header, "pass" means Varnish is bypassed)

Compared to a Varnish hit for the base case: https://www.webpagetest.org/result/170827_ER_34f2816d9c794a7807a70e197ea3cd4b/1/details/#step1_request1 (x-cache-status: hit)

This alone would explain the 200ms different for the article pageload.

To summarize, you're dealing with 2 things:

  • when adding parameters to invoke the banner manually, you are bypassing Varnish cache, which results in worse performance because PHP has to render the article instead of it being served by Varnish
  • the banner shows up late (on purpose or not, I guess that needs to be figured out), which skews metrics and the filmstrip but doesn't mean anything about the performance of the initial pageload, when the article shows up

As for the browser feeling frozen, we can't verify that easily, but WebPageTest provides hints with CPU usage, browser main thread and "page is interactive".

The reference run from "chr-base":

The reference run from "fr2-chr":

It does look like the span of time during which the page isn't interactive is a bit longer, as it it was extended a little (by about 0.2 seconds in this case). It's difficult to say if there's anything that can be done about it, though, but it does look like something fr-tech should look into.

Nemo_bis added a comment.EditedSep 7 2017, 6:25 AM

Thanks Gilles for the analysis. I understand that the URL parameters don't give a perfectly accurate view, but what I see there is pretty similar to what I experience when I randomly receive such a banner.

skews metrics and the filmstrip but doesn't mean anything about the performance of the initial pageload, when the article shows up

I specifically looked at the filmstrip because we have indications that users don't consider the page usable before the banners have finished loading, inter alia because otherwise all sorts of misclicks can happen (see for instance the thread https://lists.wikimedia.org/pipermail/wikimedia-l/2017-September/088547.html ). This specific banner seems to have something special in that before it's done loading it *also* freezes the browser completely, as if there were some extremely CPU-intensive operation.

Nemo_bis renamed this task from 2017 USA banners take 1-2 seconds to load to 2017 USA banners may freeze your browser for 1-2 seconds.Sep 7 2017, 6:32 AM
Gilles added a comment.EditedSep 7 2017, 6:52 AM

There's a difference between actually freezing your browser (the page can't physically be interacted with because the browser is overloaded), and users waiting for things to have settled (banner included) before interacting with the page. Semantics matter here, is the symptom the latter only or both?

Pcoombe added a subscriber: Pcoombe.Sep 7 2017, 5:33 PM
Krinkle updated the task description. (Show Details)Sep 12 2017, 9:04 AM
Gilles moved this task from Inbox to Radar on the Performance-Team board.Sep 12 2017, 9:12 AM
Gilles edited projects, added Performance-Team (Radar); removed Performance-Team.
K4-713 added a subscriber: K4-713.Sep 12 2017, 7:35 PM
Krinkle removed a subscriber: Krinkle.May 6 2019, 11:33 PM