[minutes] 20150715 Web Performance

Available at

Text version:

                             Web Performance

15 Jul 2015


           yoav, sami, eliperelman, Plh, ToddReifsteck, mpb, Ilya,





      * [2]Topics
          1. [3]requestIdleCallback feedback and next steps
          2. [4]SOP + Resource Timing + no-cors fetches
          3. [5]Timing attacks
          4. [6]Future of performance.timing and performance.navigation
          5. [7]PerformanceObserver needs target
          6. [8]dns prefetch
          7. [9]recommended names for UT
          8. [10]Next meeting
      * [11]Summary of Action Items

requestIdleCallback feedback and next steps



    Ross: [brief overview of the API and motivations]
    ... 8 months ago, we wanted to host background task in the
    ... JS garbage collection, etc.
    ... implementation was based partly on rendering tasks
    ... idle time, etc.
    ... the internal API looks similar to the one we're proposing
    ... and we think it would be useful
    ... so scheduling background task
    ... long running processing, prerendering of content, etc.
    ... could do with a worker
    ... but needs access to the DOM
    ... the API uses a callback
    ... and it become eligible to run at idle times
    ... so could not run for some time
    ... timeout parameter gives some guarantee
    ... deadline objects help with figuring future expectations
    ... any questions?

    [none heard]

    Ross: some discussion around setImmediate with a deadline
    ... don't hink it's the same
    ... but we could do some polyfill of setImmediate use cases
    ... but there are different set of use cases
    ... setImmediate is an API for yielding from the critical path
    ... ie not get in the way of critical path
    ... requestIdleCallback (IRC) is different from that
    ... doesn't get in the way of rendering either
    ... you get a setImmediate callback (SIC) after each rendering

    Todd: yes, current impl of SIC can block rendering
    ... other that that, we do share the rendering idle time
    ... but don't stop when idle time is over

    Ross: we can polyfill SIC really easily, by fallback using RAF
    ... so your work will be processed if the next frame goes out

    Todd: somewhat reasonnable
    ... IRC seems an implementation detail that is exposed
    ... RAF would do all of the RIF if wai until next frame

    Ross: the spec says that if if you call IRC from within an
    other IRC
    ... it will run in the next idle period, not the current one
    ... so if you have a lot of work, you can do some of it up
    until the deadline and scheduled yourself for the next idle
    ... if you work is 5ms and deadline is 5ms, you don't want to
    reschedule within that same idle period

    Yoav: could be multiple idle period inside the same frame

    Ross: current impl is only one idle
    ... when not drawing frames, we have 15ms chunks

    Todd: if it has to wait for the next idle, is that a
    requirement or a default behavior?
    ... if there is time remaining in the idle period, why not?

    Ross: good point. the user should be aware of the remaining
    ... something we could add to the spec after discussion
    ... but default should be next idle period
    ... I'd like to see some use cases first
    ... but should be easy enough to add

    Ilya: curious on use cases as well

    Todd: RAF is about once per frame
    ... IRC is about work during idle time

    Ross: if you know you had that work to do, why don't you do it
    within the same IRC?
    ... if you have multiple idle callback, you may want to yield
    to the one
    ... you can build on top as part of libraries

    Todd: you can do that, but we could also build the abiility in
    the API

    Ilya: what's the next steps?
    ... I do think we can polyfill SIC using IRC

    Todd: saying it can polyfill isn't the same as the adoption
    ... should we introduce a new named API or change the existing

    Ross: you do have about 5% usage of setImmediate but I think
    it's using for immediate task
    ... if we change that, you will loose it
    ... would be confusing for the name
    ... immediate or in the background?

    Yoav: I agree it would be confusing

    Todd: I agree
    ... the name doesn't state Idle
    ... IdleRequestCallback is a better name

    Ross: I do believe there are use cases for setImmediate, so a
    polyfill or a direct impl is valid

    Yoav: is that true in the background as well?

    Todd: just like RAF
    ... setImmediate doesn't run in a non-visible task

    Ross: background tab would run for 10s before being stopped
    ... open for changes as long as we don't use a lot of energy

    Ilya: that behavior would affect RAF as well

    Todd: we can cover that into the spec

    Ilya: are we ok to adopt IRC as a top level spec?

    Todd: don't have a strong enough objection to block

    Plh: would be good to have a polyfill for setImmediate using
    requestIdleCallback and RAF

    long requestIdleCallback(IdleRequestCallback callback [,
    timeout ] );

    <scribe> ACTION: plh to create a repo for requestIdleCallback

    <trackbot> Created ACTION-157 - Create a repo for
    requestidlecallback [on Philippe Le Hégaret - due 2015-07-22].

