RE: Minutes [was: Re: call for agenda: design call on 05/31 @ 11AM PST]

Ryosuke,
Summer scheduling has always been a bit tricky.

June 11-15 is Fluent so we blocked that week: https://conferences.oreilly.com/fluent 
Yoav is not available June 18-22 except on June 18 which is our preliminary scheduled call at 11 AM PST. Nic/Yoav are the active Resource Timing editors which has the largest number of issues so they are critical for Triage meetings.
The next Design meeting will be scheduled ~2 weeks out from that call by Ilya.

I'll put together an early agenda by ~6/6 and send it out so you can review and provide remote feedback for the Triage discussion. Is that a fair compromise?

-Todd

-----Original Message-----
From: rniwa@apple.com <rniwa@apple.com> 
Sent: Monday, June 4, 2018 8:28 PM
To: Xiaoqian Wu <xiaoqian@w3.org>; Ilya Grigorik <igrigorik@google.com>
Cc: public-web-perf <public-web-perf@w3.org>
Subject: Re: Minutes [was: Re: call for agenda: design call on 05/31 @ 11AM PST]

Hi,

Sorry for the missing this call; I had a conflicting appointment.

Can we schedule the next meeting before/on 13th or after 25th?  I’ll be traveling on the week of June 18th, and I’d hate to miss two meetings in row.

- R. Niwa

> On Jun 1, 2018, at 3:22 AM, Xiaoqian Wu <xiaoqian@w3.org> wrote:
> 
> The record of this week's call is available as 
> https://www.w3.org/2018/05/31-webperf-minutes.html

> 
> also in plain text as
> 
> WebPerf Group Call
> 31 May 2018
> Attendees
> Present
> Addy, Ilya, Dom, Nic, Charles, Todd, Yoav, Garrett, Panagiotis, 
> Philippe, Nolan, xiaoqian, Tim, Nicolas Regrets Chair igrigorik Scribe 
> igrigorik Contents Topics Priority Hints Event Timing: 
> https://github.com/wicg/event-timing

> charter: 
> https://docs.google.com/document/d/1Zx2orxWQhjN7fsIfrR2EHVhVzIanppKIya

> qewrFJIFM/edit#
> Summary of Action Items
> Summary of Resolutions
> Agenda for today's call: 
> https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B

> 4q8Q46LMM/edit?pli=1#heading=h.c7x3glbx3g3m
> 
> Priority Hints
> Addy + DOM: https://github.com/WICG/priority-hints

> 
> Addy: exposes new attribute "importance" to enable authors to lower or 
> raise fetch priority of resources ... one example today is an image 
> carousel where you have multiple resources: browsers have heuristics 
> for fetching different resources, but they do not have enough 
> information to prioritize based on position, etc ... with priority hints (PR), authors could annotate those resources - e.g. <img src=.. priority="low"> for resources at the end of the stack ... saw this in action on recent Doodle site we built for I/O where carousel images were competing each other for bandwidth, delaying display of visible images ... another use case is reducing BW contention for 3P resources — e.g. non-critical widgets, etc.
> ... we have preload that's ~kinda of a signal for raising priority, 
> but PR provides an explicit signal and also allows authors to lower 
> priority ... can also be applied to preload itself, e.g. <link rel=preload priority=low> for an async stylesheet ... in addition to declarative approach, we'd like to surface this as a parameter on Fetch — e.g. for non-critical API requests, etc.
> ... ~ fetch('/path', { importance: low})...
> 
> Dom: working on Chromium implementation..
> ... we're exploring iframes and fetch right now ... fetch is higher 
> priority right now ... one thing we found challenging so far is 
> enticing examples ... largest wins so far are around lowering priority 
> to minimize contention ... (bandwidth contention)
> 
> yoav: there's some gotchas for 3P contention use cases where you rely 
> on different connections, because even low-pri request on standalone 
> connection is still a high-pri request on that connection ... this is 
> a good building block, but we'll probably need more work in this space
> 
> dom: iframes: we're investigating now what priority this means for 
> subresource requests ... testing is tricky for this, we can ask the 
> internals of Chrome for what priority is, but for WPT it's mostly 
> feature detection ... we're landing some CLs so you can play with this 
> soon in Chrome Canary
> 
> panagiotis: I'll gather feedback from our folks (Moz)
> 
> todd: I'd love to see this defined through Fetch primitives
> 
> yoav: do we need to solve the "auto" definition as part of this problem?
> 
> (we should distinguish "auto", which is cross-UA agreement; vs 
> relative adjustment within a class)
> 
> todd: within class seems speccable
> 
> Ali + Angela on edge side (networking team)
> 
> ai's: make relative importance more prominent in the spec changes; 
> followup with Edge networking + fetch folks
> 
> ----------
> 
> Event Timing: https://github.com/wicg/event-timing

