Re: NavigationTiming event for initial display

To loop back here, I've proposed the initial first paint metrics on this
issue on Nav Timing <https://github.com/w3c/navigation-timing/issues/45>.

The proposal is to start with standardizing the following:
- first non-blank paint - this is when anything beyond document background
is painted
- first contentful paint - when some contentful thing (text, image, canvas,
or SVG) is first painted.

Explainer doc is here
<https://docs.google.com/document/d/1kKGZO3qlBBVOSZTf-T8BOMETzk3bY15SC-jsMJWv4IE/edit#>
.
Feedback is welcome.



On Tue, Jun 28, 2016 at 3:24 PM, Ilya Grigorik <igrigorik@google.com> wrote:

> On Thu, Jun 23, 2016 at 8:41 AM, Ben Maurer <ben.maurer@gmail.com> wrote:
>
>> 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.
>
>
> If I can generalize the above: there is no single point in time that can
> meaningfully capture the "loading experience" in a single metric; any
> metric we propose will fail this test. However, if we think about this
> problem as a collection of phases on a timeline... then those same metrics
> *can *reveal a useful picture:
>
> - delta from navigation to first paint
> - delta from first paint to first contentful paint
> - delta from first contentful paint to ...
> - delta from ... to onload (yes, I said onload! :))
>
> Which is to say, I think if we park the idea that any one of these metrics
> is the "holy grail" and instead focus on the various phases, then I think
> we can make progress in this space by identifying a few common phases and
> agreeing on some heuristics for how to automatically capture them in the
> browser. Yes, they won't be perfect, but I think there is still a lot of
> value in exposing these.
>
>
> On Thu, Jun 23, 2016 at 11:53 AM, Ben Maurer <ben.maurer@gmail.com> wrote:
>
>> - If the metric doesn't quite fit your use case this api doesn't give any
>> room for adjustment.
>>
> - it seems easy to inadvertently change what is being measured. For
>> example I could imagine minor tweaks to a loading screen making it count as
>> "contentful" or not contentful.
>>
>
> True, but same can be said of most existing metrics too -- e.g. you can
> trivially tweak your page/response to trigger big changes in various DOM
> metrics exposed via NavTiming. Once again, I think that if we consider all
> of these metrics in a context of different phases, and in relation to each
> other, then we're in a better position - e.g. a change in "contentful
> paint" would improve one delta and regress another, which is still useful
> and meaningful to know.
>
>
>> - in a service worker world first paint is much less meaningful. Your
>> first paint may be rendering data you already have offline like the chrome
>> of your app. But you really care if your app has rendered updated data from
>> the network.
>>
>
> Same is true for non-SW pages, the above does not eliminate the need for
> application-level metrics.
>
>
>> I worry without the site giving more hints as to what is being measured
>> it will be hard to have confidence in these metrics.
>>
>
> These are all valid concerns. I do think different sites would get
> different mileage out of them. However, my hunch is that we could get them
> to be "good enough" for most (experiments Shubhie linked to earlier seem to
> indicate that this is plausible) and as long as we don't fixate on any one
> as the holy grail.. then they still make sense and are worth exploring.
>
> ig
>
>
>
>> On Jun 23, 2016, at 11:24 AM, Shubhie Panicker <panicker@google.com>
>> wrote:
>>
>> To provide a bit more context here:
>> - FirstPaint - anything but document background is painted
>> - FirstContentPaint - any contentful thing (image, text, SVG etc) is
>> painted
>> 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
>> <https://docs.google.com/document/d/1Owfs6arciEnWgT2-8bWCcHdYRIKRKZ0Xj8UtqRx4c3k/edit#>
>>
>>
>>
>> On Thu, Jun 23, 2016 at 8:41 AM, Ben Maurer <ben.maurer@gmail.com> 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 <panicker@google.com>
>>> 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
>>>> <https://www.w3.org/2016/06/WebPerfWGroadmap.html> 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 <bmcquade@google.com>
>>>> 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 <paulirish@google.com> 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 <nine@detonation.org>
>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>