Present: Tim Dresser, Yoav Weiss, Nicolás Peña, 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, and write yourself down as a scribe for some topic.

Triage

Performance-timeline

https://github.com/w3c/performance-timeline/issues/105

Nicolás: 

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 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

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

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.