1652816 - Preload fonts only after DOMContentLoaded

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, enhancement, P3)

Description

[Honza Bambas (:mayhemer)]

There is a regression on a cnn website. Comparing full logs in logan's network diagnostic overview suggested that we are preloading fonts too soon and delay DOMContentLoaded. This is an experiemntal bug to delay font preload to happen after DOMContentLoaded. It decreases the refgression significantly but doesn't affect firstPaint.

Comment 1

[Honza Bambas (:mayhemer)]

Attachment: Bug 1652816 - Start preloading fonts only after DOMContentLoaded, r=heycam

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

What is the regression we're trying to fix here? Which metric?

Comment 3

[Emilio Cobos Álvarez (:emilio)]

How do fonts block DOMContentLoaded?

Also, is this the DOMContentFlushed one? If so there's something with that metric that I need to investigate: https://bugzilla.mozilla.org/show_bug.cgi?id=1648003#c7

Comment 4

[Honza Bambas (:mayhemer)]

The metric that regresses is DOMContentLoaded. With preload turned on I'm locally able to reproduce it with browsertime on the cnn website. Looking at logs shows that we are loading the fonts too soon and the main thread (possibly both processes) flood and network utilization slow down the load and parsing of the main document, including sync script load and run. This fix lowers the regression significantly on that page. I don't understand the exact cause of the regression, the tools are not sufficient to find out. But experimentally this helps and doesn't lower time to first paint.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Part of the issue is that font loads being slow don't necessarily lower first paint. But they may show a flash of unstyled text, which is pretty ugly.

Comment 6

[Honza Bambas (:mayhemer)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)

Part of the issue is that font loads being slow don't necessarily lower first paint. But they may show a flash of unstyled text, which is pretty ugly.

I know. I came to conclusion that the source of the regressions are fonts by specifically disabling only font preload. Wiggling with priorities and class-of-service didn't change anything, so timing to start the load was likely the problem. I gave a test build with this patch to acreskey for retesting, let's see how this will affect also other sites.

BTW, with unpatched preload on, the fonts don't load before the first paint anyway.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

DOMContentLoaded timing isn't particularly important. I wonder how font loading affects to visual metrics.

Comment 8

[Cameron McCormack (:heycam)]

It's hard for me to say whether this is the right change. You may have a large document that takes a while to download, and before it has finished downloading, you'll render the content you do have already. It would be better to render that with the correct font if possible. If preloading the font earlier means DOMContentLoaded is later, but the amount of content within the viewport isn't affected, then it seems like it's the right thing to do to minimize any time spent rendering that initial content with the wrong font. Unless the font download delays the viewport's content from downloading sooner.

This is all balancing the weight of the fonts and the HTML download and the user's network bandwidth. Focusing on the visual results of the change seems like the right thing to do.

Comment 9

[Honza Bambas (:mayhemer)]

According results from acreskey with this patch and comments on this bug we are not going to land this.