Minutes (was: Re: [7/26/18] webperf (design) group call @ 11AM PST)

Available at:
https://www.w3.org/2018/07/26-webperf-minutes.html

Also in plain text as:

WebPerf Group Call
26 Jul 2018
Agenda

Attendees
Present
igrigorik, Harald, todd, plh, Doug, Phillip, Nic, Nicolas, Tim
Regrets
Chair
igrigorik
Scribe
igrigorik
Contents
Topics
NEL & Reporting
resource timing
Element Timing
shouldYield
Summary of Action Items
Summary of Resolutions
NEL & Reporting
Doug: NEL and Reporting moved from WICG to WebPerf
... we have i2s LGTM's for both in Chrome
... we'll be launching as stable experiments this quarter
... we should have live implementation in chrome by EOQ
... some good feedback from i2s process, which resulted in spec updates
... one common question from TAG was about using JSON in headers
... we got some pushback from TAG on JSON; there are known gotchas with 
JSON — e.g. numbers.
... alternative would be to use structured headers (being developed by 
httpwg / IETF)
... after some analysis, we ended *not* doing that and sticking with 
JSON
... implementation: we have confidence in JSON parser / security audits; 
structured headers would be a new parser — but that's not the blocker
... more importantly, structured headers have some limitation in terms 
of schemas that we can implement; doing the switch would require a major 
rework of the configuration
... we're still referencing JFV — we're referencing a draft 
specification in IETF
... ----
... Reporting uploads are not subject to CORS preflights
... we send CORS preflight to the reporting collector to confirm that 
collector is willing to accept reports on behalf of some origin
... this caused some refacotring in batching logic, because this means 
we should only group by single origin
... ----
... there was a security issue raised around crafting a NEL spec that 
could enable someone to do a local port scan
... the issue here is around us enabling "includeSubdomain" policy, 
which has a good use case because we want NEL to capture DNS 
misconfigurations
... NEL needs to verify that the IP address is its trying to request, 
matches the IP address it received the policy from
... if they don't, we can only surface DNS issues
... this introduces some complications with DNS load balancing use 
cases; there are some examples in the spec
... current behavior is conservative, we could look at expanding this in 
the future

Nic: we'll take an AI to review latest updates

Doug: when IP addresses don't match, we don't drop the report, we 
downgrade it...
... you lose what kind of error there was, but might not have full 
visibility

Harald: check standards position repo

Todd: given current updates, does the spec still meet the original 
intent and use cases?

Doug: we believe so, there is active collaboration with our internal 
("Domain reliability") infra to make sure that we can meet their needs

Todd: when do you think we'll have a good sense of adoption and use 
cases?

Doug: we're launching experiments in EOQ3, we'll want to run experiments 
for a while.. so ~early 2019.

resource timing
Nicolas: resource timing updates (in flight resources)
... goal -- currently RT only exposes info when resource has been 
completed, and we want to expose information while it's in progress
... current proposal is to introduce "ResourceTimingUpdate" interface, 
similar to ResourceTiming with some additional attributes — e.g. list of 
updated attributes
... with current proposal (integrating L2), we would expose that fetch 
is in flight, but a lot of the rest would be delayed until much later 
due to how L2 handles redirects, etc... this can be more granular in L3, 
when we unpack subrequests
... for PerfObserver: we can expose same interface there, with same 
buffering logic as other entries — i.e we would only buffer up to 
onload.

Nic: really excited about this, looks great.
... for use cases: even with the L2 limitation, I think this would still 
address most of the use cases

Todd: it might be nice to list some of the alternative proposals in the 
doc
... for example, ~FetchObserver could be another solution that's not 
tied to webperf specs
... e.g. network.observe(...) to observe start and end of requests

<scribe> ACTION: RT editor to capture alternatives in the doc

Phillip: any guarantees on how quickly these would be dispatched to 
observer?

Nicolas: per PO spec, delivery is ~low priority, so there isn't a strong 
guarantee

<plh> "The performance timeline task queue is a low priority queue that, 
if possible, should be processed by the user agent during idle periods 
to minimize impact of performance monitoring code."

^ that :)

Element Timing
Nicolas: we're simplifying current proposal, starting with images as 
first use case
... the generic case is complicated due to nesting
... for img, you could <img ... elementtiming="foo>
... but we could also expose automatic registration, e.g. for analytics 
use cases

"we consider images that occupy significant percentage of the viewport" 
— e.g. maybe 15%, up for discussion

scribe: after image has loaded, first time we run the rendering step in 
viewport
... for the image low on the page.. we could distinguish whether it was 
visible in the viewport

Todd: how do you enable this without instrumenting?

Tim: we have proposal for implicit registration, but it is scoped to 
~large image
... attribute registration is the explicit opt-in

Nic: implicit use case is very important to us, it significantly lowers 
onboarding
... large elements is a good tradeoff; "if you want to tweak the 
default, go do this"

