Philippe le Hegaret - W3C
Ryosuke Niwa - Apple
Nate Schloss, Andrew Comminos - Facebook
Nic Jansma - Akamai
Gilles Dubuc - Wikimedia
Will Hawkins, Benjamin De Kosnik - Mozilla
Thomas Kelly - Shopify
Steven Bougon - Salesforce
Todd Reifsteck - Microsoft
Ilya Grigorik, Nicolás Peña, Tim Dresser, Yoav Weiss - Google
Chair: Yoav Weiss
Ilya: Chrome is shipping SXGs - you can wrap a document in an SXG, serve it from a random origin, and the browser will consider it as coming from the original origin.
This solves the AMP cache use case among others.
But what implications does that have for telemtry - if the document was served from a different physical origin, what does that mean to the APIs.
In NEL we added an option for SXG failure reporting
Should it change navigation timing reporting to say that the navigation is an SXG one?
<yoav explains what’s SXGs>
For AMP - if you have an AMP site, you can provide an SXG to the edge caches, and when a user clicks on a link to the SXG, the SXG is loaded from AMP CDN, but presented to the user as if it came from the origin.
But for perf reporting - should we distinguish those cases?
Ryosuke: how does the browser know where to load the resource from
Ilya: The links point there.
Ilya: let’s draft something about how SXGs work and then get a gut check
Benjamin: Gut check is that we need separate telemetry
slides - Nicolás
Spec for images - https://wicg.github.io/element-timing/
Nicolás: Already presented ET for images, this is focused on text. Want to expose entries for important text components.
*presents IDL*
For images we want to expose: img, svg, poster and BG-imgs (even if BG images are not an element)
Dispatch when image takes significant portion of viewport
For text:
Text nodes are not elements - need to be aggregated
Tim: if you have a <p> with bold text and that bold text is waiting on a font, should the <p> be marked as visible?
Yoav: maybe a %age of visible text on the element would be good enough?
Tim: that %age can be 100% even.
Nicolás: the question is more about “belonging” - which text node belongs to which element?
Maybe the answer is all the contained nodes, but it could have performance implications
Also, we want automatic registration for text, so we need efficient computations
Plh: maybe the first text node of the element?
Nicolás: if you have a <p> with links and bold text and many other sub elements, the first is not logical
Tim: If you have two similar headlines, where the first child on the first and the second on the second appear first, that would give a different score without real justification.
Maybe 1 or 2 levels of nesting are enough.We’re looking into that
Nicolás: Another proposal was to look at certain DOM elements that are considered phrasing content, which is basically text content. Needs more research and look at real websites. Wondered if anyone has any clever ideas.
Todd: Just read the explainer. Appears you’re properly breaking down the problem.
Tim: If we show that finite depth covers the problem well, does that seem like a reasonable solution to the WG?
Ryosuke: The depth of DOM trees is rarely relevant. The tricky cases are overflows, clipping and text wrapping. So computing the bounding box of text is super expensive because of that. I don’t think limiting the depth will solve the problem
Tim: it reduces the set of elements that we care about.
Ryosuke: sure, but the few elements you have may be pathological and trigger full page relayout.
Tim: In these cases, the ET entries will not be surfaces until the content is laid out, so no need to force layout.
Ryosuke: Sure, but you’d still need to compute the bounding boxes. Need to combine the rects regarding overflows. If we can ignore overflows that could be easy.
Tim: good point
Plh: have you looked at CSS generated content
Nicolás: that’s a problem… Assuming we need to define the text node’s alignment with an element, we want to define the time as the first time of painting for all elements, so rendering with a fallback font
That’s relevant, because for an element to be considered rendered, we want to wait for all nodes. If contents is generated dynamically, that could be problematic
Tim: CSS is not async so should be fine
Nicolás: yeah, CSS would be fine. JS would be problematic
Otherwise, size of elements, we need to define what it is
Proposing to take the sum of all bounding boxes, for performance reasons
Could overlap, but in the majority of cases, should be close enough
Nic: pixel value or %age value?
Nicolás: same problem as images.
Ryosuke: Why not number of pixels?
Tim: may not translate well across device form factors
Ryosuke: and on resize?
Tim: we will use the original viewport size
Ryosuke: If the user is resizing while the page is loading, the values may be off
Tim: Yeah, we should give some more thought to that
Nicolás: IntersectionRect: current proposal to define as the smallest rect that contains all the nodes
Another option is to expose all the rects, one for each text node, but I don’t think it provides a lot of value. Could be confusing.
Current proposal works fine for rectangles, but can over-estimate for more complex element layouts.
Ryosuke: computing the rect of text is very expensive, so that’s a problem. Rect of an element is faster. We can’t figure out the bounding rect of each element without figuring out if text is visible or not.
Tim: The explainer calls out clipping and oclusion cases. It’s probably fine for the primary use cases. But we need to reason through the performance.
Ryosuke: maybe forget about text and just consider the element box and use that instead?
Nicolás: that’s an option
Tim: You can have a large element with a little bit of text in it, so the important text is not that important
Nicolás: there are tradeoffs between performance and accuracy
More thoughts?
How to handle buffering once we ship the buffered flag?
Want people to ship performance observer, but currently we don’t expose entries from the past.
Wrote down a proposal in the comment. Thoughts?
Tim: new entry types we want them to be available and we want that information to be available to developers, so need to refactor.
The browser also needs to keep buffering, so we need to determine that buffer size, but in a simple way: buffer until the buffer is full, then entries get dropped
Ilya: should we also break buffering in RT
Nicolás: maybe not at first. This is more about new entry types. Long tasks is a special case, as right now we don’t buffer them at all, but header registration can help us do that
Event timing and element timng are good candidates
Plh: so you have a buffer for each type, but may not make it available for all types. In the current algorithm we have a flag. Why didn’t we use the same?
Tim: we need things that return from PO but not from getEntries
Nicolás: if you had a PO that observes afterwards, it’s currently gone. The buffered flag should resolve that
Todd: everything you say there looks fine. Waiting for final spec for full judgement
Nicolás: will add you as a reviewer to the PR
Ilya: so if I’m making a new thing, what’s the guidance?
Nicolás: I haven’t specified guidance
Ilya: are we trying to drive people away from getEntries?
Nicolás: yes. We would need to add some flags to entries defined by relying specifications. We would need to provide a max size for the buffer as well.
Tim: so maybe provide also a brief snippet of what integration may look like
Ilya: or a separate document. *describes the new behavior*
Todd: if we want PO to be the only new thing, but maybe we also need to be able to set buffer sizes in headers or HTML
Tim: Yeah, that was our thinking. Start with a default size and eventually have a way to set it
Plh: For nav timing we only need an entry of 1. Have we solved the problem of entries that were emitted before the PO registered?
Yoav: this is solving exactly that problem