First meaningful paint?

443 views
Skip to first unread message

Kunihiko Sakamoto

unread,
Feb 1, 2016, 12:00:55 AM2/1/16
to Chromium Loading Performance
Hi loading-dev,

Last quarter I added a set of simple first-X-paint metrics. Now I'm thinking about "first meaningful paint" - something closer to user-perceived page load time.

To study how to define such a metric, I created a catalog page of WPT screenshots:

I'm wondering what a useful definition of first-meaningful paint would be. It seems not as obvious as I thought...

For example, loading of wordpress.com (the first filmstrip of the above catalog) progresses like the following:
  • 2.758s: First contentful paint (logo)
  • 2.953s: Significant part of the background image is visible
  • 3.201s: Some text become visible
  • 3.434s: The background image completes
  • 3.618s: All fonts ready
Which is first meaningful paint? I think 2.953s (user sees something nontrivial) or 3.618s (button text becomes visible -> user is able to interact with the page) could be, but others may think differently.

Whatever the definition, we'll need some programmatic approximation of the metric, to make it measureable.

Random ideas that could be (components of) first-meaningful-paint criteria:
  • Painted area
    • Size of painted image, number of characters painted
  • Key user moments
    • All text is visible
    • Input form is usable
  • Last layout jank
Any ideas / comments will be appreciated.
Thanks!

Patrick Meenan

unread,
Feb 1, 2016, 8:44:52 AM2/1/16
to Kunihiko Sakamoto, Chromium Loading Performance
For me, most of the pages only become meaningful when the text is available.  How about something like defaulting it to the first visible text paint time and if no text is drawn then fall back to the first image paint (and largely ignore backgrounds)?  Unfortunately in the fallback case the decision would only be able to be made after the page finished loading (to know that no text painted) but I think that would work well enough in the general case.

It wouldn't be perfect because there's no guarantee that the first text painted is meaningful either but I think it handles the general case well.

The YouTube experience (and gmail) where there is a loading progress indicator first is more complicated though.  It would be great if we could ignore the loading progress indicator and only count the actual content but I can't think of a good way to do that.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.
To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAO5vZCiacbe%2BhahYhb-BHZjdaA17%2B5Zetc5e9UL0-PP7zP%2BVnw%40mail.gmail.com.

Ilya Grigorik

unread,
Feb 1, 2016, 11:54:27 AM2/1/16
to Patrick Meenan, Kunihiko Sakamoto, Chromium Loading Performance
+1 to (any) visible text. It has its edge cases, but it's a reasonable user-utility proxy + reasonably sane (stable) to reason about, both as a site and browser developer.

Kunihiko Sakamoto

unread,
Feb 2, 2016, 4:17:32 AM2/2/16
to Ilya Grigorik, Patrick Meenan, Kunihiko Sakamoto, Chromium Loading Performance
Thanks -- sounds like first-text-paint is a good starting point.

I've added "Load/Save selections" buttons to the catalog page (https://goo.gl/UIkVpg). You can see the timing of first-text-paint by loading attached json file using the top-right "Load Selections" button.

I can see two patterns where naive firstTextPaint doesn't work (heuristics needed):

Btw, currently my catalog only have domain top pages (from Alexa top 200 sites). Is there any recommendation for an URL list that includes leaf pages too?

FirstTextPaint.json

Charles Harrison

unread,
Feb 2, 2016, 9:17:38 AM2/2/16
to Kunihiko Sakamoto, Ilya Grigorik, Patrick Meenan, Chromium Loading Performance

Kunihiko Sakamoto

unread,
Feb 3, 2016, 4:10:14 AM2/3/16
to Charles Harrison, Kunihiko Sakamoto, Ilya Grigorik, Patrick Meenan, Chromium Loading Performance

Kunihiko Sakamoto

unread,
Feb 8, 2016, 2:46:14 AM2/8/16
to Kunihiko Sakamoto, Charles Harrison, Ilya Grigorik, Patrick Meenan, Chromium Loading Performance
I did a manual evaluation for "meaningful-ness" of FirstTextPaint using this data.


Summary:
  • 146 (73%) - Good, FirstTextPaint was meaningful.
  • 8 (4%) - Splash screen / spinner
    • I'm not sure whether we should exclude these from first meaningful paint. Page author chose to load contents in background.
  • 29 (15%) - Page header only
    • Detectable by page height?
  • 11 (6%) - Not meaningful, (almost) background only
    • In most cases, first text was not visible, i.e. FirstTextPaint was not working well.
  • 5 (3%) - N/A (FirstTextPaint not recorded for some reason)
Patrick's suggestion was to use FirstImagePaint if no text is drawn, but within these 199 pages there's no such case.

Kinuko Yasuda

