Web Performance Working Group Teleconference

Boris's item will be done by email.

attribute filtering

Justin: using a filter object, we filter the entries. by people want to use a generic object
... but it doesn't mean all properties are relevant
... so we try to specifiy the properties that are important
... so people will make mistake, like passing a window object
... bad things can happen
... when we define a dictionary, we define a specific set of properties
... we would then allow the user to use the returned array and use filter() on it
... counter argument is performance
... we don't know any perf issue in IE

Todd: in perf observers, we use lazy evaluation. we don't marshall it unless it's needed

Justin: WebIDL doesn't support generic property bag. we would have to define the algorithm to access the properties of the object.

Ilya: the only question was interop with User Timing
... some request to extend User Timing with arbitrary attributes
... if we go down that path, we'll have custom attributes
... would be nice for users to filter those
... if we namespace them however, the user would have to filter manually

Justin: we could have a filter object to be strongly type, with custom keys and values as DOMString

Plh: only DOMString for values?

Justin: yes, the convertion should work fine

Ilya: sounds like we're ok with typed dictionary, with current defined attributes of all entry types
... for the sequence, won't add it yet but we could extend with .keys/.values in the future if needed

Ilya will provide a revised pull request for performance-timeline/#11

setImmediate usage

Todd: we're got telemetry for setImmediate
... 4% for navigation in the past 2 weeks
... higher that we expected in fact
... so clearly it's used

Ilya: should we take it to the list?

Todd: ok

Todd will follow up on list regarding setImmediate usage

frame timing + :visited

Plh: [3 path forward]

Justin: people timing differences
... if we filter out, they may still be able to detect

Todd: 2 timing info: render and composite

Justin: you can imagine forcing complex style and determine timing information
... , like transition state change

Yoav: so this applies to new links added to the page anyway

Ilya: if you try to apply complex style to generate timing attack, we'll filter those out

Justin: we can provide a list of our filtered properties
... anything that change shapes will be suppressed
... dotted borders, etc.
... will have to go back to check

Todd: would be helpful to mention that

Ilya: so IE does not update the link if href changes
... did it cause any dev feedback?

Justin: depending on our you recycle the DOM, you'll get the update
... for visited links, we do not render visited and then we go back and rerender them
... we can provide more details
... if you always rerender the links, you can still put 10,000 of them and measure the rendering difference

Ilya: one solution was to disable link painting if frame timing is enabled, but it was ruled out because FT should desactive other features

Justin: [on the use cases for :visited] it doesn't seem unreasonnable that, when the page is live, the painting based on user history is disabled
... if you click on a link, we'll set the visited flag on the click action

Ilya: so, depending on the DOM update path, you take the history into account?

Justin: the only thing that would update the link state would be user update interaction
... we're already disabling those state in private mode

Todd: we'll follow up in the github issue

Todd/Justin will provide an update to frame-timing/#40

is domLoading useful?

Todd: domLoading is internal to implementation
... you don't learn much from this value
... I would proposing to get rid of it
... but Ilya indicated that it will cause some pain
... so proposal is to update the spec with a Note
... ie deprecate via spec

Ilya: that's the minimum pain. doesn't solve the issue but it will be documented

Yoav: I'm ok with spec update but should we add console messages as well?

Ilya: might be difficult because you're getting a bag of values
... we should add the note in the spec and the UA is free to add the console warning

plh: I'll propose a note

Todd: in Edge, it will be the same as responseStart

Ilya: I'm curious how it will impact developers
... we should announce the change in Edge on the list
... see if people scream on the list, and revisit depending on feedback

Plh to propose a Note for domLoading in navigating-timing/#13

preconnect - shipping the non-contentious parts

Yoav: currently, we'
... maybe we shouldn't block shipping preconnect for non-anonymous connection

Ilya: preconnect is a hint. as such, you're not guaranteed anything, ie not breaking contracts
... my concern is creating unnecessary confusion
... like if a dev uses for webfont, it won't work and folks will be confused
... firefox has plan to ship preconnect without cross origin in 39
... I pinged them and waiting for a reply
... so confusion and perception issue on my side

Yoav: I think we can mitigate it
... by making is clear it doesn't work for fonts

Ilya: how long do we need to resolve the privacy link-ability question?
... I'll nudge Ryan and see if we can get something up
... for v1, we could land prefetch, and have a separate issue for preconnect