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.

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: Addy Ilya Dom Nic Charles Todd Yoav Garrett Panagoitis Philippe Nolan xiaoqian Tim Nicolas
No ScribeNick specified.  Guessing ScribeNick: igrigorik
Inferring Scribes: igrigorik

WARNING: No "Topic:" lines found, but dash separators were found.  
Defaulting to -dashTopics option.


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)