- From: Philippe Le Hegaret <plh@w3.org>
- Date: Wed, 15 Jul 2015 17:47:46 -0400
- To: public-web-perf <public-web-perf@w3.org>
Available at
http://www.w3.org/2015/07/15-webperf-minutes.html
Text version:
Web Performance
15 Jul 2015
Attendees
Present
yoav, sami, eliperelman, Plh, ToddReifsteck, mpb, Ilya,
Ross
Regrets
Chair
Todd
Scribe
plh
Contents
* [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
[12]https://lists.w3.org/Archives/Public/public-web-perf/2015Ju
n/0126.html
[12]
https://lists.w3.org/Archives/Public/public-web-perf/2015Jun/0126.html
Ross: [brief overview of the API and motivations]
... 8 months ago, we wanted to host background task in the
scheduler
... 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
loop
Todd: yes, current impl of SIC can block rendering
... other that that, we do share the rendering idle time
semantic
... 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
deadline
... 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
one?
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
[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
[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
[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
[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
[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 {
[Replaceable]
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
[19] https://github.com/w3c/performance-timeline/pull/35
dns prefetch
[20]https://github.com/w3c/resource-hints/issues/37
[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
marks
... 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
RT
[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