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

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 Friday, 1 June 2018 10:22:16 UTC