W3C home > Mailing lists > Public > public-web-perf@w3.org > October 2015

[minutes] Web Performance 20151007

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>
Message-ID: <5627C758.9010303@w3.org>
Available at

Text version:

                             Web Performance

07 Oct 2015




           yoav, plh, todd, ilya





      * [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
          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

    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

    Yoav: do we want to deprecate one?


      [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
    ... 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/

    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




      [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: 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


    <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

This archive was generated by hypermail 2.3.1 : Wednesday, 21 October 2015 17:11:59 UTC