Re: Next call - October 16th 11am PST (TPAC planning, Triage and Design)

Thanks to all who attended. Minutes from the call can be found here
<https://docs.google.com/document/d/e/2PACX-1vRlt2UBBEVuaBf_M23KE9l5O4OrdNrHVsrotiEDKr_rNTvIs3aGlidBiA2NWPyizHsCgBrD1H8-_Be6/pub>
or
below

WebPerfWG - October 16th minutes

Present: Tim Dresser, Yoav Weiss, Nicolas Pena, Ryosuke Niwa, Andrew
Comminos, Charles River, Charles Vasac, Eric Faust, Gilles D, Nathan
Schloss, Nic Jansma, Philip Walton, Philippe Le Hegaret, Shubhie Panicker,
Shweta Joshi, Todd Reifsteck, Vladan D, Xiaoqian Wu

Chair: Yoav Weiss

Scribe: Tim Dresser

Next Meeting: Monday November 5th at 11:00am PST

Yoav: Please take a look through the agenda
<https://www.google.com/url?q=https://docs.google.com/document/d/1bYMLTkjcyOZR5Jt3vrulzMSoS32zOFtwyH33f6hW_C8/edit?ts%3D5ba207d4%23&sa=D&ust=1539722904298000>,
and write yourself down as a scribe for some topic.

Triage

Performance-timeline

https://github.com/w3c/performance-timeline/issues/105
<https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/105&sa=D&ust=1539722904299000>

Nicolas:

Paint timing may fire very late due to a page being backgrounded.

The current visibility API doesn’t look because you can’t see historical
entries.

Yoav:

This shouldn’t block the performance timeline spec.

Phillippe:

What about out of viewport resources?

Todd:

There are also out of viewport iframes etc. Maybe we want a general
“performance may be impacted” flag.

Yoav:

What’s the visibility state of out of viewport iframes?

Todd:

Currently if the tab is visible, all frames are considered visible.

This is also discussed in this
<https://www.google.com/url?q=https://github.com/w3c/page-visibility/issues/29&sa=D&ust=1539722904302000>
page
visibility issue.

Yoav:

A page visibility entry which gets buffered could address the page
visibility issue, but this doesn’t fix the iframe case.

Nate:

What if for each entry, we have a boolean “was this potentially impacted by
throttling”?

Todd:

There are a lot of heuristics at play here though, which are changing all
the time. We might want to focus on specific occurrences that devs should
be able to understand.

Ryosuke:

Why do we need a new API?

Yoav:

We need a new API to track visibility state before JS has been executed.

Ryosuke:

Just executing this script shouldn’t be expensive. What’s the use case
where the user changes visibility before the page paints.

Yoav:

The page is loaded in the background, and so javascript to monitor
visibility doesn’t get to run until we switch to the tab.

Gilles D:

We need visibility on the timeline.

https://github.com/w3c/performance-timeline/issues/81
<https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/81&sa=D&ust=1539722904306000>

Yoav:

This adds the buffered flag. We want to unite the buffering logic across
all specs. We may want to postpone this until the big navigation / resource
timing unification in L3.

This logic should live in the performance timeline.

Let’s rip out the buffered flag in L2.

Instead of buffering until onload, have a maximum number of entries.

Nic:

There’s no reason for user timing to have a max buffer size. The same model
may not apply everywhere.

Yoav:

We could tweak the size per entryType, but keeping the same model for all
buffered entryTypes.

For user timing, we could set no buffer limit (or set it to no limit).

Todd:

Who is this issue assigned to? We need someone to own this.

Yoav:

I’ll drive it.

Todd:

Core goal - give analytics providers the data they want, while not bloating
the web.

Resource Timing punted for this week.

Scheduling API - deck
<https://www.google.com/url?q=https://docs.google.com/presentation/d/1NSZZe7qEOX4qYHjvTz0VTlwBoj368ZrDcMCzwpifPYk/edit?usp%3Dsharing&sa=D&ust=1539722904310000>

Shubhie:

We’ve dug into existing schedulers: React, Google Maps,

React schedules work on rAF (raced with setTimeout). The scheduler then
postMessages itself to execute the next task.

4 priority levels: immediate, user blocking, normal, idle.

Each priority has an “expiration time”. Expired tasks are the most
important.

Tries to do as much work as possible until the frame deadline comes up. All
expired tasks are executed synchronously.

Dynamically figures out frame rate, starting at 30fps.

Nate:

This all sounds right. Planning to add a fifth priority “logging”. It’s a
bit more important than idle, but shouldn’t block anything user visible.

Ryosuke:

You mentioned updating priorities. What updates these priorities? Are they
only updated in the scheduler itself, or in user code?

Nate:

Only user code.

Shubhie:

The framework drives the priority. User code doesn’t even know about the
scheduler.

Todd:

The React framework chooses which callbacks should have which priority.

Nate:

Aim is to have the React Scheduler used for non-React code.

Shubhie:

The Google maps scheduler is similar, it also uses rAF to drive the
scheduler. It classifies work into 4 categories: Input, Animation,
Rendering, Other

Input, Animation & Rendering are all executed synchronously within rAF.

Other is executed in an asynchronous way using postMessage.

Does frame rate throttling, especially during startup / transition to 3D
earth view.

Todd:

The details are going to be pretty hairy.

Ryosuke:

This feels a lot like resource loading before the fetch spec existed.

Figuring out how these APIs fit together feels important.


On Thu, Oct 11, 2018 at 11:35 AM Yoav Weiss <yoav@yoav.ws> wrote:

> Hello all,
>
> The next WebPerf WG call will be on Tuesday next week, October 16th 11am
> PST. (with a *different hangout *link
> <https://hangouts.google.com/call/pt6GicuSLwEZvrc3semFAAEI>, see below)
>
> The call will be a mix of subjects, as we want to talk about TPAC's F2F
> agenda, discuss some issues as well as complete the discussions from last
> week regarding the Scheduling API.
>
> Tentative agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.ohc3prc50j0w>
> :
>
>    -
>
>    TPAC agenda
>    <https://docs.google.com/document/d/1bYMLTkjcyOZR5Jt3vrulzMSoS32zOFtwyH33f6hW_C8/edit#>
>    -
>
>    Performance-timeline
>    -
>
>       https://github.com/w3c/performance-timeline/issues/105
>       -
>
>       https://github.com/w3c/performance-timeline/issues/81
>       -
>
>    Resource Timing
>    -
>
>       https://github.com/w3c/resource-timing/issues/166
>       -
>
>       https://github.com/w3c/resource-timing/issues/165
>       -
>
>       https://github.com/w3c/resource-timing/pull/163 vs
>       https://github.com/w3c/resource-timing/pull/168
>       -
>
>    Scheduling API
>
>
>
> Feel free to add to the agenda if you there's something else you want to
> discuss, and we'll see how we fit that in.
>
> Note that due to last call's hangout mishaps, we'll be using a *different
> hangout link <https://hangouts.google.com/call/pt6GicuSLwEZvrc3semFAAEI>*.
> Please try to connect a couple of minutes before and let me know on IRC or
> elsewhere if you're running into any issues on that front.
>
> See y'all next week!
> Yoav
>

Received on Tuesday, 16 October 2018 19:54:56 UTC