Re: [9/6/18] webperf (design) group call @ 11AM PST

Minutes from the call are now available
<https://docs.google.com/document/d/e/2PACX-1vQnwcAvH3yOfhGz86a2XrUUpIQNGmqezvkxfQlkp8Bimp5zB6-48US0B41xqpXV-6296JSsK8V8Sq5v/pub>
.

Copying them here for safe keeping.

WebPerfWG - Design call Sep 6th 2018 - minutes
September 6th @ 11 AM PST — Design

Agenda
<https://www.google.com/url?q=https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli%3D1%23heading%3Dh.4d24rgepjznb&sa=D&ust=1536267488150000>

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

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

Performance Observer proposal
<https://www.google.com/url?q=https://docs.google.com/presentation/d/1m-0_XzLQCj1_8ROvek1Wd7J_n3XOORhIcGXZHUVsqxE/edit?usp%3Dsharing&sa=D&ust=1536267488151000>

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
Page Lifecycle
<https://www.google.com/url?q=https://docs.google.com/presentation/d/1lqWh6rEnC0IqPq0yh7enAvW1LumxjhMdJO9reVI0-28/edit%23slide%3Did.g416a9628b7_0_153&sa=D&ust=1536267488154000>

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.

PerformanceResourceTiming enhancements to measure service workers
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/162&sa=D&ust=1536267488155000>

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
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/162%23issuecomment-418764525&sa=D&ust=1536267488156000>

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

See GitHub issues, we’ll tackle in next design call.
Resource Timing

Issue: https://github.com/w3c/resource-timing/pull/163
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/pull/163&sa=D&ust=1536267488158000>

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



On Wed, Sep 5, 2018 at 1:09 AM Ilya Grigorik <igrigorik@google.com> wrote:

> Hey folks.
>
> We have a design review call scheduled for this Thursday @ 11AM PST.
> Tentative agenda:
>
>
>
>    -
>
>    PerformanceObserver proposal: observe() entryType-specific parameters
>    -
>
>    Update on rollout status and data results for Page Lifecycle API
>    -
>
>    Overview on Scheduling API proposal
>
>
> Plus some smaller / administrative updates. If you have other topics
> you'd like to discuss, please drop them into the agenda [1]. See you on
> the hangout [2] this Thursday.
>
> ig
>
> [1] *https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.4d24rgepjznb
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.4d24rgepjznb>*
>
> [2] https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg
>