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

[minutes] 20140401 Web Performance

From: Philippe Le Hegaret <plh@w3.org>
Date: Tue, 28 Apr 2015 16:48:13 -0400
Message-ID: <553FF20D.6070004@w3.org>
To: public-web-perf <public-web-perf@w3.org>
(apologizes about not sending those earlier)

Available at

Text version:


       [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


           [Microsoft], +, Plh, +657888aabb, yoav,
           Ilya, +1.310.310.aacc, mbp




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



      [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

    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

    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

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

    Ilya: I need to update the PR
    ... current performance observers provide a callback


      [17] https://lists.w3.org/Archives/Public/public-web-perf/2015Feb/0045.html


      [18] https://lists.w3.org/Archives/Public/public-web-perf/2015Feb/0030.html



      [19] https://github.com/w3c/navigation-timing/pull/10


      [20] https://github.com/w3c/navigation-timing/pull/10/files


      [21] https://github.com/w3c/resource-timing/pull/18

    <igrigorik> new version:

      [22] https://cdn.rawgit.com/w3c/navigation-timing/move-perf-interface-definition/index.html


    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-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/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
    ... would be useful to summarize

    todd: would be valuable to have a few customers that have use
    ... where there is gain

    <scribe> ACTION: Todd to come back with data related to
    setImmediate [recorded in

    <trackbot> Created ACTION-155 - Come back with data related to
    setimmediate [on Todd Reifsteck - due 2015-04-08].


    zaki, close agendum 5

Triage/discuss issues


      [26] https://github.com/w3c/performance-timeline/pull/9

    ilya: would it make to define a more general concept:
    ... 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


      [28] http://w3c.github.io/webperf-dashboard/

Summary of Action Items

    [NEW] ACTION: Todd to come back with data related to
    setImmediate [recorded in

    [End of minutes]
Received on Tuesday, 28 April 2015 20:48:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 28 April 2015 20:48:17 UTC