unread,
Feb 8, 2016, 9:39:12 AM2/8/16
to Kunihiko Sakamoto, Charles Harrison, Ilya Grigorik, Patrick Meenan, Chromium Loading Performance
Thanks for looking into this.

On Mon, Feb 8, 2016 at 4:45 PM, Kunihiko Sakamoto <ksak...@chromium.org> wrote:
I did a manual evaluation for "meaningful-ness" of FirstTextPaint using this data.

2016-02-03 18:09 GMT+09:00 Kunihiko Sakamoto <ksak...@chromium.org>:

Summary:
  • 146 (73%) - Good, FirstTextPaint was meaningful.
  • 8 (4%) - Splash screen / spinner
    • I'm not sure whether we should exclude these from first meaningful paint. Page author chose to load contents in background.
Looking into these questions I have an unclear feeling that we don't have a good definition / base agreement of what kind of new metric(s) we want to add/define for measuring real-world loading performance yet.

For this particular one I can imagine one could argue either this is meaningful paint or not, while I can also imagine that having the time-to-splash-text/spinner could be useful regardless of whether it's considered 'meaningful' or not.  But it alone wouldn't tell all what we might want to know--- showing splash text/spinner would probably improve user experience some sense but if loading the body contents takes forever after that it'd still make the overall loading experience bad.  Then how should we track those timings?  Might we want to record multiple timings or could somehow combine them?  If we want to record multiple values/timings (I think we'll likely end up doing this) how many we'd need to add (I think we want them to be distinct / minimum)?

I think maybe you/we could first build some hypotheses (with rationals) on what / how many values we'd want to add, and then discuss how we could approximate the timings if we were to add them as UMA/RUM-type values?  (I'd also want existing metrics to be reviewed in that context too-- why they're not enough or how many we want to keep etc)

  • 29 (15%) - Page header only
    • Detectable by page height?
  • 11 (6%) - Not meaningful, (almost) background only
    • In most cases, first text was not visible, i.e. FirstTextPaint was not working well.
I think for this one many have mentioned that we'd want to only include the visible text paints.  Would it be easy to fix this?  Would we need some heuristics here?

Bryan McQuade

unread,
Feb 8, 2016, 11:19:36 AM2/8/16
to Kinuko Yasuda, Kunihiko Sakamoto, Charles Harrison, Ilya Grigorik, Patrick Meenan, Chromium Loading Performance
Thank you Kunihiko for this great analysis. Would it be possible for you to put together a doc that has ~5 representative screenshots for each of the example cases you cite (first paint screenshot vs first meaningful paint screenshot vs final page screenshot)? That would help us to quickly scan and understand the challenges with each of these cases?

I agree with Kinuko that it may be hard to detect whether a spinner counts as meaningful. Assuming that detecting this will be very difficult, I think we can mostly ignore that case for now and keep it in mind for future work. That may also be a case that we decide is out of scope for first meaningful paint and is instead better covered by speed index.

I do wonder if we can detect some other cases, e.g. header only or background only, by looking at the dom/layout tree at the time of the paint and determining that a significant amount of content is not yet paintable due to e.g. pending fonts being loaded. For those cases, I think it may be worth investing further. How much work would it be for us to determine that contentful content in the DOM is not yet paintable due to pending resource loads? I imagine this information must already be computed during the layout phase - perhaps we could piggyback on those computations? Might be good to talk to the layout or paint folks to get their guidance on when we compute this information and whether it's recorded for us to look at when we're deciding whether first meaningful paint has happened yet.

-bryan



Bryan McQuade

unread,
Feb 11, 2016, 12:45:56 PM2/11/16
to Kinuko Yasuda, Kunihiko Sakamoto, be...@google.com, Charles Harrison, Ilya Grigorik, Patrick Meenan, Chromium Loading Performance
+Ben Greenstein who is looking for a first meaningful paint metric.

Kunihiko Sakamoto

unread,
Feb 16, 2016, 2:18:31 AM2/16/16
to Bryan McQuade, Kinuko Yasuda, Kunihiko Sakamoto, be...@google.com, Charles Harrison, Ilya Grigorik, Patrick Meenan, Chromium Loading Performance
Thanks Kinuko and Bryan.

Comments and suggestions welcome!

Ben Greenstein

unread,
Feb 16, 2016, 4:07:22 PM2/16/16
to Kunihiko Sakamoto, Bryan McQuade, Kinuko Yasuda, Charles Harrison, Ilya Grigorik, Patrick Meenan, Chromium Loading Performance
This sounds great! Would a first contentful paint metric that is based on first text wait until there are no more reflows of that first text? I'm interested in when the critical content (maybe just the text) on a page is available to the user, and I worry that until the pixels stabilize the content might not really available to be consumed even if it has been painted. Ideally, if a page has text, a bunch of images, and a bunch of ads, a first contentful paint metric would tell me when the text is stable and can be consumed. This may depend on images being loaded in to stabilize the layout, and might even depend on ads appearing.

