1570090 - Investigate fast first paints

Status: NEW

(Core :: Performance: Navigation, enhancement, P2)

Description

[Bas Schouten (:bas.schouten)]

Our data indicates Firefox is currently doing its first paints slower than Chrome. Even if subsequent visual data comes in faster this does hurt us on SpeedIndex and the FirstVisualPaint metric. We can probably force fast early paints in some way, but the impact on the critical pageload path should me minimized. Once we have a pref for this we will be in a better position for UX to determine if this actually contributes to a better perception of the pageload performance. Possibly with different behavior based on whether a page is loaded from the URL bar or a clicked link.

Comment 1

[Leonie Philine]

Hi!

Once we have a pref for this we will be in a better position for UX to determine if this actually contributes to a better perception of the pageload performance.

As a user / web developer (not a gecko/servo developer), I found the difference between Gecko and Blink so big that I started profiling and ended up searching for "gecko first paint" on bugzilla.

Working on https://www.cobytes.com/ I made sure to lazy-load lots of functionality to gain an early first paint, which works nicely on Chromium Version 83.0.4103.61 (openSUSE Build) (64-bit). FP, FCP, FMP and LCP all happen before the lazy loading of additional functionality (matomo, lazysizes, hamburger menu and interactive elements on the page) are initialized.
=> chromium-profile.json
tested url: https://www.cobytes.com/nl/diensten-mogelijkheden

In Firefox, I was surprised to find that Gecko ran all the lazy-loaded stuff first and then decided to paint after these were executed. This moved FP far behind the DCL and Load events. During development, I had intentionally chosen to lazy-load not already after domcontentloaded but only after the load event, to make sure the initial response is as fast as possible.
=> firefox-profile-1-rendered-after-handling-lazyloaded-assets.json
tested url: https://www.cobytes.com/nl/diensten-mogelijkheden

PS: Testing a different url of the same site, Firefox did render before initializing lazy loaded resources, and right between the DCL event and the load event.
=> firefox-profile-2-rendered-before-handling-lazyloaded-assets.json
tested url: https://www.cobytes.com/nl/

I will attach json profiles and a screenshot of how Blink handles loading, parsing, layout, compositing and rendering of https://www.cobytes.com/nl/diensten-mogelijkheden . The firefox devtools unfortunately did not offer a way to display the data in an easily screenshottable, "everything at a glance" way.

Comment 2

[Leonie Philine]

Attachment: firefox-profile-1-rendered-after-handling-lazyloaded-assets.json

Comment 3

[Leonie Philine]

Attachment: chromium-profile.json.bz2

Comment 4

[Leonie Philine]

Attachment: firefox-profile-2-rendered-before-handling-lazyloaded-assets.json

Comment 5

[Leonie Philine]

Attachment: Screenshot_20200530_150214.png

Comment 6

[Leonie Philine]

Attachment: firefox-profile-1-rendered-after-handling-lazyloaded-assets.png

Comment 7

[Leonie Philine]

https://bugzilla.mozilla.org/show_bug.cgi?id=1641696 seems related.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last months and this bug has priority 'P2'.
:fdoty, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 9

[Suhaib Mujahid [:suhaib]]

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.