Re: NavigationTiming event for initial display

To provide a bit more context here:
- FirstPaint - anything but document background is painted
- FirstContentPaint - any contentful thing (image, text, SVG etc) is
These are not trying to be very smart in terms of capturing just the "right
subset of content". The question is more whether they align well with user
perceived "non-blank" moments. And that is a great question.
The initial results have been somewhat promising, although there is
certainly indication of this being not perfect.
More details in this public doc

On Thu, Jun 23, 2016 at 8:41 AM, Ben Maurer <> wrote:

> Hey,
> Just wanted to share some thoughts here based on our measurement
> experience at Facebook. While the FirstPaint and FirstContentfulPaint
> events are interesting I don't think these reflect the actual loading times
> of non-trivial applications. Many sites load their content incrementally
> and these statistics are unlikely to capture just the right subset of
> content.
> IMHO one of the problems to solve here is that it's impossible to know
> when a specific manipulation to the DOM (such as inserting newsfeed) is
> actually painted to the user. There are absolutely privacy considerations
> here wrt the :visited css functionality. But I think it's possible to
> address a more general problem here.
> -b
> On Thu, Jun 23, 2016 at 8:21 AM, Shubhie Panicker <>
> wrote:
>> We just discussed this at this Wednesday's W3C F2F meeting (great timing
>> :))
>> The general consensus was on moving forward with *FirstPaint* and
>> *FirstContentfulPaint*  (something more than blank screen, such as the
>> top app bar) to start with. Captured in Ilya's meeting notes
>> <> at the bottom under
>> "Milestone 3: Nav Timing"
>> We also discussed "FirstMeaningPaint" (Paul can share pointer), as a
>> future possibility.
>> On Thu, Jun 23, 2016 at 8:12 AM, Bryan McQuade <>
>> wrote:
>>> Thanks for starting this discussion. This has been an area of interest
>>> recently, and I believe there's a desire to expose display-oriented metrics
>>> to the web platform. +Paul Irish <> has been
>>> working on some possible display-oriented metrics and may be able to share
>>> more about this.
>>> We do currently expose a first paint timing
>>> via chrome.loadTimes().firstPaintTime, however chrome.loadTimes() is an
>>> old, non-standard API and we're hoping to standardize some paint/display
>>> timing information and then deprecate chrome.loadTimes().
>>> IIUC IE also exposes a similar performance.timing.msFirstPaint.
>>> So there's no standard APIs available today, but I agree there should
>>> be. Paul can share more about the thinking with progressive web metrics.
>>> On Thu, Jun 23, 2016 at 9:13 AM Stefan Seifert <>
>>> wrote:
>>>> Hi!
>>>> Trying to bring facts into a discussion about the merits and harm of
>>>> using
>>>> Javascript to lazily load images, I've been looking through the
>>>> documentation
>>>> about timing interfaces. While Navigation Timing seems to offer a
>>>> wealth of
>>>> information, the one point that would be most helpful for me is the
>>>> time to
>>>> initial display, i.e. when the browser first displays rendered content.
>>>> This is the time, people try to optimize by using lazy image loaders
>>>> which
>>>> then rob the browser any chance to make a better informed decision
>>>> based on
>>>> all the information it has. The first step in optimization is of course
>>>> creating a reliable and meaningful benchmark. In absence of timing
>>>> information
>>>> offered by the browser (which should be the entity that knows best),
>>>> people
>>>> have to resort to opaque web services claiming to use elaborate camera
>>>> setups
>>>> or even worse - tribal knowledge spread at conferences and in blog
>>>> posts.
>>>> Would it be feasible to add such an event to Navigation Timing or is
>>>> this
>>>> information already available in some form?
>>>> Thanks and regards,
>>>> Stefan Seifert

Received on Thursday, 23 June 2016 18:25:06 UTC