webperf-wg-July 26th-2018.txt

<igrigorik> Ilya Grigorik agenda: https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#
11:07 Doug: NEL and Reporting moved from WICG to WebPerf
11:07 ... we have i2s LGTM's for both in Chrome
11:07 ... we'll be launching as stable experiments this quarter
11:07 ... we should have live implementation in chrome by EOQ
11:08 ... some good feedback from i2s process, which  resulted in spec updates
11:08 ... one common question from TAG was about using JSON in headers
11:09 ... we got some pushback from TAG on JSON; there are known gotchas with JSON — e.g. numbers.
11:09 ... alternative would be to use structured headers (being developed by httpwg / IETF)
11:10 ... after some analysis, we ended *not* doing that and sticking with JSON
11:10 ... implementation: we have confidence in JSON parser / security audits; structured headers would be a new parser — but that's not the blocker
11:11 ... 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
11:12 ... we're still referencing JFV — we're referencing a draft specification in IETF
11:12 ... ----
11:12 ... Reporting uploads are not subject to CORS preflights
11:13 ... we send CORS preflight to the reporting collector to confirm that collector is willing to accept reports on behalf of some origin
11:14 ... this caused some refacotring in batching logic, because this means we should only group by single origin
11:14 → yoav joined ([email protected])
11:14 <igrigorik> Ilya Grigorik ... ----
11:15 → garrett joined ([email protected])
11:15 <igrigorik> Ilya Grigorik ... there was a security issue raised around crafting a NEL spec that could enable someone to do a local port scan
11:16 ... the issue here  is around us enabling "includeSubdomain" policy, which has a good use case because we want NEL to capture DNS misconfigurations
11:17 ... NEL needs to verify that the IP address is its trying to request, matches the IP address it received the policy from
11:18 ... if they don't, we can only surface DNS issues
11:19 ... this introduces some complications with DNS  load balancing use cases; there are some examples in the spec
11:19 ... current behavior is conservative, we could look at expanding this in the future
11:20 Nic: we'll take an AI to review latest updates
11:21 Doug: when IP addresses don't match, we don't drop the report, we downgrade it...
11:21 .. you lose what kind of error there was, but might not have full visibility
11:22 Harald: check standards position repo
11:22 Todd: given current updates, does the spec still meet the original intent and use cases?
11:23 Doug: we believe so, there is active collaboration with our internal ("Domain reliability") infra to make sure that we can meet their needs
11:24 Todd: when do you think we'll have a good sense of adoption and use cases?
11:25 Doug: we're launching experiments in EOQ3, we'll want to run experiments for a while.. so ~early 2019.
11:25 ------------------------------
11:25 Nicolas: resource timing updates (in flight resources)
11:26 ... goal: currently RT only exposes info when resource has been completed, and we want to expose information while it's in progress
11:26 ⇐ yoav quit ([email protected]) Client closed connection
11:26 <igrigorik> Ilya Grigorik ... current proposal is to introduce "ResourceTimingUpdate" interface, similar to ResourceTiming with some additional attributes — e.g. list of updated attributes
11:28 ... 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
11:29 ... for PerfObserver: we can expose same interface there, with same buffering logic as other entries — i.e we would only buffer up to onload.
11:29 Nic: really excited about this, looks great.
11:30 ... for use cases: even with the L2 limitation, I think this would still address most of the use cases
11:31 Todd: it might be nice to list some of the alternative proposals in the doc
11:32 ... for example, ~FetchObserver could be another solution that's not tied to webperf specs
11:33 ... e.g. network.observe(...) to observe start and end of requests
11:34 AI: let's capture alternatives in the doc
11:34 Phillip: any guarantees on how quickly these would be dispatched to observer?
11:35 Nicolas: per PO spec, delivery is ~low priority, so there isn't a strong guarantee
11:35 <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."
11:35 <igrigorik> Ilya Grigorik ^ that :)
11:36 -----------------
11:36 Element Timing 
11:37 Nicolas: we're simplifying current proposal, starting with images as first use case
11:37 ... the generic case is complicated due to nesting
11:38 ... for img, you could <img ... elementtiming="foo>
11:38 ... but we could also expose automatic registration, e.g. for analytics use cases
11:39 "we consider images that occupy significant percentage of the viewport" — e.g. maybe 15%, up for discussion
11:40 ... after image has loaded, first time we run the rendering step in viewport
11:43 ... for the image low on the page.. we could distinguish whether it was visible in the viewport
11:44 Todd: how do you enable this without instrumenting?
11:44 Tim: we have proposal for implicit registration, but it is scoped to ~large image
11:44 ... attribute registration is the explicit opt-in
11:45 Nic: implicit use case is very important to us, it significantly lowers onboarding 
11:45 ... large elements is a good tradeoff; "if you want to tweak the default, go do this"
11:46 Todd: so, if we look at Facebook as an example.. I'm guessing most images are ~small, we should think about the implicit registration
11:46 ... current time is referencing "when rendered", what do we mean by that?
11:47 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
11:48 Tim: I'm working on an update to the HTML spec to clarify this
11:48 Todd: we decouple decoding and display in Edge, there's is some dark corners in the spec here
11:49 ... this is an important measuring fundamental,
11:50 Nic: the 15% in the proposal, would/could that be controllable?
11:50 Tim: probably not, because we need to pick a default
11:50 Nicolas: this also depends on how much overhead it would be to track all images
11:51 Tim: we could track either by % or number of images
11:52 AI: define the "image loaded" / rendering
11:52 AI: how to expose large images outside of viewport
11:53 ... might be worth adding an explainer for out-of-viewport images
11:53 ---------
11:53 shouldYield
11:54 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
11:54 ... there is a tradeoff between doing work fast, but risking non-responsive, or being responsive but paying overhead
11:55 ⇐ garrett quit ([email protected]) garrett
11:55 <igrigorik> Ilya Grigorik ... shouldYield is a bool that tells you whether there is pending user input
11:55 ... as a way for browser to signal to application that it should yield
11:56 ... there is a discussion in Discource (WICG).
11:57 ... we gave a build to FB, and they have some (unreasonably impressive) stats — see thread.
11:58 Nic: we're going through similar pain with Nic; we have this challenge in Boomerang
11:58 ... Q: does this have any overlap w/ tti?
11:59 Philip: it would be good to add an explainer for where/why this overlaps with requestIdleCallback
11:59 Tim: there is a difference here between low vs high priority work
11:59 — plh Ilya, I have a short question for you and Todd before you adjourn (sorry, arrived too late to ask earlier :( )
12:00 <igrigorik> Ilya Grigorik Todd: based on experience with schedulers, we ideally want small tasks, the overhead in scheduling should be low
12:00 ⇐ dcreager quit ([email protected]) "leaving"
12:00 <igrigorik> Ilya Grigorik Tim: the composition model is different, we should followup on this
12:01 plh: can we update NEL and reporting
12:02 ... ^ public on W3C
12:02 +1 from Todd and Ilya