- From: Philippe Le Hegaret <plh@w3.org>
- Date: Wed, 21 Oct 2015 13:11:52 -0400
- To: public-web-perf <public-web-perf@w3.org>
Available at http://www.w3.org/2015/10/07-webperf-minutes.html Text version: Web Performance 07 Oct 2015 [2]Agenda [2] https://lists.w3.org/Archives/Public/public-web-perf/2015Oct/0003.html Attendees Present yoav, plh, todd, ilya Regrets eliperelman Chair Ilya Scribe plh Contents * [3]Topics 1. [4]Definition of current document 2. [5]Clarify Resource Timing terminology 3. [6]Can hidden attribute be removed? (Page Visibility) 4. [7]queue Frame Timing events for each fully active document 5. [8]User Timing rewrite and cleanup 6. [9]Implementation links in specs? 7. [10]Resources Hints * [11]Summary of Action Items __________________________________________________________ Date: 07 Oct 2015 Definition of current document The term current document refers to the document associated with the Window object's newest Document object. The term current document refers to the Window object's newest Document object. Ilya: looks like it's in plh's pile ... we can raise a bug against the html spec ... I'll raise it Clarify Resource Timing terminology <igrigorik> @ [12]https://github.com/w3c/resource-timing/pull/38 [12] https://github.com/w3c/resource-timing/pull/38 plh: I'll address the history section ... and merge it after that Can hidden attribute be removed? (Page Visibility) [13]https://github.com/w3c/page-visibility/issues/12 [13] https://github.com/w3c/page-visibility/issues/12 Yoav: do we want to deprecate one? [14]http://www.w3.org/2013/02/pv-cr-report.html [14] http://www.w3.org/2013/02/pv-cr-report.html Ilya: not sure if we have telemetry Yoav: we could also add a note but we need stats first Todd: the hidden attribute is one of the most used attributes that are currently monitored ... visibilityState is used less Ilya: sounds like we can add a note but not deprecate it ... I'll propose one ... also unloaded is not supported by any browser ... I'll open an issue Yoav: it's optional in the spec. remove? Ilya: we'll tackle those changes before publishing a new draft queue Frame Timing events for each fully active document <igrigorik> @ [15]https://github.com/w3c/frame-timing/pull/50 [15] https://github.com/w3c/frame-timing/pull/50 Ilya: FT doesn't account for iframe, only for current document Todd: might be worth asking Eli to look at it Ilya: ok Yoav: diff between active and current document? Ilya: some documents that may be suspended Yoav: so they may be current but not active? Ilya: correct User Timing rewrite and cleanup Todd: for clearMarks, it will change the return values for getEntries ... it says it empties the mark list, but need to clean the performance entry buffer Ilya: set of objects associated with the performance object ... which is the timeline ... and user timing will follow that plh: ok, i'll continue to iterate Implementation links in specs? plh: see what I did for [16]http://w3c.github.io/page-visibility/ [16] http://w3c.github.io/page-visibility/ Ilya: I wouldn't want to keep an up-to-date list. linking to can I use and make sure. plh: I'll update all of our specs to add the info [17]https://github.com/w3c/web-platform-tests/tree/master/page- visibility [17] https://github.com/w3c/web-platform-tests/tree/master/page-visibility [18]http://w3c-test.org/page-visibility/ [18] http://w3c-test.org/page-visibility/ plh: I'll link to both Resources Hints Yoav: dnsprefetch doesn't work when the page is https ... there is a flag for it ... it's off by default <yoav> [19]https://www.chromium.org/developers/design-documents/dns-pr efetching#TOC-DNS-Prefetch-Control [19] https://www.chromium.org/developers/design-documents/dns-prefetching#TOC-DNS-Prefetch-Control Yoav: same is true for firefox ... I don't understand the restriction, since we'll need to do the dns request eventually "This restriction helps prevent an eavesdropper from inferring the host names of hyperlinks that appear in HTTPS pages based on DNS prefetch traffic. " Yoav: can we remove the restriction? Ilya: my guess is that it's tied to the predictor ... and we didn't want to leak information ... and we just carried the same mechanism in the dns-prefetch ... but I agree with you Yoav: I'll open an issue and loop in Mike West and Ryan, and others (Firefox, MS) ... everyone should dns-prefetch over https because limitating it doesn't make sense ... I'll raise a spec issue [adjourned] <yoav> igrigorik: You were right. The reason this dns-prefetch limitation exists is coupling between explicit <link rel=dns-prefetch> and speculative prefetching of DNS for <a href> in the page <yoav> I'm not sure it merits a spec issue, or just filing patches to decouple that Summary of Action Items [End of minutes]
Received on Wednesday, 21 October 2015 17:11:59 UTC