Todd: so, if we look at Facebook as an example.. I'm guessing most 
images are ~small, we should think about the implicit registration
... current time is referencing "when rendered", what do we mean by 
that?

Nicolas: there's a sketch in the proposal. In html spec, under "update 
rendering" we would use that timestamp (after it has loaded), once the 
image is in the pending list of images

Tim: I'm working on an update to the HTML spec to clarify this

Todd: we decouple decoding and display in Edge, there's is some dark 
corners in the spec here
... this is an important measuring fundamental,

Nic: the 15% in the proposal, would/could that be controllable?

Tim: probably not, because we need to pick a default

Nicolas: this also depends on how much overhead it would be to track all 
images

Tim: we could track either by % or number of images

<scribe> ACTION: Tim to define the "image loaded" / rendering

<scribe> ACTION: Tim to explore how to expose large images outside of 
viewport might be worth adding an explainer for out-of-viewport images

shouldYield
Tim: ... today you could either batch work and hope that there isn't 
more critical work, or you could split the work.. but you pay the cost 
because you're posting a task
... there is a tradeoff between doing work fast, but risking 
non-responsive, or being responsive but paying overhead
... shouldYield is a bool that tells you whether there is pending user 
input
... as a way for browser to signal to application that it should yield
... there is a discussion in Discource (WICG).
... we gave a build to FB, and they have some (unreasonably impressive) 
stats — see thread.

Nic: we're going through similar pain with Nic; we have this challenge 
in Boomerang
... Q: does this have any overlap w/ tti?

Philip: it would be good to add an explainer for where/why this overlaps 
with requestIdleCallback

Tim: there is a difference here between low vs high priority work

Todd: based on experience with schedulers, we ideally want small tasks, 
the overhead in scheduling should be low

Tim: the composition model is different, we should followup on this

plh: can we update NEL and reporting
... ^ public on W3C

+1 from Todd and Ilya

RESOLUTION: Publish a W3C WD for NEL and reporting

Summary of Action Items
[NEW] ACTION: RT editor to capture alternatives in the doc
[NEW] ACTION: Tim to define the "image loaded" / rendering
[NEW] ACTION: Tim to explore how to expose large images outside of 
viewport might be worth adding an explainer for out-of-viewport images

Summary of Resolutions
Publish a W3C WD for NEL and reporting
[End of minutes]

On 2018-07-25 06:56, Ilya Grigorik wrote:
> Hey folks!
> 
> I know some folks are still on holidays (summer scheduling is always
> hard), but just a reminder that we have a design call scheduled for
> later this week, and with packed agenda:
> 
>  *
> 
> NETWORK ERROR LOGGING + REPORTING UPDATE — DCREAGER@
> 
>  *
> 
> RECEIVED APPROVAL TO SHIP IN CHROME M69 (~EARLY SEPTEMBER)
>  *
> 
> SUMMARY OF CHANGES SINCE WE FILED THE INTENT TO SHIP IN MAY
> 
>  *
> 
> STILL USING JSON FOR HEADER/REPORT PAYLOAD
>  *
> 
> REPORT UPLOADS SUBJECT TO CORS
>  *
> 
> HTTPS://GITHUB.COM/W3C/NETWORK-ERROR-LOGGING/ISSUES/74 [1]
> 
>  *
> 
> RESOURCE TIMING: UPDATED PROPOSAL FOR IN-FLIGHT RESOURCE REQUESTS [2]
> — NPM@
>  *
> 
> UPDATE ON ELEMENT TIMING [3] - NPM@
>  *
> 
> NEXT STEPS FOR USER TIMING L3 [4] (and parking Performance Entry [5])
> — tdresser@, nolawson@, philipwalton@
>  *
> 
> FYI & FEEDBACK: SHOULDYIELD PROPOSAL [6] — TDRESSER@
> 
>  If you have other topics you'd like to discuss, please drop them into
> the agenda [1].
> 
> Otherwise, see you on the hangout this Thursday:
> https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg
> 
> ig
> 
> [1]
> https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.6ilqz7pbc2gc
> 
> 
> 
> Links:
> ------
> [1] https://github.com/w3c/network-error-logging/issues/74
> [2]
> https://docs.google.com/document/d/18J6JJB4HHssqIfeHjb6sQbRrbcduJFRfkset8edt5L4/edit?usp=sharing
> [3]
> https://docs.google.com/document/d/1blFeMVdqxB0V3BAJh60ptOBFY7cJSXnf7VyW3wspbZ8/edit?ts=5b50c86b#
> [4]
> https://docs.google.com/document/u/1/d/1hltt8z9C4PaI5Qu1YMIp1wOGdbJPJPoJwBarEeCY6xQ/edit#heading=h.ejti6qhmjv0b
> [5] https://github.com/wicg/performance-entry
> [6]
> https://discourse.wicg.io/t/shouldyield-enabling-script-to-yield-to-user-input/2881

Received on Tuesday, 21 August 2018 14:28:41 UTC