Minutes [was: Re: [4/12/17] webperf group call @ 10AM PST]

Hi all,

The minutes of the 4/12/17 webperf group call are available as:
https://www.w3.org/2017/04/12-webperf-minutes.html <https://www.w3.org/2017/04/12-webperf-minutes.html>

See also:
=============
Web Perf WG weekly call

12 April 2017

Attendees

Present
igrigorik, spanicker, nicj, cvazac, plh, toddreif, nolan, yoav, xiaoqian
Regrets
Chair
igrigorik
Scribe
yoav
Contents

 • Topics
  • Performance Timeline
  • Memory Pressure
  • High resolution time
  • PerformanceObserver
  • NavigationTiming
  • Page Visibility
  • Beacon
  • RequestIdleCallback
 • Summary of Action Items
  • Page Visibility -> PR
  • Beacon -> CR
  • RequestIdleCallback -> PR
 • Summary of Resolutions
igrigorik: hello!

plh: hello:)

plh: I finally managed to setup the automatic bikeshed on w3c/longtasks

Charlie: PRing the {buffered:true} at https://github.com/w3c/performance-timeline/pull/76

spanicker: Concerned about no upper-limit on buffering

cvazac: Planning to cap it at 1000

spanicker: should the buffer cap be part of the spec?

should there be a global buffer cap for all entries?

cvazac: planning to limit only server timing entries to 1000

nicj: should the buffer be limited if we're killing it at onload?

spanicker: would it be cleared at first observer?

cvazac & igrigorik: no, since second observers should have access

cvazac: buffered true eliminates some races conditions vs. getEntriesByType()

igrigorik: proposal to add a new flag to registration that defaults to true. need to read through it

cvazac: we're all good for serverTiming. Need to discuss PerformanceTimeline changes and there are missing hooks

igrigorik: Let's take this to the PR and find the right plumbing

Memory Pressure: https://github.com/spanicker/device-ram

Shubhie: Starting a prototype and working with gmaps and other devs for getting early feedback

igrigorik: should we simplify the levels or add more?

spanicker: A single signal might not be enough, as devs may do different things based on pressure levels

also background and foreground matter as well. They can query visibility state, but adding it to the API can be convenient

igrigorik: is the discussion captured on the public repo?

spanicker: It'll be captured in the doc

igrigorik: we need the latest proposal up to date, so that rniwa can comment

toddreif: So you're prototyping in order to see how devs use it? Concerned that publishers may use this differently than Google/Microsoft properties

spanicker: G properties are not necessarily memory efficient

toddreif: Is mobile the main consumer? We think mostly of desktop

spanicker: Both. A lot of interest from emerging markets. But also desktop oriented interventions

toddreif: So the main question is the number of states?

spanicker: Yeah, but also maybe more prescriptive. Indicating memory pressure + You're in BG

igrigorik: So there's Memory Pressure (temporary state), overall memory (permanent) and "user wants a light experience"

yoav: should "light experience" be converged with the data saving mode? Different UI, but similar delivery mechanism and semantics

spanicker: memory is not the only factor. CPU also plays a major role

spanicker: but maybe better to start with individual signals

igrigorik: take a look at the docs and let's resolve offline.

toddreif: It's very easy to understand and implement memory pressure. amount of RAM may raise privacy concerns

spanicker: rounding will help?

toddreif: Not sure what's the solution, just raising a concern. If Chrome privacy will be happy, MS privacy folks are likely to follow

igrigorik: High resolution time

https://github.com/w3c/hr-time/issues/32

There's an issue with Firefox there

xiaoqian: In Chrome when you open a window you get the document, in Firefox the document returned is an empty document, which breaks the test. Might be a Firefox bug. Need to find a workaround

igrigorik: We may need to talk to annevk to see who's bug it is

Do we move the spec to PR?

toddreif: yes, we should

igrigorik: plh, can you help?

xiaoqian: I can

igrigorik: Performance Timeline

PerformanceObserver support in worker are lacking

spanicker: It looks like a conscious implementation decision

