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.
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 :)
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
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