- From: Philippe Le Hegaret <plh@w3.org>
- Date: Mon, 14 Sep 2015 10:46:26 -0400
- To: public-web-perf <public-web-perf@w3.org>
Available at:
http://www.w3.org/2015/09/09-webperf-minutes.html
Text version:
Present
plh, yoav, ilya, todd, brandon
Regrets
Chair
Ilya
Scribe
plh
Contents
Topics
requestAnimationFrame
Obsoleted EDs
requestIdleCallback
Resource Timing
Navigation Timing
Page Visibility
Summary of Action Items
requestAnimationFrame
Todd: didn't review the HTML spec to see if they have everything there
but not a blocker
Resolved: Published a Working Group Notes pointing to the HTML spec for RAF
Obsoleted EDs
plh: took care of that a week ago. should be fine now
... (if not, scream)
requestIdleCallback
<igrigorik> https://github.com/w3c/requestidlecallback/pull/16
plh: request for FPWD sent
Ilya: where should the test PR go?
plh: indeed, should go to WPT
<igrigorik> https://github.com/w3c/resource-timing/issues/17
Resource Timing
Todd: I'll look into RT/#17
<igrigorik> https://github.com/w3c/resource-timing/issues/12
Todd: no pushback from our security folks
Ilya: meaning exposing the timestamp isn't an issue?
Todd: with NEL, would we want this to be exposed?
Ilya: Resource fetches should be reported to the page
... while error logging sits on top of that, ie ifr the fetch fails,
what's to know about it
https://github.com/w3c/resource-timing/issues/21
Ilya: the web platform has a lot of transparent fetches (redirects, etc.)
... but would be good to surface
... today, you can infer than a redirect happened
... if we can surface the number of redirects, is that a bad thing?
... for perf, we don't have visbility into this
... despite the impact
... we need to clarify fetch first before we can define the behavior
Yoav: the preflight case would be safe to expose
... while redirects are more risky (don't have a specific case in mind)
Ilya: we want to simplify and improve our reporting in RT
... if we can bundle them, it would make our model much easier
Todd: the key in security issue is exposing data from the URL
... if the data wasn't exposed previously, that would be the risk
Ilya: we could choose not to reveal the URL, only the fact that a fetch
happened
... at least, you'll get your waterfall correct
Todd: we probably need to kick the fetch thread
Ilya: I'll follow
Navigation Timing
Todd: I was looking into this and didn't find the case where we would
have multiple documents
https://github.com/w3c/navigation-timing/issues/1
<ToddReifsteck> TAO for Nav timing--
https://github.com/w3c/navigation-timing/issues/20
(summary: assign the issues to plh and get him to do the
navigation-timing rewrite :)
<igrigorik> https://github.com/w3c/page-visibility/issues/8
http://w3c.github.io/page-visibility/#hidden-attribute
<yoav> Here's the relevant Blink work:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/_SRHebxivJs
http://www.w3.org/2014/10/pv2/iframe-hidden.html
Page Visibility
https://github.com/w3c/page-visibility/issues/12
Todd: I'll create an issue to see if we can remove hidden
http://microformats.org/wiki/rel-prerender
Ilya: we define the relationship in the wiki
... we'll put more details in resource hints
... but we never talk about prerender mode
... we never define it
plh: I'll open an issue on resource hints to define prerender mode
Ilya: I'll take care of it
[adjourned]
Received on Monday, 14 September 2015 14:46:33 UTC