- From: Philippe Le Hegaret <plh@w3.org>
- Date: Wed, 29 Apr 2015 16:05:49 -0400
- To: public-web-perf <public-web-perf@w3.org>
Available at
http://www.w3.org/2015/04/29-webperf-minutes.html
Text version:
Web Performance
29 Apr 2015
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-web-perf/2015Apr/0021.html
Attendees
Present
Yoav, Ilya, Plh, Todd, Michael
Regrets
Chair
plh
Scribe
plh
Contents
* [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
"loadpolicy"
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
[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
completed
... 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
estimates
... 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
[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
empty
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
[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
prefetch/prerender
... we're now adding optional attributes
... the probability attribute
[15]https://github.com/w3c/resource-hints/pull/27
[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
[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
context
... 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
[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
mechanism
... 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
Issues
[18]http://www.w3.org/2010/webperf/board/
[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
<igrigorik>
[19]https://lists.w3.org/Archives/Public/public-web-perf/2015Ap
r/0005.html
[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