Minutes from WG call: November 27th @ 11AM PST (Triage/Design)

Thanks all that were on the call!

Minutes are now here
<https://docs.google.com/document/d/e/2PACX-1vTI_8Otl8XbJgChbUPQ_XJkJSRmXh2oaNfldhL0rKzjw-J8EUiYMt5UkMueLPZTV8jaQoO2jkfSxoFr/pub>
.

Copying them inline for safe keeping:

WebPerfWG call 27/11/18
Attendees



*Ilya Grigorik, Todd Reifsteck, Tobin Titus, Tim Dresser, Nicolas Pena,
Markus Stange, Benjamin De Kosnik, Charlie Vazac, Nic Jansma, Steve
Souders, Yoav WeissChair: YoavScribes: Ilya, Yoav*Resource Timing


* - Fire `resourcetimingbufferfull` asynchronously - alternative approach
<https://github.com/w3c/resource-timing/pull/168> - 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- Make TAO a subset of
CORS <https://github.com/w3c/resource-timing/issues/178>- 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.- Allow semi-wildcard
`Timing-Allow-Origin` values (for subdomains)
<https://github.com/w3c/resource-timing/issues/175>- 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.- Privacy implications?- [Todd] there are probably some leaks to
consider - e.g. different IPs for different subdomains?- Should 404 codes
by considered aborts? <https://github.com/w3c/resource-timing/issues/165>-
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
<https://docs.google.com/presentation/d/1L96bc-JxZ628WMFbu0Skyu1UDrI7zn9aZepiMfTQrUE/edit#slide=id.p>)
- Nicolás:- 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.-
Tim:- 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

   -

   Unload event TAO check should be for all redirects
   <https://github.com/w3c/navigation-timing/issues/95>
   -

      Probably just a miswording. Need tests.
      -

   Define attribute behavior only once
   <https://github.com/w3c/navigation-timing/issues/97>
   -

      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.



On Fri, Nov 23, 2018 at 2:48 PM Yoav Weiss <yoav@yoav.ws> wrote:

> Hey folks,
>
> Please join us on the call next week. We'll have a new hangout link
> <https://hangouts.google.com/hangouts/_/chromium.org/webperfwg> for the
> call, which will hopefully be smooth to connect to. If you'd add your name
> and email to the list
> <https://docs.google.com/spreadsheets/d/1j7uyLfYoNqJkBF8MHfh48wjZ6PApz4GylxhHLqoTP_s/edit?usp=sharing>
> I'll send you a calendar invite with that link, which will hopefully make
> it easier to join the calls (as you will not need someone to click you
> through).
>
> See y'all there!
> Tentative agenda below, but please add to it if you want to discuss
> something else:
>
>    -
>
>    Resource Timing
>    -
>
>       Make TAO a subset of CORS
>       <https://github.com/w3c/resource-timing/issues/178>
>       -
>
>       Allow semi-wildcard `Timing-Allow-Origin` values (for subdomains)
>       <https://github.com/w3c/resource-timing/issues/175>
>       -
>
>       Should 404 codes by considered aborts?
>       <https://github.com/w3c/resource-timing/issues/165>
>       -
>
>    Navigation Timing
>    -
>
>       Unload event TAO check should be for all redirects
>       <https://github.com/w3c/navigation-timing/issues/95>
>       -
>
>       Define attribute behavior only once
>       <https://github.com/w3c/navigation-timing/issues/97>
>       -
>
>    User Timing
>    -
>
>       Update on current usage, based on Chrome Canary data.
>       -
>
>          Of calls to performance.measure:
>          -
>
>             For the start parameter and the end parameter.
>             -
>
>                A number is passed < 0.0001% of the time.
>                -
>
>                Null or undefined are passed < 0.0001% of the time.
>                -
>
>    Event/Element Timing - proposed changes
>
>
> Cheers :)
> Yoav
>