Attendees
Ilya Grigorik, Todd Reifsteck, Tobin Titus, Tim Dresser, Nicolás Peña, Markus Stange, Benjamin De Kosnik, Charlie Vazac, Nic Jansma, Steve Souders, Yoav Weiss
Chair: Yoav
Scribes: Ilya, Yoav
Resource Timing
- Landed in Chrome
- Edge already filed bug
- FF to open implementation bug
- Safari should (in theory) already be compliant, but need to confirm with tests
- Based on feedback from analytics vendors, want to allow CORS resources to pass TAO check-in
- Should this target L2 or L3?
- There is an integration required with fetch → L3.
- What are the security implications?
- We would expose some new information about timestamps, e.g. time to resolve DNS.
- AI: need a more thorough security review.
- What would the impact be of this change be?
- If we land this, how many more responses would get timing data?
- Nic: ran some research on TAO headers that we could rerun to investigate CORS mode.
- Nic + Yoav to follow up on crawler based metrics.
- Decision: push to L3; new feature; use case is not entirely solid.
- What is the use case?
- Allow sharded resources to opt-in easily
- [Steve] we have a customer that needed to add 50 different TLDs for their site, ideally this could have been a wildcard.
- [Todd] there are probably some leaks to consider - e.g. different IPs for different subdomains?
- This is planned for L3, tagging it as that.
- The past+current agreement is that RT will expose all responses, regardless of response code. However, this needs integration with Fetch.
User Timing
- As decided at TPAC, the Chrome team gathered data on the safety of shipping User Timing L3. Conclusion is that it is safe to do that. (less than 0.0001% for both numbers and null/undefined)
Render Timing
(presentation)
- Multiple different specs require to measure “next paint” - Event Timing, Element Timing, Paint Timing, Maybe LongTasks in the future
- RenderTiming can unify the model for all of the above
- Measure start of rendering pipeline, end of event loop, and when pixels hit the screen.
- RenderTiming will not be exposed directly, but as part of other entries
- Initially only contain the current single measurement, and would add the other points of measurements later on
- Steve: Love rendering metrics, but sounds a bit confusing. How heuristic would the “actually displayed” metric be?
- Tim: Hoping implementations would use the signal they get from the GPU, but can’t spec that
- Todd: We want the spec to push browsers towards accurate metrics, while understanding that OSes don’t necessarily expose that info. Not exposing anything if it can’t be perfect is not the way to go.
- Steve: How would I interpret it for Element Timing?
- Tim: Even if we can’t attach operations to specific element, this would give you a picture of how much time we spent on the different operations when the element was displayed.
- Steve: worried that developers will be confused about the cause of the problem
- Tim: It’s complicated to understand that and drawing those conclusions can be difficult. But can point you in the right direction. But we could potentially expose expensive operations in the future.
- Todd: The gap between mainThreadDone and displayDone can lead us to seeing patterns of browser differences.
- Steve: Very excited for Element and Rendering timing.
- Tim: Thoughts on general API shape?
- Nic: Makes sense for the evolution of what we have today
Navigation Timing
- Probably just a miswording. Need tests.
- Yoav: The current spec defines things in multiple places and it would be better to unify that into a single definition
- Todd: No objections, just work
- Nicolás: What would it look like when defining the attributes?
- Yoav: Non-normative note describing what they do, but not precise definition.
- Nicolás: Makes sense.