> Tim: goal is to provide metric on latency of response of user input 
> ... right now you can do some of this via event listeners + 
> timestamps, but they're not ergonomic and don't allow you to measure 
> input before you can register listeners
> 
> e.g. we have data showing that first input events are 4x slower than 
> later events
> 
> scribe: we now have a definition of events we want to listen to 
> (probably) ... for events that take >50ms to process, expose name + 
> start and end times ... end time is next execution of event loop ... 
> speccing default actions is very complicated, so we've pivoted to time 
> to next paint ... we can polyfil this today: empty iframe and inject 
> some content ... feedback security & privacy: rounding to 8ms avoids 
> any new exposure ... raf gives you a very similar signal ... any 
> thoughts on use of paint time? specifically, from a security / privacy perspective.
> 
> todd: I don't anticipate a hard "no"
> 
> panagiotis: ditto, quantization should help but we should review on 
> our end
> 
> plh: polyfill?
> 
> tim: it works, but it's ugly and it doesn't allow for early input use 
> case
> 
> plh: right, but you can use this as existence proof in the platform
> 
> tim: another addition is exposing count of each type — e.g. 
> performance.eventCount as denominator so you can compute
> 
> nic: this is useful as it means you don't have to subscribe to all 
> events to get a relative baseline
> 
> tim: we also included ~FID definition in the spec. same fields, only 
> difference is removing the 50ms threshold ... given the slow first events (4x), I think it's worth incentivizing developers to pay more careful attention to this.
> 
> yoav+tim: 50ms threshold, would be nice to be able to customize that
> 
> todd: agree, we gave similar feedback for LT ... we had feedback from 
> customers where current threshold is too low; they have too many 
> reports
> 
> nic: we're aggregating LT in SOASTA, still working on aggregation + 
> presentation view
> 
> tim: what would be a minimum?
> 
> todd: i would imagine 16ms is a good lower bound
> 
> tim: sgtm
> 
> todd: we can always lower in the future if needed, 16ms is a simple 
> place to start ... if you have multiple event sources, you'd have to figure out on your own where slow event is coming from?
> 
> tim: today, yes. we put some thought into this but wanted to keep 
> initial scope small; we could always add this down the road
> 
> todd: sgtm, makes sense
> 
> -----
> 
> charter: 
> https://docs.google.com/document/d/1Zx2orxWQhjN7fsIfrR2EHVhVzIanppKIya

> qewrFJIFM/edit#
> next call: tentative Monday, 18th.
> 
> Summary of Action Items
> Summary of Resolutions
> [End of minutes]
> 
> 
> On 2018-05-31 05:29, Ilya Grigorik wrote:
>> Hi folks. A reminder and update on our call tomorrow (11AM PST) [1].
>> Currently we have...
>>  *
>> Update on "Priority Hints": github.com/WICG/priority-hints [2] — 
>> Addy, Dom.
>>  *
>> Update on "Event Timing": github.com/wicg/event-timing [3] — Tim.
>>  *
>> Review and discuss renewal of WG charter
>>  *
>> Current charter: w3c.github.io/charter-webperf/ [4]
>>  *
>> Current spec status: bit.ly/webperfwg-specs [5]
>>  *
>> Initial proposal for charter updates [6] If you have cycles ahead of 
>> the call, please review charter updates doc [7] and feel free to 
>> leave any comments or suggestions in there.
>> On Fri, May 25, 2018 at 3:59 PM Ilya Grigorik <igrigorik@google.com>
>> wrote:
>>> Hey folks. Our next call is tentatively scheduled for next Thursday:
>>> May 31st @ 11AM PST.
>>> Please add any topics you'd like to discuss in our planning doc:
>> https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37

>> B4q8Q46LMM/edit#heading=h.ozu502b9h3ey
>>> We'll also reserve some time next week to discuss our charter. Our 
>>> current one is expiring, which gives us an opportunity to revisit 
>>> and discuss goals, timelines, etc. For reference:
>>> * Current charter: https://w3c.github.io/charter-webperf/

>>> * Current spec status: https://bit.ly/webperfwg-specs If you have 
>>> any particular thoughts or suggestions on the charter, please let us 
>>> know!
>>> ig
>> Links:
>> ------
>> [1]
>> https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37

>> B4q8Q46LMM/edit?ts=5b0ed7a3&amp;pli=1#heading=h.ozu502b9h3ey
>> [2] https://github.com/WICG/priority-hints

>> [3] https://github.com/wicg/event-timing

>> [4] https://w3c.github.io/charter-webperf/

>> [5] https://bit.ly/webperfwg-specs

>> [6]
>> https://docs.google.com/document/d/1Zx2orxWQhjN7fsIfrR2EHVhVzIanppKIy

>> aqewrFJIFM/edit?ts=5b0edae2
>> [7]
>> https://docs.google.com/document/d/1Zx2orxWQhjN7fsIfrR2EHVhVzIanppKIy

>> aqewrFJIFM/edit?ts=5b0edae2&amp;pli=1
>

Received on Tuesday, 5 June 2018 05:15:52 UTC