Implement First Meaningful Paint metric

[abarre]

I think that adding the First Meaningful Paint metric would be a great addition to start render, speed index and now Time to interactive.

The current implementation on Lighthouse makes sense :

First Meaningful Paint is essentially the paint after which the biggest above-the-fold layout change has happened, and web fonts have loaded.

See the spec to learn more: First Meaningful Paint: A Layout-Based Aproach.

[pmeenan]

FWIW, it is already available for Chrome if you enable timeline capture (though it isn't exposed in the main UI).

You can see it in the filmstrip timings graph and it is exposed as "chromeUserTiming.firstMeaningfulPaint" in the API. The main issue with exposing it in the UI is just figuring out how to add another metric without over-complicating it more than it already is.

[abarre]

Thank you for the feedback.
I don't know how realistic this timing is.
In the linked example, the first meaningful paint timing (721ms) is inferior to the start render timing (1091ms).
It doesn't make sense for me.
In the api :

"chromeUserTiming.firstLayout": 718,
"chromeUserTiming.firstPaint": 721,
"chromeUserTiming.firstTextPaint": 721,
"chromeUserTiming.firstContentfulPaint": 721,
"chromeUserTiming.firstMeaningfulPaint": 721,

In the UI, we see that the start render is correct.

In this example, it's hard to tell if the inconsistency between those metrics comes from the video capture that is too slow or if Chrome thinks that the first paint is 300ms before the real paint at the screen.

[pmeenan]

I'm confident enough in WPT's 100ms intervals to be sure that the bits were not on the screen at 721ms so I expect there's a little bit of slack in there. If I had to guess it would be that the paint kicked off at 721ms but getting things from the raster thread through to the actual screen took ~300ms.

Looking at the timeline it looks like 721ms is right around where the big layout finished but there is a block of time in raster and gpu right after that which is probably the actual getting of the bits to the screen.

Both Lighthouse and WPT just report what Chrome internally measures for FMP so it looks like there is still a bit of work on the algorithm to try and make it more accurate.

[pmeenan]

I sent a note with the details to the Chromium Progressive Web Metrics group. It will probably turn into a Chrome issue/bug but I don't know how deep in the rendering pipeline they are committing to instrument.

[pmeenan]

I verified with the people implementing it that Chrome's current measurement does not include the raster and GPU time (though they are working on it).

[DivineTraube]

Quick question: is there any reason, the "chromeUserTiming" field containing the FMP is available in the public WPT instances but not on the private ones? We are using the latest version and the chromeTimeline is activated.

Any hint would be highly appreciated.

[pmeenan]

Are you running the latest public release from download or the tip of tree from Github? The support was added after the last release was cut so unless you are running something more recent that is likely the cause. I'll be cutting an updated official release this week and moving to a quarterly release schedule to keep them more in sync.

[KevT2017]

After the new version "WebPageTest 17.08" was released, our test agents automatically updated succesfully. We also merched our web server software with the master branch. Unfortunatly the "chromeUserTiming" field is still not available.

Do you have any idea what we're doing wrong?

[pmeenan]

Do you have timeline capture enabled for the tests? If you have trace captured are you specifying explicit categories? If so you may be missing the appropriate categories.

[KevT2017]

The "Capture Dev Tools Timeline" is activated and we do not capture chrome trace.