W3C home > Mailing lists > Public > public-web-perf@w3.org > June 2016

Re: NavigationTiming event for initial display

From: Ben Maurer <ben.maurer@gmail.com>
Date: Thu, 23 Jun 2016 08:41:33 -0700
Message-ID: <CABgOVaL+8HrtLnMjk=cwXCPZXbWLAoDwaFAYj2_J=YO_gRe_Ug@mail.gmail.com>
To: Shubhie Panicker <panicker@google.com>
Cc: Bryan McQuade <bmcquade@google.com>, Stefan Seifert <nine@detonation.org>, public-web-perf <public-web-perf@w3.org>, Paul Irish <paulirish@google.com>
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
>>>
>>>
>>>
>
Received on Thursday, 23 June 2016 15:42:20 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 23 June 2016 15:42:20 UTC