https://docs.google.com/presentation/d/1HGBOAfVhmWoyOt2ETk-1Y2dOvuMyRnQ5AF7VrPBvfX0/edit#slide=id.g4506b1db01_0_77
Post by Yoav WeissThanks 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>
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.
This shouldnât block the performance timeline spec.
What about out of viewport resources?
There are also out of viewport iframes etc. Maybe we want a general
âperformance may be impactedâ flag.
Whatâs the visibility state of out of viewport iframes?
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.
A page visibility entry which gets buffered could address the page
visibility issue, but this doesnât fix the iframe case.
What if for each entry, we have a boolean âwas this potentially impacted
by throttlingâ?
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.
Why do we need a new API?
We need a new API to track visibility state before JS has been executed.
Just executing this script shouldnât be expensive. Whatâs the use case
where the user changes visibility before the page paints.
The page is loaded in the background, and so javascript to monitor
visibility doesnât get to run until we switch to the tab.
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>
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.
Thereâs no reason for user timing to have a max buffer size. The same
model may not apply everywhere.
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).
Who is this issue assigned to? We need someone to own this.
Iâll drive it.
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>
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.
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.
You mentioned updating priorities. What updates these priorities? Are they
only updated in the scheduler itself, or in user code?
Only user code.
The framework drives the priority. User code doesnât even know about the
scheduler.
The React framework chooses which callbacks should have which priority.
Aim is to have the React Scheduler used for non-React code.
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.
The details are going to be pretty hairy.
This feels a lot like resource loading before the fetch spec existed.
Figuring out how these APIs fit together feels important.
Post by Yoav WeissHello 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
<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