Re: NavigationTiming event for initial display

Awesome doc. It's great that these metrics meet so many use cases. That said I haves few concerns.

- If the metric doesn't quite fit your use case this api doesn't give any room for adjustment.

- 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.

- 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.

I worry without the site giving more hints as to what is being measured it will be hard to have confidence in these metrics.

Sent from my iPhone

> 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
> 
> 
> 
>> 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 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 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
>