W3C home > Mailing lists > Public > public-web-perf@w3.org > April 2015

[minutes] 20150429 Web Performance

From: Philippe Le Hegaret <plh@w3.org>
Date: Wed, 29 Apr 2015 16:05:49 -0400
Message-ID: <5541399D.4000004@w3.org>
To: public-web-perf <public-web-perf@w3.org>
Available at

Text version:

                             Web Performance

29 Apr 2015


       [2] https://lists.w3.org/Archives/Public/public-web-perf/2015Apr/0021.html


           Yoav, Ilya, Plh, Todd, Michael





      * [3]Topics
          1. [4]new draft for Performance Observer
          2. [5]clarifying behavior around failed fetches in
             Resource Timing
          3. [6]Refactoring Preload and Resource Hints to remove
          4. [7]"grouping" of performance entries
          5. [8]Issues
          6. [9]Frame Timing
          7. [10]Next meeting
      * [11]Summary of Action Items

new draft for Performance Observer

    Ilya: how do we want to proceed to land it in performance
    timeline description?
    ... I'd like to be more thorough on how events are recorded


      [12] https://github.com/w3c/performance-timeline/pull/10

    scribe: when do we emit the records?
    ... ie, initialize the entries, append it to the buffer, ...,
    and then deliver it to the observer once it's finalized

    plh: that means the NT record would be submitted after the
    loadevent is completed

    Todd: agree that entries should only appear once they're
    ... RT and NT entries appear before their entries are filled.
    was it intentional or not?

    Ilya: by product of implementation
    ... suspect we can't change it

    Yoav: also use cases to estimate network performance
    ... earlier is better

    Ilya: we shouldn't make promises that these entries are
    synchronous. we want to move the devs away that should rely on
    delivrance of the entries
    ... no guarantee it will be after the delivery of the resource

    Yoav: use case is network estimation
    ... hard time to expose network information to developers
    ... having that info early on will allow to do bandwidth
    ... and use different loading logic based on result
    ... not sure if it's the best tool to do that
    ... if it relies on implementation details, I agree we
    shouldn't expose it

    Ilya: next step? merge the PR and iterate?

    Todd: agreed

    Ilya: I'll merge the PR and start a new one then

    Plh: can we publish and get more eye balls?

    Resolved: ok to publish a FPWD for Performance Timeline 2

clarifying behavior around failed fetches in Resource Timing


      [13] https://github.com/w3c/resource-timing/pull/19

    Ilya: current spec doesn't say anything on failed fetches
    ... we should surface them
    ... if http server broke, dns would be there but remaining

    todd: Edge surfaces most of them, just a couple of exception

    Plh: ok to merge?

    Todd: yes

    Yoav: what about redirect?

    Ilya: I'll open an issue on resource timing then


      [14] https://github.com/w3c/navigation-timing/issues/11

    Todd: I'll take that one

    Ilya: can we have guidelines for editing the html in webperf?

    Plh&Todd: sure

Refactoring Preload and Resource Hints to remove "loadpolicy"

    Ilya: resource hints: removed loadpolicy and have
    ... we're now adding optional attributes
    ... the probability attribute


      [15] https://github.com/w3c/resource-hints/pull/27

    Ilya: can we merge this one?

    All: ok


      [16] https://github.com/w3c/preload/pull/17

    Ilya: one issue with fetch at the moment. the as attribute will
    be passed to fetch

    Yoav: not sure why why the response has to be tainted in the
    ... what's blocking this from having as set a context that is
    different from the fetch context?

    Ilya: if there is a CSP policy with "only img from host", you
    shouldn't be able to circumvent the policy
    ... we're stuck on the appropriate header and other settings
    ... for preload, we could block on that
    ... or put some clause in the spec and merge

    Yoav: we don't have to block in terms of implemetations
    ... for preload, as can do whatever we think it's right
    ... I don't think the circumvention applies to preload

    Ilya: preload just do a cache thing and then it gets enforced
    when used by other elements

    Yoav: ok we can put a place holder in the spec

    Ilya: I'll clarify that
    ... and then merge 17

    Resolved: FPWD for preload

"grouping" of performance entries


      [17] https://github.com/w3c/performance-timeline/pull/9

    Ilya: thinking we can ignore that one. original proposal was to
    have a common id
    ... but folks would like to see a more general purpose
    ... ie group by properties
    ... e.g. getEntries(site, value)

    Todd: make sense, looking at the use cases

    Ilya: for frame timing, we have a source frame number
    ... for things like redirect, we'll have to create a fetch id

    Plh: did you talk to Anne about the idea of fetch id?

    Ilya: nope
    ... that's pseudo-code
    ... same return value as getEntriesByType

    plh: howe about getEntries({type: entryType})
    ... getEntries({type: entryType, name: entryName})

    <ToddReifsteck> Yoav: getEntries({type: 'resource'}) to get
    resource timings

    plh: what about getEntries({foo: "bar", type:"resource"}) ?

    Ilya: would return empty list
    ... I'll close PR9 and open a new one



      [18] http://www.w3.org/2010/webperf/board/

    plh: we're not making progress on our backlog of issues. let's
    elect issues in upcoming calls so we can move forward.

Frame Timing

    Ilya: talked to Hixie about adding some mechanism and he is ok
    if we can get a +1


      [19] https://lists.w3.org/Archives/Public/public-web-perf/2015Apr/0005.html

    Todd: I'll go talk to Travis and see if we can +1 this

Next meeting

    Plh: next one in two weeks
Received on Wednesday, 29 April 2015 20:05:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 29 April 2015 20:05:51 UTC