1533102 - Extra "all black" paint when reloading www.theverge.com (and longer wait time on all-black rendering for normal pageload)

Status: RESOLVED WORKSFORME

(Core :: Performance: General, defect, P3)

Description

[Boris Zbarsky [:bzbarsky]]

At least on Mac, with tracking protection off, if I load http://www.theverge.com I see the viewport paint all black, then paint with content.

Other browsers seem to not have this flash of black. See bug 1516552 comment 20.

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #0)

At least on Mac, with tracking protection off, if I load http://www.theverge.com I see the viewport paint all black, then paint with content.

Other browsers seem to not have this flash of black. See bug 1516552 comment 20.

FWIW, Chrome on Linux gives me "actual results" (all-black paint, and then paint with content). I just tried 4 times in a row (loading theverge.com in a new tab each time), and I saw that flash-of-black behavior every time.

I also get those same results (flash of black before any content paints) from the following browsers that I tested remotely via BrowserStack.com:

• Chrome 72 on Win10
• Edge 18 on Win10
• Safari 12 on Mac Mojave
• Chrome 72 on Mac Mojave

So: I have yet to find a browser that has the expected no-flash-of-black behavior. In other words, from my testing, Firefox's behavior is the same as every other browser's.

bz, do you have any ideas for why you might be seeing better results from other browsers than what I'm seeing?

Comment 2

[Daniel Holbert [:dholbert]]

One observation: if I amend the STR to be "reload theverge.com", then I do see better results from Chrome. I see flash-of-black from Firefox pretty much every time, whereas I only see flash-of-black from Chrome in ~2/15 attempts (testing locally).

(Not sure if that's the explanation for the difference between my results & bz's results -- bz, did you mean "reload" rather than "load"?)

Comment 3

[Boris Zbarsky [:bzbarsky]]

So I just tried this again with Chrome (74 dev on Mac Sierra) and a current nightly.

If I do an uncached load (by clearing the cache) I do see a black paint in Chrome; it's there for about 0.3s before content paints. In Firefox, with tracking protection off and cache cleared, it's closer to 0.5-0.6s, I think.

For a cached load, though, I see a ~.3s black paint in Firefox, but in Chrome usually it's not there at all; when present it's much shorter. Just tested Safari TP and it's more like Firefox here.

Comment 4

[Boris Zbarsky [:bzbarsky]]

So yes, I guess the bit I was seeing in bug 1516552 was around reloading.

Comment 5

[Andrew Overholt [:overholt]]

I'll move this to Core: Performance until we find the time to do a more thorough investigation which will hopefully point us to a better component.

Comment 6

[Markus Stange [:mstange]]

Ok, just to restate the problem this bug is tracking: In Firefox with tracking protection off, reloading theverge.com shows black for a longer time than reloading theverge.com in Chrome.
I can confirm that observation on my Mac. The time between pressing Cmd+R and seeing the post-black painted frame on the screen is about twice as long in Firefox as in Chrome. Here's a Firefox profile where it takes 1.7 seconds: https://perfht.ml/34qzCpx. The time range there is from the command event in the parent process that triggers the reload to the composite that puts the post-black content on the screen.

Comment 7

[Markus Stange [:mstange]]

This was fixed a while ago by tracking protection changes; we now stub out a google tag manager script which, because it didn't load, was causing longer blackness. I can't find the bug which made this change at the moment.

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to Markus Stange [:mstange] from comment #7)

This was fixed a while ago by tracking protection changes; we now stub out a google tag manager script which, because it didn't load, was causing longer blackness. I can't find the bug which made this change at the moment.

That sounds like bug 1516552. This bug here was about timing differences between Firefox w/ Tracking Protection off vs. other browsers (per comment 0 and comment 6), so I don't think it would have been impacted by stubbing?

(Having said that, I haven't retested and it's possible this is indeed WFM at this point; but I think not-for-the-reason-you-stated in comment 7, unless I'm misunderstanding.)

Comment 9

[Daniel Holbert [:dholbert]]

FWIW retrying my steps from comment 2, this does seem to be WFM.

In particular: with tracking protection off ('custom' and unchecking all checkboxes), and with network traffic throttled (sudo wondershaper [eth-interface-name] 200 200) and then reloading The Verge, I'm not visually seeing any fully-black paints. The header image and most of the content remains in-place as the page reloads and never disappears.

(I'll try bz's steps from comment 3 next...)

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to Boris Zbarsky [:bzbarsky] from comment #3)

If I do an uncached load (by clearing the cache) I do see a black paint in Chrome; it's there for about 0.3s before content paints. In Firefox, with tracking protection off and cache cleared, it's closer to 0.5-0.6s, I think.

I can't reproduce these black paints on first pageload, in either Chrome or Firefox. I'm using sudo wondershaper [eth-interface-name] 1000 1000 (1MB down/up) to make things take a bit longer while still loading in a reasonable amount of time (~10 seconds to first-paint). And I've disabled tracking protection (via 'custom'/unchecking-checkboxes), and clearing cache and then opening a new tab with The Verge.

In both Chrome and Firefox, I see the black-background & page-content paint together atomically in the first paint, as-expected/desired here. This was my observation from several uncached-load attempts. (Before that first paint, the tab is just showing a default browser-theme background-color, which in my case is a grayish color for Chrome and white for Firefox.)

Comment 11

[Daniel Holbert [:dholbert]]

So it seems like WFM is the correct resolution, though possibly not for the reason in comment 7, but rather via other changes on our end and/or The Verge's end.

Comment 12

[Markus Stange [:mstange]]

Thank you, Daniel!