Re: WebPerfWG call - November 19th 2019 @ 11am PST

Hey all,

Minutes
<https://docs.google.com/document/d/e/2PACX-1vR5LxMEKopOssn86iRToQYpqEUGkNVVko23aYh6WwjiZuvHA13Hf7kHfqYE17Bt3uMRaKVdmbf-dgz_/pub>
from yesterday's meeting are now available, as well as the video
<https://youtu.be/1B6sFgbIPaU>. Copying the minutes here for safe keeping:
WebPerfWG call - 19 November 2019

Participants: Philippe Le Hegaret, Gillis Dubuc, Peter Hedenskog, Scott
Haseley, Alex Timin, Will Hawkins, Nicolás Peña, Nic Jansma,  Subatra Ashe,
Benjamin De Kosnik

Next Call

December 5 @ 11am PST

Main Thread Scheduling APIs
<https://www.google.com/url?q=https://docs.google.com/presentation/d/1yLkP41BQlJw-N-6dvbEkC8JhXm8sYdlXnAORDHcBKiQ/edit%23slide%3Did.g5b43bd1ecf_0_508&sa=D&ust=1574259413801000>
-
Scott Haseley

Scott:

scheduler.postTask() API allows scheduling of prioritized tasks

… Implemented v0 task-queue based prototype in Chromium

… Changing to a Signal-based prototype in response to TAG feedback

… Planning to go to Origin Trial to evaluate performance and broader
feedback on ergonomics

… Controller/Signal based design

   - Inspired from AbortController/AbortSignal
   - Removing Task objects replacing with a Promise
   - Removing TaskQueue

… Examples of old vs. new
<https://www.google.com/url?q=https://docs.google.com/presentation/d/1yLkP41BQlJw-N-6dvbEkC8JhXm8sYdlXnAORDHcBKiQ/edit%23slide%3Did.g78f96ea603_0_19&sa=D&ust=1574259413802000>
-
Promise is significantly simpler and less verbose

   - Fetch example - we pass in a Signal object (that we got from
   AbortController) and that enables aborting fetches later
   - Changed the API to add a new object TaskController that has a signal
   - Relationships are now exposed by sharing a signal

… What’s controller priority?

   - TaskController allows you to change priorities, on top of just
   aborting everything that shares a signal
   - Allows Fetch reprioritization as well as task reprioritization in
   general

Yoav: So from a Priority Hints perspective, that would give us
reprioritization?

Scott: Yes

Yoav: If I want to create a task that would propagate other signals to
subtasks, this will enable that?

Scott: Yup. Also cases where you’d want the signal and priority to differ,
so we want to pass along an explicit priority

… Signals are read-only - easy to pass and help to resolve the priority
inversion problem

… Task/SubTask vs. TaskQueue model - Signals are better for Task/SubTask,
and can be used to model task queues, even if it’s clunky

… Exploring options around signal propagation (getting current signal,
inheriting, etc). This has some risk of misuse/footgun

… Still seeking feedback from other implementers

Will/Ben: Defer to Boris who has been tracking it closer

Ben: Interested teasing out the difference between Abort and Signal
propagation

Safari/Edge not present

LongTasks Interaction w/ Buffered Flag

Nicolás: Chrome planning to ship buffering of LongTasks from start of page
and available via PO

… PerformanceObserver.observe({ buffered:true })

… Earlier thought there would be overhead related to their computation, but
then realized that they are being measured anyway?

… Is the same true for Firefox?

… If so, and we’re willing to move forward with it, what would be the
initial buffer size?

… No data on per-frame long tasks in Chrome, but data on onload

… Time to load event 90p is less than 10 seconds, so at a maximum less than
200 LTs

… Does a buffer size of 200 sounds reasonable?

Nic: 200 seems reasonable. Akamai can look to see what the distribution is,
but don’t have the initial LTs.

Gilles:        Customers with LT buffering in head?

Nic: No major ones

Yoav: Maybe we could do some math based on the time in which the PO was
registered as well as the number of LTs that happened after it.

Nic: No need to store the ones after PO

Yoav: True, but it can help us estimate

Gilles: p90 for load event is 20-30 seconds. Need to evaluate methodology

Nicolás: Working on gathering data but will take some time

Yoav: we could also change the buffer size afterwards, if it’s too small

Nicolás: Ideally, we would like to avoid it, but possible

Nic: 200 sounds like a decent number

Ben: calculation sounds simple and fine. Why is Gilles seeing 3x the
numbers though?

Gilles: More users from slower countries? If we’d hit the limit often we’d
let you know

Yoav: CrUX data?

Nicolas: Might not have onload

Nic: Akamai customer have a 95p long task number of ~30.

Gilles: So, I guess 200 sounds reasonable and we’ll let you know if we hit
the limit

Ben: Sounds reasonable

Nicolás: Great, I’ll update the registry
TAO and Fetch integration

https://github.com/whatwg/fetch/pull/955
<https://www.google.com/url?q=https://github.com/whatwg/fetch/pull/955&sa=D&ust=1574259413808000>

Nicolás: Trying to integrate TAO into Fetch. Has a PR for it, but there
were no tests and needed to file browser bugs for the changes

… 2 changes are:

   1. Instead of same origin checks we now check “response tainting” which
   is a Fetch concept that’s pretty close to same-origin check
   2. Using the “serialize the origin” method that returns null is the
   origin is tainted - which means there are two origin crosses in the
   redirect chain. Once it’s set the TAO header must be “*” and maybe “null”

… The goal is to align with CORS, but will result in changes to the
processing of TAO, so heads-up on upcoming browser bugs

… Analytics providers can shout at us if the change will be breaking TAO

Nic: We will notice

Nicolás: main change is requiring a “*” for cross origin redirects

Nic: All I see is stars!

Nicolás: Great

Yoav: Motivation is alignment with CORS and have CORS imply TAO. Not aware
of security issues that require those restrictions, but aligning with CORS
will give us more content.

Ben: High level goals sound great, need to dig in to better understand.

Yoav: Also, in CORS “*” is simplifying the processing model as well as they
don’t support a list of origins. For TAO, we just want to align unless it
breaks something significant.


On Mon, Nov 18, 2019 at 11:42 AM Yoav Weiss <yoav@yoav.ws> wrote:

> Hey all,
>
> Please join <https://meet.google.com/agz-fbji-spp> us tomorrow to talk
> performance!
>
> On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.pdptt3pnkl1w>
> :
> * Scheduling API updates
> * Longtasks and buffered flag
> * TAO integration with Fetch
>
> Note that as always, the call will be recorded and posted online.
>
> See y'all tomorrow! :)
> Yoav
>