[minutes] 20150527 Web Performance

Available at
   http://www.w3.org/2015/05/27-webperf-minutes.html

Text version:
               Web Performance Working Group Teleconference

27 May 2015

    See also: [2]IRC log

       [2] http://www.w3.org/2015/05/27-webperf-irc

Attendees

    Present
           Todd, Yoav, Ilya, Justin, Plh, Michael (last 10 minutes)

    Regrets
    Chair
           plh

    Scribe
           plh

Contents

          1. [4]attribute filtering
          2. [5]setImmediate usage
          3. [6]frame timing + :visited
          4. [7]is domLoading useful?
          5. [8]preconnect - shipping the non-contentious parts
          6. [9]Next meeting
      __________________________________________________________

    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
    [11]performance-timeline/#11

      [11] https://github.com/w3c/performance-timeline/pull/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 [12]frame-timing/#40

      [12] https://github.com/w3c/frame-timing/issues/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
    [13]navigating-timing/#13

      [13] https://github.com/w3c/navigation-timing/issues/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

    Ilya to report on Ryan's progress and Mozilla preconnect
    feedback

   Next meeting

    Same time, same place next week. Ilya will send the agenda.

Summary of Action Items

    [End of minutes]

Received on Wednesday, 27 May 2015 21:02:55 UTC