Kenji Baheux

unread,
Feb 16, 2016, 6:30:12 PM2/16/16
to Ben Greenstein, Kunihiko Sakamoto, Bryan McQuade, Kinuko Yasuda, Charles Harrison, Ilya Grigorik, Patrick Meenan, Chromium Loading Performance

My take is that we need metrics for the following key user moments:

1. “is it happening?” (i.e. time to first paint)

2. “is it useful?” (i.e. time to first meaningful paint)

3.  “is it usable?” (i.e. time to stable layout)

Beyond loading:
4. "is it delightful?" (i.e. metrics for the RAI of RAIL)


Jonathan Garbee

unread,
Feb 16, 2016, 6:43:47 PM2/16/16
to Chromium Loading Performance
Thinking from the perspective of a user (as RAIL advises) first meaningful paint is certainly *not* a loading spinner. It is the content, or at least the applications layout being shown.

I think Kenji presented a good flow to think by. However, I'd put Usable before Useful with the examples provided. A stable layout is where the site becomes useful, since you aren't worried about reflow happening while trying to scroll and having content jump around. Then useful is when the content comes in to fill in the layout. 

Kenji Baheux

unread,
Feb 16, 2016, 6:57:56 PM2/16/16
to Jonathan Garbee, Chromium Loading Performance
I agree with Jonathan that a spinner is not meaningful and that eventually it would be good to address these cases as well. In the meantime, a metric that works for most cases is already a major improvement over what we've been using so far.

Regarding the ordering of useful and usable, the reason I have them in that order is because as a user I can't know beforehand if a website is usable by the time it's useful: I would start reading and scrolling as soon as I see something useful on the screen, only to later realize that the site isn't quite yet usable (e.g. a reflow triggers while reading).

Paul Irish

unread,
Feb 18, 2016, 9:36:36 PM2/18/16
to Kenji Baheux, Ben Greenstein, Kunihiko Sakamoto, Bryan McQuade, Kinuko Yasuda, Charles Harrison, Ilya Grigorik, Patrick Meenan, Chromium Loading Performance
Kenji, I really like this user moment breakdown. 

1. “is it happening?” (i.e. time to first paint)

Splash screen, loading indicator, basically some feedback that communicates your navigation has started.  

2. “is it useful?” (i.e. time to first meaningful paint)

I agree with the earlier definitions on the thread. Generally focusing on the paints of above-the-fold body & headline text. And sometimes a large hero image is primary content.

3.  “is it usable?” (i.e. time to stable layout)

This one captures the key aspect of "the page feels ready to interact with".  
There's probably a few technical considerations to identify this moment:
  • User-agent loading indicator is probably done
  • Any almost-primary images/text has been painted.
  • Above-the-fold layout has stabilized

But, I suppose there's a bit more on layout stability that isn't captured here.…

Ideally, there is very little change in the layout of links and actionable elements between the user moments 2 and 3. Worst case: every click target completely moves and is replaced with a different click target that navigates somewhere else.

So there may be a metric around layout stability that timestamps can't offer. Something that captures the movement of the layout during the entire load--from moment 2 to moment 3 to ten seconds after, when the page should be totally done.

I had just started a thread on lighthouse-core exploring if the Speed Index metric takes this into account. If not, I can imagine a standalone metric for layout stability to complement these others.



All-in-all, I do like breaking apart loading into these 3 key user moments. Then adding in measures of layout stability and main thread availability complete the picture for me.





Colin Blundell

unread,
Feb 19, 2016, 4:51:00 AM2/19/16
to Paul Irish, Kenji Baheux, Ben Greenstein, Kunihiko Sakamoto, Bryan McQuade, Kinuko Yasuda, Charles Harrison, Ilya Grigorik, Patrick Meenan, Chromium Loading Performance

A related question: Is there a meaningful distinction between "is it usable?" and "is it complete?" Kenji's categorization (which I find extremely insightful) is not explicitly tracking the latter.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.
To post to this group, send email to loadi...@chromium.org.

Nat Duca

unread,
Feb 19, 2016, 2:52:40 PM2/19/16
to Colin Blundell, Paul Irish, Kenji Baheux, Ben Greenstein, Kunihiko Sakamoto, Bryan McQuade, Kinuko Yasuda, Charles Harrison, Ilya Grigorik, Patrick Meenan, Chromium Loading Performance, Yi Zhang
+yi who has been poking at this space too

On Fri, Feb 19, 2016 at 1:50 AM, Colin Blundell <blun...@chromium.org> wrote:

