Re: WebPerfWG design call - Thursday March 14th @ 11am PT

Hey all,

Minutes from last week's design call are now available
<https://docs.google.com/document/d/e/2PACX-1vRt4-tPpYEHBoirB2-gs9svUYy5DLGldk-Cwt0xQToy7hNh8G9HypdqMt58rwAYj8tX6m1ke7hTi2jr/pub>!
(apologies for it taking longer than usual. Technical difficulties...)
Recording for the call will soon follow.

Copying the minutes here for safe keeping:

WebPerfWG design meeting notes - March 14th 2019
Present

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
Admin

   - TPAC - Which WG meetings should we try to avoid?
      - Try to avoid conflict with webapps and web platform, service workers
   - Next meeting March 29th

SXG and perf telemetry

Ilya: Chrome is shipping SXGs
<https://www.google.com/url?q=https://developers.google.com/web/updates/2018/11/signed-exchanges&sa=D&ust=1552900920379000>
-
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

Element Timing for Text elements
<https://www.google.com/url?q=https://docs.google.com/document/d/1xhPJnXf0Nqsi8cBFrlzBuHavirOVZBd8TqdD_OyrDGw/edit?usp%3Dsharing&sa=D&ust=1552900920380000>

slides
<https://www.google.com/url?q=https://docs.google.com/presentation/d/1sblyolOAWQuY9xEsGfJsnjrQv8sg13EyShsNAZhCEbs/edit?usp%3Dsharing&sa=D&ust=1552900920381000>
-
Nicolás

Spec for images - https://wicg.github.io/element-timing/
<https://www.google.com/url?q=https://wicg.github.io/element-timing/&sa=D&ust=1552900920381000>


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
<https://www.google.com/url?q=https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Content_categories%23Phrasing_content&sa=D&ust=1552900920383000>,
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?

Performance Timeline buffering
<https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/81%23issuecomment-462513499&sa=D&ust=1552900920386000>

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


On Wed, Mar 13, 2019 at 8:21 AM Yoav Weiss <yoav@yoav.ws> wrote:

> Hey all,
>
> Let's talk about new and exciting webperf features tomorrow! :D
> On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.mrrkl83ul16p>
> we currently have:
>
>    - SxG and webperf telemetry — igrigorik@
>    - Element Timing for Text Elements
>    <https://docs.google.com/document/d/1xhPJnXf0Nqsi8cBFrlzBuHavirOVZBd8TqdD_OyrDGw/edit?usp=sharing>
>    - npm@
>    - Performance Timeline buffering
>    <https://github.com/w3c/performance-timeline/issues/81#issuecomment-462513499>
>    - npm@
>    - In-progress resource requests
>    <https://github.com/w3c/resource-timing/issues/137> - npm@
>
> But it's very likely we'll add more stuff to the agenda and/or shuffle
> things around. If you have anything you want to discuss, don't be shy.
>
> The hangout for the call is the usual one
> <https://meet.google.com/nog-ttdz-myg?hs=122>.
>
> See y'all tomorrow! :)
> Yoav
>