Re: [11/17/16] webperf group call @ 10AM PST

The record of the 17 November webperf group call is available as 
https://www.w3.org/2016/11/17-webperf-minutes.html.

and in text form below.

------------------------------
WebPerf Group Call

17 Nov 2016

See also: IRC log

Attendees

Present
igrigorik, John, Todd, Nolan, Yoav, Xiaoqian, n8s, NicJansma, Shubhie, plh
Regrets
Chair
igrigorik
Scribe
igrigorik
Contents

 • Topics
 • Summary of Action Items
 • Summary of Resolutions
first up, Perf timeline L2: https://github.com/w3c/performance-timeline/issues/62

todd: I agree.

RESOLUTION: push L2 to CR

next up, User Timing L2: I believe we're good to push to CR, xiaoqian or plh to push it forward

Page Visibility: https://github.com/w3c/page-visibility/pull/27

next up, Resource Timing L2 issues

nexthopprotocol: https://github.com/w3c/resource-timing/pull/78

Todd: there is a use case for devs that want to know what types of caches (e.g. serviceworker); ALPN is, on the other hand, is already crisply defined.. so this may not be the right place

Yoav/Shubhie: there is an intent thread on Blink which has privacy/security feedback and questions.

Nic: we have lots of customers that don't know which protocol is being used, they're really excited about nextHopProtocol.

Yoav: it would be useful to have "customer use cases" doc to help motivate this

scheduling of add/queue: https://github.com/w3c/resource-timing/pull/79

Yoav: one of the tests in webkti implementation was testing whether resource is available at onload. After investigating it, implementations didn't agree...

_ could live either way, but current state of different implementations, is a mess

Todd: "should" is a little weak, ideally we'd have MUST
... "after onload" might be tricky to implement

Yoav: with regards to images and onload, I believe onload is a microtask.. which means that onload can fire before image is visible.

Todd: I'd like to check-in with our guys about what the implications of running add step after onload

definition of responsestart: https://github.com/w3c/resource-timing/issues/63

initiatorType: https://github.com/w3c/resource-timing/issues/69

we don't define fallback value: FF says "other", Chrome reports empty string.

https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-initiatortype

NicJansma: we collapse "other" and "" into same bucket, collapsing in either direction is fine.

plh: "other" seems better as empty string

Todd: our plan was to use "fetch" for fetch and "sendBeacon" for beacon.

rough consensus: "other", add sendbeacon and fetch. AI: investigate custom elements.

For navigation timing, use "navigation”.

------------------------------

> On 16 Nov 2016, at 7:13 AM, Ilya Grigorik <igrigorik@google.com> wrote:
> 
> Note that the call is on Thursday (17th) @ 10AM PST, instead of Wednesday this week. 
> 
> Hangout: https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg <https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg> - please hop on IRC if you're having trouble joining the video chat.
> 
> --- Agenda:
> Transition Performance Timeline L2 to CR?
> https://github.com/w3c/performance-timeline/issues/62 <https://github.com/w3c/performance-timeline/issues/62>
> Followup on User Timing L2 CR
> https://github.com/w3c/user-timing/issues/19 <https://github.com/w3c/user-timing/issues/19>
> Review privacy/security update on Page Visibility L2
> https://github.com/w3c/page-visibility/pull/27 <https://github.com/w3c/page-visibility/pull/27>
> Triage L2-blocking issues for Resource Timing L2:
> nextHopProtocol for cache fetch: https://github.com/w3c/resource-timing/pull/78 <https://github.com/w3c/resource-timing/pull/78>
> scheduling of add/queue steps: https://github.com/w3c/resource-timing/pull/79 <https://github.com/w3c/resource-timing/pull/79>
> definition of responseStart: https://github.com/w3c/resource-timing/issues/63 <https://github.com/w3c/resource-timing/issues/63>
> clarify initiatorType for Fetch/other: https://github.com/w3c/resource-timing/issues/69 <https://github.com/w3c/resource-timing/issues/69>
> related: what should Nav Timing L2 entries report as initiatorType?
> Review "payload limit enforcement via Fetch API" in Beacon API
> https://github.com/w3c/beacon/pull/39 <https://github.com/w3c/beacon/pull/39>
> Review requestIdleCallback tests
> https://github.com/w3c/web-platform-tests/pull/2163 <https://github.com/w3c/web-platform-tests/pull/2163>
> Updates / discussions:
> Naming in Paint API (first paint, first contentful paint - see [1])
> Long Tasks V1 plan
> 
> [1] https://github.com/w3c/charter-webperf/issues/32 <https://github.com/w3c/charter-webperf/issues/32>
>