- From: Yoav Weiss <yoav@yoav.ws>
- Date: Tue, 16 Oct 2018 21:54:14 +0200
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CACj=BEhaExeD7inyuaQMKaOgFemHiJJY8OLkjOgE38+osguG6w@mail.gmail.com>
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