- From: Philippe Le Hegaret <plh@w3.org>
- Date: Tue, 28 Apr 2015 16:48:13 -0400
- To: public-web-perf <public-web-perf@w3.org>
(apologizes about not sending those earlier)
Available at
http://www.w3.org/2015/04/01-webperf-minutes.html
Text version:
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-web-perf/2015Mar/0046.html
See also: [3]IRC log
[3] http://www.w3.org/2015/04/01-webperf-irc
Attendees
Present
[Microsoft], +33.1.56.69.aaaa, Plh, +657888aabb, yoav,
Ilya, +1.310.310.aacc, mbp
Regrets
Chair
SV_MEETING_CHAIR
Scribe
plh
Contents
* [4]Topics
1. [5]recharter
2. [6]Resource Hints
3. [7]Performance Timeline
4. [8]setImmediate
5. [9]Preload
6. [10]Triage/discuss issues
* [11]Summary of Action Items
__________________________________________________________
<trackbot> Date: 01 April 2015
recharter
[12]https://w3c.github.io/charter-webperf/
[12] https://w3c.github.io/charter-webperf/
plh: pay attention to section 2
ilya: how do we say that we want to revisit some of the old
specs?
plh: we can make a general statement in that sense
ilya: do you guys see anything missing?
yoav: things that were discussed at the velocity summit
... visibility observers
... not sure we have the answer yet
... or something in that range
todd: in scope of page visibility?
ilya: seems beyond PV, and we have frame timing
... other things that should be on the list? please open issues
in the repo
plh: should strike the sentence on member only list
Resource Hints
todd: we have prefetch in html5
... then prerender, preload, etc.
... preload was targeted to solve many of them
... should we focus preload?
... even on prefetch, the wording is vague
... should we pull it in?
ilya: look into issues on preloading
... don't think there are concerns to use prefetch/prerender
... initial reason was inconsistency between browsers
... but we could make them better
... I'm ok with going back to those
yoav: totally behind that
... future friendliness argument seems the best option
... ok to go back to prefetch/prerender
ilya: will update resource hints
... refine preconnect/prefetch/prerender
... that will simplify a lot of things
[13]http://microformats.org/wiki/rel-prerender
[13] http://microformats.org/wiki/rel-prerender
todd: already pulled travis with this
... his take was that we should update the html spec or pull it
from it
ilya: I prefer separate spec
... but we'll need the right hooks
<igrigorik> [14]https://github.com/w3c/preload/pull/15
[14] https://github.com/w3c/preload/pull/15
<igrigorik> [15]https://github.com/w3c/preload/pull/16
[15] https://github.com/w3c/preload/pull/16
Ilya: preload/#15 makes as attribute mandatory
... feedback from intent to implement that it opens interested
side effect
... this will also simplify the processing
Yoav: I like it because missing 'as' would be a common
authoring mistake
... if it resolves in a priority change, that would be
difficult to detect
... so ignoring the hint is absent is better imho
Todd: by forcing the user to make the choice, we avoid the
authoring issue. right?
Ilya: correct
... if somebody specified an invalid context, we shouldn't
initiate the request
... friendly warning and ignore
... like an invalid link tag
yoav: separate issue: are we doing sync or async fetch request?
... if we're building the link dynamically, we don't want to
create a situation when the img gets invalidated because of
order
ilya: preload/#16 is supposed to address that
yoav: what happens if as is changed dynamically?
... do we re-apply CSP
ilya: doesn't affect CSP
... but it may reprioritize the resource
... I'll update the language for #15
... then merge
todd: setting the link and the as might cause issue?
yoav: let's merge and figure out corner cases
ilya: I'll merge #16
yoav: I have an issue related to media attribute and viewport
setting
... concern is that allowing resources to be preloaded based on
media attribute, in some cases, we don't know the actuall
viewport dimension when we're fetching the resources
ilya: can we set the viewport via header?
yoav: not as a meta
... I don't think we should do this
... viewport should be saner
... discussion on blink-dev didn't go very far
... @viewport is over engineered
... it's possible for authors to shoot themselves in the foot
ilya: please open a bug
yoav: will do
... as well as sync question
Performance Timeline
todd: performance observers to performance timeline
[16]https://github.com/w3c/performance-timeline/pull/8
[16] https://github.com/w3c/performance-timeline/pull/8
Ilya: I need to update the PR
... current performance observers provide a callback
[17]https://lists.w3.org/Archives/Public/public-web-perf/2015Fe
b/0045.html
[17] https://lists.w3.org/Archives/Public/public-web-perf/2015Feb/0045.html
[18]https://lists.w3.org/Archives/Public/public-web-perf/2015Fe
b/0030.html
[18] https://lists.w3.org/Archives/Public/public-web-perf/2015Feb/0030.html
[...]
<igrigorik>
[19]https://github.com/w3c/navigation-timing/pull/10
[19] https://github.com/w3c/navigation-timing/pull/10
<ToddReifsteck>
[20]https://github.com/w3c/navigation-timing/pull/10/files
[20] https://github.com/w3c/navigation-timing/pull/10/files
<ToddReifsteck>
[21]https://github.com/w3c/resource-timing/pull/18
[21] https://github.com/w3c/resource-timing/pull/18
<igrigorik> new version:
[22]https://cdn.rawgit.com/w3c/navigation-timing/move-perf-inte
rface-definition/index.html
[22] https://cdn.rawgit.com/w3c/navigation-timing/move-perf-interface-definition/index.html
setImmediate
todd: number of usages are increasing
... 1.7% usage
<igrigorik> plh: see above for readable version of
[23]https://github.com/w3c/navigation-timing/blob/move-perf-int
erface-definition/index.html
[23] https://github.com/w3c/navigation-timing/blob/move-perf-interface-definition/index.html
todd: it's existence stats
plh: any browser counter stats?
todd: could pull that in a month
[24]https://lists.w3.org/Archives/Public/public-web-perf/2013Au
g/0051.html
[24] https://lists.w3.org/Archives/Public/public-web-perf/2013Aug/0051.html
plh: would be helpful to go back to those threads before
recycling again
yoav: blink-dev resistance based on implementations and fear of
abuse
... would be useful to summarize
todd: would be valuable to have a few customers that have use
cases
... where there is gain
<scribe> ACTION: Todd to come back with data related to
setImmediate [recorded in
[25]http://www.w3.org/2015/04/01-webperf-minutes.html#action01]
<trackbot> Created ACTION-155 - Come back with data related to
setimmediate [on Todd Reifsteck - due 2015-04-08].
Preload
zaki, close agendum 5
Triage/discuss issues
[26]https://github.com/w3c/performance-timeline/pull/9
[26] https://github.com/w3c/performance-timeline/pull/9
ilya: would it make to define a more general concept:
getEntriesThatHaveThisAttributeOrProperty
... so that we can annotate our entries in the futre
todd: makes a lot of sense
... will have to talk to developers on implementations
plh: how far to go in phrasing the question?
ilya: I'll write some use cases for it
... it does open a lot of possibilities
... to push more records
[27]https://github.com/w3c/webperf-dashboard
[27] https://github.com/w3c/webperf-dashboard
[28]http://w3c.github.io/webperf-dashboard/
[28] http://w3c.github.io/webperf-dashboard/
Summary of Action Items
[NEW] ACTION: Todd to come back with data related to
setImmediate [recorded in
[29]http://www.w3.org/2015/04/01-webperf-minutes.html#action01]
[End of minutes]
Received on Tuesday, 28 April 2015 20:48:17 UTC