SOP + Resource Timing + no-cors fetches


      [13] https://github.com/w3c/resource-timing/issues/27

    Ilya: you can use RT to monitor resources uses by style sheets
    ... with the cors attribute

    Todd: we agree we should block


      [14] https://w3c.github.io/resource-timing/#privacy-security

    Ilya: [looking at proper place]

    <scribe> ACTION: Ilya to make a proposal for fixing CORS issues
    on RT

    <trackbot> Error finding 'Ilya'. You can review and register
    nicknames at <[15]http://www.w3.org/2010/webperf/track/users>.

      [15] http://www.w3.org/2010/webperf/track/users>.

Timing attacks

    Todd: this has been reopened by Mozilla
    ... and we're clamping at 1-5 nanoseconds now
    ... should we spec that?
    ... proposal is to clamp at least 1 nanosecond in the spec

    <igrigorik> Chrome:

      [16] https://code.google.com/p/chromium/issues/detail?id=506723

    Ilya: chrome and webkit are clamped at 5 microseconds

    Eli: it looks like we're at 5 microseconds

    Resolved: we're clamping at at least 5 microseconds

    <scribe> ACTION: Todd to clamp HR-TIME at 5 microseconds

    <trackbot> Created ACTION-158 - Clamp hr-time at 5 microseconds
    [on Todd Reifsteck - due 2015-07-22].

Future of performance.timing and performance.navigation


      [17] https://github.com/w3c/navigation-timing/issues/22

    Todd: feedback was, why did we removed them from the spec?

    Plh: [history and possibilities]

    Ilya: given the deployment, we can't drop them

    Todd: agree

    typedef double DOMHighResTimeStamp;

    readonly attribute unsigned long long navigationStart;

    [different time origns]

    Todd: if we do both, we can only expose the navigation and
    timing attributes in the Window context


      [18] http://w3c.github.io/hr-time/#idl-def-Performance

    Plh: but Performance is exposed to Workers...

    interface Performance {

    readonly attribute PerformanceTiming timing;

    readonly attribute PerformanceNavigation navigation;


    partial interface Window {

    [Replaceable] readonly attribute Performance performance;


    for hr-time-2:

    [NoInterfaceObject, Exposed=(Window,Worker)]

    interface GlobalPerformance {


    readonly attribute Performance performance;


    Todd: I'll take this into the issue

PerformanceObserver needs target

    Michael: it sounds to me that everyone is ok to get rid of
    standalone constructor but use the performance object to get a
    new one
    ... other that than the rest of the spec should work
    ... like that the performance object will be clear

    Plh: +1

    Eli: +1

    Michael: see #35


      [19] https://github.com/w3c/performance-timeline/pull/35

dns prefetch


      [20] https://github.com/w3c/resource-hints/issues/37

    Ilya: in a world of preconnect, is there a use for prefetch?
    ... there are some use cases from blink-dev
    ... preconnect can be expensive
    ... so probably makes sense to have dns-prefetch
    ... it's implemented as far as I know
    ... ok to add to resource hints spec?

    Todd: +1

    [Ilya will follow up]

recommended names for UT

    Plh: [introduced the topic]

    Ilya: I'm not aware of any impl that are using the recommended
    ... they define their owns
    ... given the lack of adoption, I'm inclined to remove those
    ... we may come up with new ones
    ... but not a strong argument to do so

    Todd: makes sense

    Eli: agree
    ... drop the recommended mark names
    ... in Firefox OS, we made our owns for our apps

    Ilya: so are those marks useful?

    Eli: it's an ad-hoc thing. every app will have different asset
    loading strategy/order
    ... so the marks are vague on purpose

    <scribe> ACTION: Eli should provide references at our
    recommended mark names in firefox os are used in internal apps

    <trackbot> Created ACTION-159 - Should provide references at
    our recommended mark names in firefox os are used in internal
    apps [on Eli Perelman - due 2015-07-22].

    <scribe> ACTION: plh to drop recommended marks in user timing

    <trackbot> Created ACTION-160 - Drop recommended marks in user
    timing [on Philippe Le Hégaret - due 2015-07-22].

Next meeting

    August 12

Summary of Action Items

    [NEW] ACTION: Eli should provide references at our recommended
    mark names in firefox os are used in internal apps
    [NEW] ACTION: Ilya to make a proposal for fixing CORS issues on
    [NEW] ACTION: plh to create a repo for requestIdleCallback
    [NEW] ACTION: plh to drop recommended marks in user timing
    [NEW] ACTION: Todd to clamp HR-TIME at 5 microseconds

    [End of minutes]

Received on Wednesday, 15 July 2015 21:47:50 UTC