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/1Zx2orxWQhjN7fsIfrR2EHVhVzIanppKIyaqewrFJIFM/edit#
> Summary of Action Items
> Summary of Resolutions
> Agenda for today's call: https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/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/1Zx2orxWQhjN7fsIfrR2EHVhVzIanppKIyaqewrFJIFM/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_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/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_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/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/1Zx2orxWQhjN7fsIfrR2EHVhVzIanppKIyaqewrFJIFM/edit?ts=5b0edae2
>> [7]
>> https://docs.google.com/document/d/1Zx2orxWQhjN7fsIfrR2EHVhVzIanppKIyaqewrFJIFM/edit?ts=5b0edae2&amp;pli=1
>

Received on Tuesday, 5 June 2018 03:27:55 UTC