- 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