W3C home > Mailing lists > Public > public-web-perf@w3.org > May 2018

Web Performance Design notes 2018-05-03

From: Philippe Le Hégaret <plh@w3.org>
Date: Thu, 17 May 2018 13:59:53 -0400
To: "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <aae862fb-cccd-cf17-68e0-88bf490ae274@w3.org>
Web Performance: Design Call
----------------------------

Surfacing partial records
-------------------------

doc: 
https://docs.google.com/document/d/1kbTHehU-V6Op5gcq58BlQErKTobo44ONWdz36Tkbmmg/edit

npm@: proposal is to expose updates to RT attributes via PerfObserver
... add "incremental" flag to PO registration
... there is a question about how general should be
... the idea behind new flag is that we are changing what entries are 
delivered

yoav: for what other entry types does it make sense to do incremental?
... e.g. long tasks is only relevant when we know all the info

yoav: one concern is that the developer would have to figure out what 
changed themselves

rniwa: would we create new entries, or redispatch same entry?
... should we create new entry?

toddreif: today people pull NT entries and diff themselves
... they would run the same code to do diffing
... one question is whether we need to solve this (we may not)
if we had a separate entry, what would it contain?
... MutationObserver is a good example to look, which allows you to 
observe changes to attributes, etc.

Update on performance.memory
----------------------------

eric: proposal is under active discussion
... problem: memory has tragedy of the commons issue
... websites and developers make unintentional decisions that cause 
unecessary memory usage
... the goal is to provide a API to allow developers to do A/B releases 
to identify regressions
... e.g. performance.memory satisfies following property: you have a 
baseline, you add large-K DOM nodes or other elements, and with high 
probability the browser tells you that you're using more memory
... there are also privacy/security concerns: it's a non goal to provide 
exact measurement for individual observations, but in aggregate we want 
a useful signal

panagiotis: would this only be useful for large sites?

yoav: this API should be useful for torso and tail too - e.g. long lived 
sites (PWAs, etc)

rniwa: one gotcha is that many sites  are using too much memory due to 
3P deps

erik: we are focusing on 1P use case today, to allow them to detect 
issues in their code
... AI: I can write out some specific examples where we found 1P 
problems, where a signal we're describing here would be useful
... there are other problems in this space that we could solve (e.g. 
3P), but I think we should scope ourselves here to start

yoav: any stats of existing Chrome API?

tdresser: ~20% of pageloads on windows

rniwa: what resolution do we need?

erik: in O(~hundreds kb)
... mitigations: normalized noise in the values, and quantize in time domain

rniwa: we don't have capability to isolate a site into a single process 
/ measure the exact usage of single site given iframes, etc.

todd: current draft is overspecified
... we should define memory as hint signal for growth
... with examples of what moves that needle
erik: yep, I'll update the current spec
panagiotis: if you're updating the spec, there are some points in the 
moz thread (3 concerns) that would be good to address as well
erik: in hindsights, current draft is too Chrome specific, I'll work on 
updating it to abstract and pair down what the asks are
rniwa: also, a list of known problems and use cases, so we can evaluate 
design decisions
erik: will do
Received on Thursday, 17 May 2018 18:00:15 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 17 May 2018 18:00:15 UTC