@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.

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.

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?