Agenda for today's call: https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.c7x3glbx3g3m
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
----------
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
-----
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.)[End of scribe.perl diagnostic output]