Present: Ilya Grigorik, Charlie Vazac, Panagiotis Astithas, Nic Jansma, Nicolás Peña, Doug Creager, Shubhie Panicker, Garrett Berg, Philip Walton, Tim Dresser, Ben Kelly, Yoav Weiss
Scribe: Yoav Weiss (mostly)
Ilya: Meeting at TPAC, there’s a link on the agenda, please add topics you want to discuss
Next call: September 20th - Triage call
Still iterating on the charter, waiting on feedback from Todd
Nicolás: want entry type specific parameters for PO
Currently have a dictionary and a `buffered` boolean.
No way to pass parameters specific to long tasks (and other types).
For long tasks we want to add a different threshold.
Could have passed it by other means but it would have been confusing, and weird.
The proposal is to also include parameter dictionaries for the different entry types, with their own parameters.
Every time we would add a new entry type, we’d define a dictionary IDL that goes with
Still not sure if entry types should include all the observed entry types, or including the parameters for them is enough.
Tim: IIRC, no one shipped the buffered flag, so still reasonable to change
Charlie: what if there’s a flag that applies to all entry types, do we include it for each dictionary?
Nicolás: yes
Yoav: maybe add an “all” dictionary to cover parameters that apply to all entries
Charlie: using “all” also avoids collisions between parameters and dictionary names
Nicolás: and specific entry parameters would override the “all” values
Ilya: we can also name it “default” to make it clearer
Phil: how common would it be for developers to want to register multiple observers with different options for the same entry type? Or would they create a single one with multiple different options?
Nic: We’re registering 3 PO, each looking at a single entry type, with different callbacks for each. Try to keep them separate.
Charlie: Do we also want to make the callbacks per entry type?
<discussion> users can have complex (or simple) callbacks to this with large switch statements at the top</discussion>
Nicolás: main motivation is to have entry type specific parameters
Nic: I like this proposal
Tim: you can imagine a future where you have entry types that have similar parameters
Nicolás: PR is already waiting for review
Shubhie: status is: API shipped in Chrome 68
A few remaining issues, a few API changes that will improve usage
The need for clientID and lostClientID would help with multiple tabs that some get discarded
Also need to make IDB play nice with freezes
Shipped in Android, experiments running on desktop
Freezing on android was an incremental process
Started with timers, then loading (tasks and resource fetches).
Saw good network and some CPU savings
Now experimenting with freezing all freezable task queues.
Things shared with the entire process (e.g. V8 task queue) can’t be frozen
We see significant CPU wins - 62% in Chrome 69
Translates into battery savings
Hard to see impact on top level metrics along the way, because we did freezing very incrementally on mobile (starting with timers, then loading, then more etc) so it was hard to see improvements on toplevel metrics; BUT we are seeing these improvements on toplevel metrics desktop (because it was not incrementally)..
Now looking if we need to make it more aggressive
Also exploring the feasibility of a BFcache - want perfect freezing even when going to the cache
Freezing on desktop is still on beta. So far experiment looks good with savings on cpu, memory, etc
May change once we hit stable
memory savings all across the board
Also seeing good improvements in foreground loading - 2-5% in FMP and FCP
Ilya: did you share the stats with webkit?
Shubhie : not yet.
Ben: Devs have difficulties seeing how the fetch event is handled inside the SW, and the timing spent in those operations. Seems like a small API change
Add attributes to the RT entry and populate them if the resource was served from SW
I’ve put examples in the issue
Yoav: Seems necessary. Also feels like an L3 thing
Ben: I guess we could try out the API with an origin trial if the spec is not ready to accept this
Ilya: There are also questions around TAO and what’s permitted to expose by default
Regarding urgency: are there customers demanding it?
Nic: we started to experiment with SW and SW instrumentation. Both for customers that have SW where we need to report on, as well as our own SW that we want to monitor. This would be great to get more insights into SW’s operation. Currently experimenting with other ways to get info out of SW.
Phil: What about the more complex case where a navigation response is stitched together from cache, network etc? How would that be represented?
Ben: Had a more complex proposal that was able to surface more information there. Some of this can be done with postMessage but it’s not super elegant, overlapping URLs are confusing as you have no request ID, no way to get the client handle. I guess it’s weighing code that does that in every app vs. common native API that does most things.
Nic: things we ran into: what’s the cache strategy? Resource updates are currently not surfaced, even if can be postMessaged.
Ben: I can come up with a better definition of the use case. Sounds like TPAC would be a good place to discuss that.
Ilya: Generally this makes sense, but need to find the hidden complexities, and think about TAO and the security implications. Aiming for TPAC sounds good.
Charlie: proposal really cool. Like the server timing comparison. Also, cache API is also accessible from DOM. This maybe a good use case to inject arbitrary info into RT entries
See GitHub issues, we’ll tackle in next design call.
Issue: https://github.com/w3c/resource-timing/pull/163
Yoav: I rewrote the algorithm for what happens when the buffer is full.
… Nicolás reviewed and lgtm’ed, but Ryosuke had conflicting feedback
… bufferfull event can fire multiple times
… we have primary buffer that fills up, then we start filling up secondary buffer
… in Safari: secondary buffer is initially unbound, but when copying entries over
Panagiotis: we’ll get feedback from Mozilla.
Tim: as long as the developer is using PerfObservers, this behavior is not a huge concern to me