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

Hi Todd,

Sure, if you can send me a note by next Wednesday, I’d try to give an early feedback as needed.

> On Jun 4, 2018, at 10:15 PM, Todd Reifsteck <toddreif@microsoft.com> wrote:
> 
> 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 Thursday, 7 June 2018 06:47:51 UTC