Re: NavigationTiming event for initial display

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