igrigorik: it's not clear why Chrome chose to omit support from workers

plh: doesn't work in Edge

toddreif: PerfObserver is under consideration

spanicker: should we push for perfObserver use?

igrigorik: There are new APIs that rely on it, so good time to push it. Also need to explain difference from buffering

toddreif: Just remember that IE11 will never get PerfObserver, so please caveat

plh: It won't get longtasks either

toddreif: yeah, but when moving older APIs, it requires feature detection

igrigorik: the buffer work cvazac is doing will make it simpler

igrigorik: should we file PR transition to L2?

plh: Would be nice to know the state for workers

igrigorik: we can check Safari implementation status and look at implementing on the Chrome side

yoav: idl files in WebKit indicate Worker exposed

igrigorik: might be enough for PR then

igrigorik: NavigationTiming

Timing-Allow-Origin tests

igrigorik: comma separated list and several headers should be identical according to HTTP

will take another pass on the PR

toddreif: I'll take a look as well

NavTiming2 is in both Edge and Chrome57, so we can transition to REC

Only issue is in reporting URL in name, which is shipping in 57, and got no compat issues

spanicker: as shipped right now, only available after onload. The next fix is to expose it earlier, which will land in 59

toddreif: will look if usage increased since Chrome shipped. Or maybe not, since it's hard to tell

only small differences: Edge doesn't have secureConnectionStart, Firefox has most of the support for 2 right. So Firefox and Chrome are the 2 implementations

igrigorik: Should it move to CR?

plh: should go along with ResourceTiming. We should move them together

igrigorik: in theory I agree, but will potentially stall the process. RT has many outstanding issues that we need to triage

so can hold NT2 back

toddreif: Are the blocking issues on that version?

igrigorik: not sure, we need to go over list and see which critical and which cosmetic

igrigorik: so let's do that and then decide if we move both or only NT

igrigorik: Page Visibility

Manual prerender test https://github.com/w3c/web-platform-tests/pull/5185#issuecomment-288803532

good to land

toddreif: the test is testing the right behavior, but do we land the feature which is at risk?

toddreif: should work at IE11, but haven't tested yet

Edge has no intent to support prerender

igrigorik: should we land it as it's at risk?

toddreif: we should do that when the feature is required

plh: if you support prerender you should support the prerender visibility state. We should add a note that it might be removed in the future

igrigorik: how is that different from "at risk"?

igrigorik: I suppose that we land the test

plh: sgtm

plh: from a REC point of view, at risk can be removed. A note is just a warning for developers

igrigorik: so you propose we remove the "at risk" and add a note instead and transition that to PR?

plh: Yeah

igrigorik: wfm. Todd?

toddreif: ok by me as well

igrigorik: Next, Beacon

igrigorik: Need to file CR

plh: filed, but not yet approved

if all goes well, we can publish by tomorrow

WPT https://github.com/w3c/web-platform-tests/pull/4024

toddreif: dev that pushed it is the one that implemented the Fetch updates. Will bribe dev to finish this

nicj: was there an update in spec regarding overall beaconed bytes?

igrigorik: updated to 64K in-flight bytes, which matches the Fetch spec

igrigorik: the implementation in Chrome has that limitation, but it'd change when Beacon is reimplemented over Fetch

igrigorik: RequestIdleCallback

should we move to CR?

toddreif: don't block on my review. 2 implementations with Firefox and Chrome

igrigorik: we see good usage, and ready to file PR? Objections?

no objections noted

plh: will try to request the transition this week
=============

Thanks.

-xiaoqian

> On 12 Apr 2017, at 5:34 AM, Ilya Grigorik <igrigorik@google.com> wrote:
> 
> Hangout: https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg <https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg>
> 
> We started tracking agenda in a shared doc, for this week's agenda see: 
> https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit#heading=h.xjxyh9f7y43o <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit#heading=h.xjxyh9f7y43o>
> 
> If there are additional topics you'd like to discuss, please leave a comment in the doc!
> 
> ig