Minutes [was: [1/18/17] webperf group call @ 10AM PST]

Hi,

The minutes of this week's webperf group call are available:
https://www.w3.org/2017/01/18-webperf-minutes.html <https://www.w3.org/2017/01/18-webperf-minutes.html>

• Topics
 • Nav Timing
 • Performance Timeline
 • Long Tasks V1 progress updates...
 • FP + FCP update
• Summary of Action Items
 • get feedback from Soasta and other folks about use of name field + checking value "document", revisit on the next call
 • Yoav to update PL issue#64
 • Ilya to check-in with plh@ on charter + process
 • shubhie to update the FP spec with non-normative note recommending the point in time we want to capture
• Summary of Resolutions
 • make the change for NT issue#50

Plain text version:
==============

WebPerf Group Call

18 Jan 2017

See also: IRC log

Attendees

Present
igrigorik, Nathan, Shubhie, Todd, Nolan, Yoav, Xiaoqian, Nic
Regrets
Chair
igrigorik
Scribe
igrigorik

Contents

Nav Timing

https://github.com/w3c/navigation-timing/issues/50#issuecomment-268919388

shubhie: we want to ship in M58, should we make the change?

n8s: yeah, this is critical for us

todd: we do the proposed approach for NT2, not RT2

yoav: for RT2 it could break some tests?
... let's separate the discussions

todd: NT2 already functions this way in IE11/Edge. lgtm

yoav, n8s, shubhie: lgtm

for RT2, can we make the same update?

yoav: practical concerns around non RT tests that may break? We need to change the code and see what breaks (if anything)
... also, could code rely on entry being added at resource onload?

we'll draft PR for RT2 and discuss implications.. e.g. do we need a new attribute to indicate done?

https://github.com/w3c/navigation-timing/issues/59

todd: conceptually makes sense... concern is if there is any existing code querying for "document". Question: is it worth breaking a legacy browser to add name in URL field.. to support the future?
... we could add new field, as an option

yoav: do we have any data? todd: nothign on this particular string
... only use case I can think of is "getEntriesByName('document')"

n8s: it would be useful to have the URL

todd: let's check w/ Soasta and other folks about use of name field + checking value "document"

AI: get feedback, revisit on the next call.

Performance Timeline

https://github.com/w3c/performance-timeline/issues/64

yoav: current implementation in Chrome throws an exception if you try to register an observer for unsupported types, whereas spec says ignore; for getEntries they're ignored in both spec and implementation

todd: ... this could be good time to change shape of PerfObserver, if we wanted
... is there a way to check if the type exists?
... if the type is around, browser supports it. perhaps it's already doable?

AI: Yoav, will update the issue.

Long Tasks V1 progress updates...

shubhie: iterating in Chrome, in good shape overall.
... 1ms clamping + 50ms floor on the task got positive feedback from security review
... Dominic is helping out with the spec

igrigorik: should we consider graduating LT from WICG to webperf

todd: sgtm, looking forward to implement.. need to review latest updates.
... I'll review later today on WICG.

xiaoqian: as long as our charter is good, we don't need to recharter

AI: check-in with plh@ on charter + process

shubie: we got good feedback from ads folks.. who found it useful.
... also, YouTube and FB are playgn with it
... attribution is of interest to everyone.

-- FP + FCP update --

https://docs.google.com/document/d/1XVP9jaZT7acQtK5O6vO-mIz31i5iB-pZn1S41_YP6p0/edit#

shubhie: should capture all the phases between main thread vs compositor, etc.
... looking at higher percentiles, we should consider up to the second step (time to composite + rasterization), ignore the rest. GPU stuff is unspeccable and too small to justify the effort.

todd: this matches my intuition for what I expect to see in Edge

shubhie: unclear on how to spec.. as HTML does not even talk about compositor.

todd: exposing two numbers could expose differences between structure of graphics/layers vs blocking main thread

yoav: that would be interesting in ~frame-timing case, but for first paint vs first-contentful-paint .. maybe not so much?

duration should be the most accurate, we could expose additional attributes

AI: update spec with non-normative note recommending the point in time we want to capture
==============

Thanks.

-xiaoqian

> On 19 Jan 2017, at 12:03 AM, Yoav Weiss <yoav@yoav.ws> wrote:
> 
> If there's time, there's also a fresh one: Tighter definition of "load was successful" <https://github.com/w3c/preload/issues/83>
> On Wed, Jan 18, 2017 at 2:15 AM Ilya Grigorik <igrigorik@google.com <mailto:igrigorik@google.com>> wrote:
> Resource Timing L2
> Increase limit of 150 for PerformanceEntrys? <https://github.com/w3c/resource-timing/issues/89>
> 
> On Wed, Jan 18, 2017 at 1:43 AM, Ilya Grigorik <igrigorik@google.com <mailto:igrigorik@google.com>> wrote:
> Hangout: https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg <https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg>
> 
> --- Agenda:
> Nav Timing L2
> Report URL in "name" attribute instead of "document"? <https://github.com/w3c/navigation-timing/issues/59>
> Data bias issues due to deferring reporting of all nav timing metrics to the load event <https://github.com/w3c/navigation-timing/issues/50#issuecomment-268919388> 
> Performance Timeline
> L2: Lack of feature detection option for new entry types <https://github.com/w3c/performance-timeline/issues/64>
> L3: Ability to observe past set of performance entries <https://github.com/w3c/performance-timeline/issues/56#issuecomment-268922807>
> Long Tasks V1 progress updates
> FP & FCP data analysis results <https://docs.google.com/document/d/1XVP9jaZT7acQtK5O6vO-mIz31i5iB-pZn1S41_YP6p0/edit#> comparing paint time with subsequent timestamps
> Resource Timing L1 
> From PR request review: "It appears that Timing-Allow-Origin was not tested. I think the implementation report is incomplete without tests for that feature."
> requestIdleCallback L1 CR <https://github.com/w3c/requestidlecallback/issues/48> check-in..
>