A related question: Is there a meaningful distinction between "is it usable?" and "is it complete?" Kenji's categorization (which I find extremely insightful) is not explicitly tracking the latter.
On Fri, Feb 19, 2016 at 3:36 AM Paul Irish <paul...@chromium.org> wrote:
Kenji, I really like this user moment breakdown. 

1. “is it happening?” (i.e. time to first paint)

Splash screen, loading indicator, basically some feedback that communicates your navigation has started.  

2. “is it useful?” (i.e. time to first meaningful paint)

I agree with the earlier definitions on the thread. Generally focusing on the paints of above-the-fold body & headline text. And sometimes a large hero image is primary content.

3.  “is it usable?” (i.e. time to stable layout)

This one captures the key aspect of "the page feels ready to interact with".  
There's probably a few technical considerations to identify this moment:
  • User-agent loading indicator is probably done
  • Any almost-primary images/text has been painted.
  • Above-the-fold layout has stabilized

But, I suppose there's a bit more on layout stability that isn't captured here.…

Ideally, there is very little change in the layout of links and actionable elements between the user moments 2 and 3. Worst case: every click target completely moves and is replaced with a different click target that navigates somewhere else.

So there may be a metric around layout stability that timestamps can't offer. Something that captures the movement of the layout during the entire load--from moment 2 to moment 3 to ten seconds after, when the page should be totally done.

I had just started a thread on lighthouse-core exploring if the Speed Index metric takes this into account. If not, I can imagine a standalone metric for layout stability to complement these others.



All-in-all, I do like breaking apart loading into these 3 key user moments. Then adding in measures of layout stability and main thread availability complete the picture for me.





--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

Kunihiko Sakamoto

unread,
Feb 24, 2016, 2:40:43 AM2/24/16
to Nat Duca, Colin Blundell, Paul Irish, Kenji Baheux, Ben Greenstein, Kunihiko Sakamoto, Bryan McQuade, Kinuko Yasuda, Charles Harrison, Ilya Grigorik, Patrick Meenan, Chromium Loading Performance, Yi Zhang
Thanks all for the comments.
I agree we should focus on these three key metrics.

The moment 1 is what we already have as time-to-first-paint.

The moment 2 is basically what I was trying to define in my document. It should detect paints of above-the-fold body & headline text (sometimes image).

Probably it should take into account the number of painted characters (per total characters in final state?), so that trivial text like this will be ignored. Of course it shouldn't count text painted out of initial viewport, or painted below the splash screen layer. I'll ask for a advice from paint team.

The moment 3 is a layout-based metric. There's some existing layout-related timings in WebMeaningfulLayout, although what this captures is somewhat different from what we want.

As Paul mentioned we may end up with a non-timestamp metric, but let's start with very simple one. A first-order approximation would be the time of the last layout change before WPT visual complete. I'll test it in some pages and see how well that works / how can it be improved.


2016-02-20 4:52 GMT+09:00 Nat Duca <nd...@chromium.org>:
+yi who has been poking at this space too
On Fri, Feb 19, 2016 at 1:50 AM, Colin Blundell <blun...@chromium.org> wrote:

A related question: Is there a meaningful distinction between "is it usable?" and "is it complete?" Kenji's categorization (which I find extremely insightful) is not explicitly tracking the latter.
On Fri, Feb 19, 2016 at 3:36 AM Paul Irish <paul...@chromium.org> wrote:
Kenji, I really like this user moment breakdown. 

1. “is it happening?” (i.e. time to first paint)

Splash screen, loading indicator, basically some feedback that communicates your navigation has started.  

2. “is it useful?” (i.e. time to first meaningful paint)

I agree with the earlier definitions on the thread. Generally focusing on the paints of above-the-fold body & headline text. And sometimes a large hero image is primary content.

3.  “is it usable?” (i.e. time to stable layout)

This one captures the key aspect of "the page feels ready to interact with".  
There's probably a few technical considerations to identify this moment:
  • User-agent loading indicator is probably done
  • Any almost-primary images/text has been painted.
  • Above-the-fold layout has stabilized

But, I suppose there's a bit more on layout stability that isn't captured here.…

Ideally, there is very little change in the layout of links and actionable elements between the user moments 2 and 3. Worst case: every click target completely moves and is replaced with a different click target that navigates somewhere else.

So there may be a metric around layout stability that timestamps can't offer. Something that captures the movement of the layout during the entire load--from moment 2 to moment 3 to ten seconds after, when the page should be totally done.

I had just started a thread on lighthouse-core exploring if the Speed Index metric takes this into account. If not, I can imagine a standalone metric for layout stability to complement these others.



All-in-all, I do like breaking apart loading into these 3 key user moments. Then adding in measures of layout stability and main thread availability complete the picture for me.





--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.
Reply all
Reply to author
Forward
0 new messages