IRC log of webperf on 2015-10-25

Timestamps are in UTC.

23:36:56 [RRSAgent]
RRSAgent has joined #webperf
23:36:56 [RRSAgent]
logging to http://www.w3.org/2015/10/25-webperf-irc
23:37:05 [xiaoqian]
rrsagent, this meeting spans midnight
23:44:16 [xiaoqian]
xiaoqian has changed the topic to: TPAC 2015 agenda: https://bit.ly/perf-tpac15
23:48:18 [minami]
minami has joined #webperf
00:02:25 [yoav]
yoav has joined #webperf
00:02:53 [lisongfeng]
lisongfeng has joined #webperf
00:09:26 [plh]
plh has joined #webperf
00:11:34 [yubo]
yubo has joined #webperf
00:18:48 [rniwa]
rniwa has joined #webperf
00:19:12 [yoav]
igrigorik: 10000 feet view of WebPerfWG
00:19:20 [yoav]
https://docs.google.com/document/d/1ZKW9N0cteHgK91SyYQONFuy2ZW6J4Oak398niTo232E/edit
00:19:25 [plh]
trackbot, start telcon
00:19:27 [trackbot]
RRSAgent, make logs world
00:19:29 [trackbot]
Zakim, this will be web-per
00:19:29 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
00:19:30 [trackbot]
Meeting: Web Performance Working Group Teleconference
00:19:30 [trackbot]
Date: 26 October 2015
00:19:54 [yoav]
High resolution time is the foundation of the WebPerf APIs
00:20:07 [plh]
rrsagent, generate minutes
00:20:07 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/10/25-webperf-minutes.html plh
00:20:11 [yoav]
we recently made sure that it works well with both window and worker
00:20:50 [yoav]
igrigorik: translateTime recently added to HRT
00:21:07 [plh]
https://w3c.github.io/hr-time/
00:21:23 [yoav]
igrigorik: we also have a problem with people finding the old version of HRT rather than the new one
00:21:49 [yoav]
igrigorik: The next big chunk is performance timeline
00:22:12 [yoav]
http://www.w3.org/TR/performance-timeline-2/
00:22:52 [yoav]
PerformanceObserver was added. It enables to subscribe to notifications about various metrics
00:23:48 [yoav]
ResourceTiming: pretty simple and not many recent updates
00:24:08 [yoav]
https://w3c.github.io/resource-timing/
00:24:23 [yoav]
Navigation Timing is being refactored to be based on resource timing
00:24:40 [yoav]
https://w3c.github.io/navigation-timing/
00:25:13 [yoav]
igrigorik: There are fetches that are multiple fetches under the hood, and we need to figure out a way to un-mush that
00:25:39 [yoav]
todd: We need to figure out a way to so that securely
00:26:19 [yoav]
igrigorik: user timing, some cleanups but no major changes
00:26:35 [yoav]
Server-timing - no implimentations today
00:26:57 [yoav]
todd: the main blocker there is trailer headers
00:27:17 [yoav]
igrigorik: without trailers a lot of the use cases are lost
00:28:21 [yoav]
http://www.w3.org/TR/server-timing/
00:30:12 [yoav]
mnot: there is pushback about supporting trailers in browsers
00:31:16 [plh]
fun fact: https://w3c.github.io/server-timing/#the-performanceservertiming-interface actually defines an interface called "ServerTiming"
00:31:17 [yoav]
igrigorik: we could just expose certain headers (e.g. server timing) there, and not generic support for exerything
00:31:53 [yoav]
todd: ServerTiming can be done, but would be more interesting with trailers
00:32:24 [yoav]
igrigorik: server timing spec has been stable for a while, but we could convert it to performance observer
00:32:58 [yoav]
todd: Agreed, but we'd need to be able to define it for the navigation request
00:33:25 [yoav]
igrigorik: as long as you register the perfObserver early, you could do that
00:34:17 [yoav]
todd: would be great if there was a declarative way to do that
00:34:46 [yoav]
FrameTiming: recently changed so that frameTiming only measured frames that exceeded their budget
00:35:07 [yoav]
The whole spec addressed a big gap that we have regarding measuring run time
00:36:09 [jeff]
jeff has joined #webperf
00:36:40 [yoav]
rniwa: when we looked at frame timing, it didn't make much sense.
00:37:11 [yoav]
todd: the recent spec matches RAF much more closely, and the compositor references are now gone
00:38:43 [yoav]
rniwa: intersection observer could have also be used to measure something like that
00:39:26 [yoav]
igrigorik: Beacon API currently based on fetch
00:39:30 [yoav]
couple of open issues
00:39:59 [yoav]
we need to send different payloads, which may trigger CORS preflights and questions RE credentials
00:41:03 [yoav]
preload - we'd done a few loop around the track on how to determine priority. It's been addressed with hooks into fetch. Exposed as the `as` attribute
00:42:43 [yoav]
igrigorik: originally, preload was part of resource hints, but now it's split into its own spec, since is has mandatory semantics
00:43:23 [yoav]
Resource hints - preconnect is shipped, and used by some Google properties
00:44:01 [yoav]
dns-prefetch, prefetch, prerender mostly retro-speccing the implemented bits
00:44:31 [lisongfeng]
lisongfeng has joined #webperf
00:45:00 [yoav]
igrigorik: prefetch and prerender are highly heuristic, and hard to predict as a developer when they'd kick off
00:45:36 [yoav]
igrigorik: in the spec we talk about downgrading resource hints, but it doesn't look like any of the implementations do that
00:46:59 [jeff_]
jeff_ has joined #webperf
00:47:03 [yoav]
todd: What we've seen with internal properties, it takes them a lot of time to experiement and figure these hints out
00:47:16 [yoav]
rniwa: maybe developer tools could help us there
00:48:44 [yoav]
bartek: Would it be possible for regular developers which parts of the draft are implemented and shipped?
00:49:33 [bartek]
bartek has joined #webperf
00:49:37 [yoav]
igrigorik: plh has a implementation document
00:50:07 [yoav]
NEL - no current implementation in Chrome, Firefox are looking into it
00:50:58 [yoav]
igrigorik: Working with Mike West on a reporting API, so that we can report NEL, CSP, HSTS and everything else
00:51:33 [moto]
moto has joined #webperf
00:52:49 [yoav]
bartek: Would be interesting to have that info in DNS headers
00:53:11 [yoav]
so that the browser can know what the reporting URL is
00:54:12 [yoav]
igrigorik: so once the reporting API would be in place, we'd reactor NEL based on that
00:54:57 [yoav]
requestIdleCallback - used to run some code at idle time so that it won't get in the way
00:55:07 [plh]
plh has joined #webperf
00:55:23 [plh-irc]
plh-irc has joined #webperf
00:55:39 [plh-irc]
plh-irc has left #webperf
00:56:34 [yoav]
todd: Page Visibility enables developers to know if the current tab is visible
00:56:57 [yoav]
there was some dicussion about out-of-view iframes, but we didn't move forward with that
00:57:32 [yoav]
todd: one last item is CPU and memory monitoring, but it can be tricky for security reasons
00:59:36 [yoav]
igrigorik: we've been talking in Chrome about killing the onunload event
00:59:56 [yoav]
on mobile you should listen to page visibility rather than onunload
01:02:15 [yoav]
igrigorik: and since it's broken in many browsers, we could just remove it, since devs can't rely on it
01:03:16 [minami_]
minami_ has joined #webperf
01:05:31 [yoav]
todd: this also means that the page visibility API may rise in importance
01:05:54 [yoav]
plh: we can add a section to the spec to talk about that
01:06:33 [yoav]
rniwa: when the users switch a task, focus and blur is changed, and currently not specified anywhere
01:06:59 [yoav]
igrigorik: might be specified in the HTML spec, but not implemented in a consistent way
01:08:19 [plh]
Yoav: how about visibility metrics? need paint observers?
01:08:48 [plh]
rniwa: interested as well. we don't know what's important for each page
01:17:10 [yoav]
Other items discussed: Declerative way to improve first paint and prevent CSS blocking
01:17:35 [yoav]
igrigorik: profiler API would be interesting
01:18:18 [yoav]
todd: it'd be interesting to expose how well the Web page performs on the machine it's working on
01:20:34 [yoav]
igrigorik: There's a proposal for interventions in Chrome, so that the browser can break the API contracts in some cases, in order to improve the user experience
01:20:52 [yoav]
part of that is signaling to the origin that the intervention took place
01:21:02 [yoav]
which loops back to the reporting API
01:21:21 [yoav]
we could observe the lifecycle of the page and at the end send back a report
01:22:50 [yoav]
rniwa: it's usually more interesting to have aggregate data
01:23:16 [yoav]
igrigorik: that depends. In some cases that's true, and in some cases it's interesting to have granular data
01:25:44 [yoav]
yoav: in terms of out-of-band reporting, it might be interesting to expose that to users eventually
01:28:28 [yoav]
break till 10:45
02:00:09 [yoav]
yoav has joined #webperf
02:04:58 [yoav]
Discussing HR timing 2
02:05:05 [yoav]
plh: What do we do with the spec?
02:05:23 [yoav]
there are no implementations of translateTime
02:05:54 [yoav]
igrigorik: it can be polyfilled
02:06:23 [yoav]
plh: who is exposing performance.now in workers?
02:06:44 [yoav]
igrigorik: Chrome is
02:07:25 [yoav]
todd: workerStart is tied to service worker, where translateTime is realted to workers in general
02:07:44 [yoav]
plh: Should we not ship translateTime in the spec?
02:08:20 [yoav]
todd: we could publish without translateTime, and then publish translateTime in the next release
02:08:40 [minami]
minami has joined #webperf
02:08:41 [yoav]
plh: so we just need to make sure we have a test that tests the worker support
02:09:28 [yoav]
plh: so the goal is to push HR time 2 to REC, but without translateTime.
02:10:18 [bob]
bob has joined #webperf
02:18:55 [jeff_]
jeff_ has joined #webperf
02:19:16 [yoav]
*Discussion about https://github.com/w3c/hr-time/pull/14
02:19:49 [plh]
The term <dfn>current document</dfn> refers to the document associated with the Window object's newest Document object
02:20:01 [plh]
The term <dfn>current document</dfn> refers to the Window object's newest Document object
02:20:56 [yoav]
Everyone: Let's just add a note referring to the bug on HTML
02:21:25 [ToddReifsteck]
ToddReifsteck has joined #webperf
02:22:30 [plh]
The term <dfn>current document</dfn> refers to the Document object returned by Window.odocument
02:22:33 [plh]
The term <dfn>current document</dfn> refers to the Document object returned by Window.document
02:25:51 [yoav]
todd: second issue https://github.com/w3c/hr-time/issues/15
02:26:06 [yoav]
this will be resolved once we'd publish the new spec
02:26:23 [yoav]
plh: Need to do the "great renaming" where the old spec changes urls
02:27:14 [yoav]
plh: Also, we can push current spec to CR with translateTime "at risk" so that we can later add it in once implementations catch up
02:27:53 [yoav]
todd: moving on from HR time to Performance Timeline
02:28:30 [jeff__]
jeff__ has joined #webperf
02:28:40 [yoav]
plh: the biggest issue is from resource timing and navigation timing
02:29:05 [yoav]
in both we have "clear" which when based on PerfTimeline does nothing
02:31:03 [plh]
https://pad.w3ctag.org/p/pt-buffer
02:32:42 [yoav]
If we only register perfObserver at the head of HTML, you're racing and might miss some resources
02:33:28 [yoav]
todd: For frame timing, it's defined as not injecting to the timeline, but only emits performanceObserver
02:34:35 [yoav]
igrigorik: We agree that all API should be based on PerformanceObserver. I think that some APIs don't need a buffer in addition to that
02:35:59 [yoav]
btu in some cases, we need a buffer - especially for resource timing and keeping track of resources that may finish loading before perfObserver registration is done
02:37:31 [Zakim]
Zakim has left #webperf
02:37:32 [justin_]
justin_ has joined #webperf
02:38:42 [yoav]
todd: perhaps the way to get perfObserver on everything is to have an initial buffer, and then the first event grabs everything from that buffer and onto PerfObserver
02:39:31 [yoav]
plh: I don't think we can change getEntries() because they are heavily used
02:40:00 [yoav]
It would be interesting to polyfill them using perfObserver
02:40:43 [yoav]
todd: that makes sense.
02:44:08 [bkardell_]
bkardell_ has joined #WebPerf
02:45:29 [yoav]
*discussion about eliminating buffers entirely, getting an initial buffer in place, etc
02:48:21 [yoav]
plh: if we could remove the setResourceTiming size, it'd make it easier to just define a start buffer
02:49:54 [yoav]
igrigorik: we could also limit buffering up until the onload event
02:50:20 [yoav]
so that users in their registration would read the buffer and then start observing from that point on
02:52:24 [yoav]
yoav: there's some race condition here if users read first and register later
02:52:37 [yoav]
plh: yeah, but if they register first, we're all good
02:55:14 [yoav]
rniwa: it'd much nicer to have a flag so that when you register the observer, you get all the past entries as well
02:56:42 [yoav]
todd: so that browsers that haven't implemented getEntries() (Safari/WebKit) never have to buffer after onload
02:57:35 [yoav]
plh: do we even need the flag?
02:57:58 [yoav]
rniwa: it makes sense for the default to be to get all the past entries
02:58:57 [yoav]
rniwa: it might be nice to be able to filter what you want recording
02:59:38 [yoav]
todd: currently you're getting an array and you can filter it
03:00:45 [yoav]
rniwa: in MutationObservers you can listen to a single node. It would be nice to filter based on a single resource
03:01:33 [yoav]
igrigorik: Alex Russel also wants to be able to query the img resource related to a single DOM element
03:02:07 [yoav]
todd: We can tell with initiator type, but not everything
03:04:04 [yoav]
yoav: how would that data be useful? If you have multiple elements referring a resource, it's still a single entry for a single fetch
03:04:25 [yoav]
rniwa: anyway, it would be nice to be able to filter based on an element
03:05:09 [yoav]
todd: we can filter by name
03:05:40 [yoav]
plh: but we don't allow filtering by name on perfObserver
03:06:08 [yoav]
igrigorik: It's a list, and devs can just ".filter" on it
03:07:32 [yoav]
plh: getEntriesByType("resource") was added so that you don't need to create the JS types for anything that won't go into the JS list
03:09:12 [yoav]
todd: That's not necessarily a concern today
03:09:59 [yoav]
igrigorik: Nat Duca supported adding the GetEntriesBy* when we were talking about thousands of entries
03:10:10 [yoav]
for a smaller number, it might not make sense
03:11:36 [yoav]
todd: we see 3 getEntries() for every 2 getEntriesByType() for 0 getEntriesByName()
03:12:21 [yoav]
plh: We can't remove these methods, but we can move them to a historical section
03:12:47 [yoav]
todd: We should wait with deprecation until we have a replacement specced and shipped in enough browsers
03:14:29 [yoav]
plh: so let's promote perfObserver in a way that could one day used to replace getEntries*
03:15:51 [yoav]
igrigorik: so let's imagine we only had perfObserver. We could tell developers to add a shim that emulates getEntries*
03:19:47 [lisongfeng_]
lisongfeng_ has joined #webperf
03:20:30 [yoav]
* Discussion on Performance Observer and {how/if} we can obsolete the getEntries* methods
03:27:54 [yoav]
* Overall discussion tends to get rid of getEntries* from perfObserver
03:30:04 [yoav]
todd: FrameTiming was defined to not buffer, but maybe in the initial buffer model we want to buffer it
03:31:09 [yoav]
igrigorik: so until onload we buffer anything. We can also have some opt-in to only buffer certain types.
03:32:08 [yoav]
rniwa: buffering is not expensive, but measuring can be expensive so an opt-in would be useful
03:33:37 [yoav]
igrigorik: FWIW, today RT and NT already measure and it works fine without huge overhead
03:35:14 [yoav]
todd: Let's separate frame timing from perfObserver for the moment and discuss that separately
03:37:24 [yoav]
igrigorik: so to keep things simple, the buffer buffers everything up until onload
03:41:25 [minami]
minami has joined #webperf
03:46:29 [yoav]
igrigorik: to complicate things further, fetch registry might also add resource timing that is unbound
03:49:17 [yoav]
todd: that's an issue for the fetch spec to deal with
03:49:33 [yoav]
for our purposes, the "up to onload" buffer can probably be bound to 500
04:07:31 [yoav]
* Discussion about some opt-in for PerfObserver
04:10:48 [yoav]
*Lunch!
04:29:22 [bob]
bob has joined #webperf
04:51:31 [jeff]
jeff has joined #webperf
05:06:08 [Justin__]
Justin__ has joined #webperf
05:08:11 [yoav]
yoav has joined #webperf
05:08:18 [Justin__]
q
05:08:59 [minami]
minami has joined #webperf
05:09:04 [justin__]
justin__ has joined #webperf
05:10:42 [yubo]
yubo has joined #webperf
05:16:24 [yoav]
discussion on perfObserver's buffer queueing logic
05:34:45 [hwlee]
hwlee has joined #webperf
05:42:38 [yoav]
conclusions:
05:43:04 [yoav]
* Some buffering is required in order to not miss events
05:43:41 [yoav]
* onload gives us the ability to register to PerfObservers from async scripts
05:43:58 [yoav]
* opt-in would save us from having to measure and queue
05:44:49 [yoav]
* Mandatory inline script registrations would allow us to buffer significantly less
05:45:29 [yoav]
* There's a problem there if we have multiple PerfObservers registering
05:47:23 [yoav]
igrigorik have taken a screenshot of the whiteboard
05:48:30 [ToddReifsteck]
ToddReifsteck has joined #webperf
05:48:37 [ToddReifsteck]
Memory info API thoughts from Ilya--https://docs.google.com/document/d/1tFCEOMOUg4zmqeHNg1Xo11Xpdm7Bmxl5y98_ESLCLgM/edit#
05:48:54 [lisongfeng]
lisongfeng has joined #webperf
05:50:57 [yoav]
igrigorik: different implementations can report different things, developers might micro-optimize to implementation details
05:51:06 [yoav]
under-reporting browsers would look better
05:54:37 [dbaron]
dbaron has joined #webperf
05:56:15 [yoav]
* Going over use-cases from the doc
06:04:44 [yoav]
two distinct use cases:
06:04:59 [yoav]
regression detection - seeing if your app memory usage increases over time
06:05:35 [yoav]
adaptation - serving a different, lighter version of your site to devices that cannot deal with the full version
06:09:35 [yoav]
todd: How would we register to getting memory reports?
06:09:42 [yoav]
plh: could be a performance entry
06:11:05 [yoav]
igrigorik: proposal is just to get an event with a performance entry with heap size and an "underPressure" boolean
06:15:29 [yoav]
igrigorik: should we add other metrics? canvas size, media buffers (if we're willing to expose it)
06:24:15 [yoav]
yoav has joined #webperf
06:25:53 [hwlee]
hwlee has joined #webperf
06:26:37 [yoav]
an underPressure event would be a signal to the app that some of their users are under memory pressure in the wild
06:28:44 [yoav]
plh: the goal is to allow the application to send a beacon up
06:28:53 [yoav]
todd: and to turn things off
06:37:36 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/10/25-webperf-minutes.html xiaoqian
06:42:47 [yoav]
another goal is to be able to send up memory increases so that apps can keep an eye on memory increases
06:43:10 [yoav]
igrigorik: Another case is getting crash reports
06:47:49 [yoav]
yoav: we also need a way to detect low-end devices relatively up-front so that Web sites can load light versions of their sites for devices that can't handle more than that
06:48:48 [yoav]
plh: there would be privacy issues with exact numbers
06:49:07 [yoav]
rniwa: we could clip the numbers to the hundreds of MBs to avoid privacy concerns
06:49:44 [yoav]
next up: Intersection Observer
06:50:29 [yoav]
slightlyoff: the proposal comes from traces of 3rd party content, what making Web sites slow, battery use & jank
06:51:12 [yoav]
A lot comes from third party that try to see where things are on screen
06:51:21 [yoav]
use cases:
06:51:34 [yoav]
dealy loading of content, with scroll events
06:51:40 [yoav]
analytics and ads networks
06:51:57 [yoav]
(forcing sync layout every 100ms or so)
06:52:26 [yoav]
the bad version of that creates plugins that measures things inside the viewport
06:53:54 [yoav]
IntersectionObserver lets you know how if an element that you care about hits the viewport
06:54:19 [yoav]
that answers this use case, plus enables lazy loading
06:55:40 [yoav]
It can report the top level viewport, or to report when the observed element overlaps another element
06:56:00 [yoav]
The information is async delivered and you might miss a thread or two
06:56:20 [yoav]
because multi-threading is hard
06:56:42 [yoav]
so you set an observer on an element and get notified when that element enters the viewport
06:57:26 [yoav]
with that you can meet the ad network guidelines, so ads can implement their thing using that
07:00:04 [yoav]
plh: Would that API be able to tell you if an element is visible?
07:00:46 [yoav]
slightlyoff: Only to an approximation
07:01:01 [yoav]
plh: iframes?
07:01:15 [yoav]
slightlyoff: There's a good chance that this would give you that
07:01:59 [yoav]
it can't cover if an element was hidden by a different element
07:03:21 [yoav]
slightlyoff: time is relative to the generator which may be the compositor
07:03:36 [yoav]
there can be some skew
07:03:52 [yoav]
igrigorik: about privacy and timing attack
07:04:07 [yoav]
rniwa: if it's async, there's no risk for timing attack
07:10:27 [yoav]
slightlyoff: about approximation of meaningful paint, the first intersection observer may more or less correlate with the meaningful first paint
07:11:51 [yoav]
there can be delay between layout and paint in some browsers. Also images that are painted to a viewport element won't be visible to that API
07:12:28 [yoav]
rniwa: we could also have elements that are in the viewport but never painted due to fast scrolling
07:14:19 [yoav]
rniwa: The real metric people want is when things got painted
07:14:38 [yoav]
slightlyoff: That's a metric that we can add. File an issue on the repo
07:18:51 [yoav]
rniwa: It would be great to correlate that info with frame timing in order to figure out which elements trigger jank
07:19:05 [yoav]
slightlyoff: the times are not correlated
07:19:54 [yoav]
igrigorik: the important thing is that you should be able to translate between that time and the current document time.
07:22:08 [yoav]
todd: We've had some push back for Page Visibility 2 on iframe visibility, but now with IntersectionObserver, maybe there's a chance to get that
07:23:08 [yoav]
rniwa: So the idea is the attach intersection observers to iframes if the user attached to the iframe's page visibility?
07:23:30 [yoav]
maybe, even if the async nature is making this harder
07:23:54 [yoav]
let's wait for intersection observer to be a thing before making decisions on that
07:39:30 [yoav]
yoav has joined #webperf
07:50:17 [hwlee]
hwlee has joined #webperf
07:51:06 [justin]
justin has joined #webperf
07:51:53 [justin]
rrsagent, make minutes
07:51:53 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/10/25-webperf-minutes.html justin
07:52:29 [yoav]
slightlyoff: some things are weirdly split between resource timing and navigation timing
07:53:32 [yoav]
It seems odd that there's no way to get from an element to the relevant timing. It's hard to tie the DOM and the timing back together
07:54:05 [yoav]
if there's evidence that this is something people do, it'd be good to add that back to the platform
07:55:03 [yoav]
rniwa: it would be nice to get a timing back from an element
07:56:33 [yoav]
todd: the theory is that most analytics poll the timeline regularly, so that instead of timers, PerfObservers would enable to receive events as they arrive
07:57:18 [yoav]
slightlyoff: they poll frequently in order to avoid data loss
07:58:00 [yoav]
igrigorik: it's both. You need to observe when things have changed. Then, if you delay it too long, you may lose it
07:59:57 [yoav]
igrigorik: one more issue is about resources that send more than one request: preflights, redirects
08:00:08 [yoav]
we can probably unbundle that
08:00:25 [yoav]
slightlyoff: so will the APIs continue to evolve or are they done
08:00:41 [yoav]
igrigorik: they'd continue to evolve in small ways, but most of the data is there
08:01:24 [yoav]
rniwa: could we agregate the data?
08:02:01 [yoav]
igrigorik: there are several agregation implementation out there, but they're all different so there's no single way we'd want to stardize
08:03:57 [yoav]
todd: getEntriesByType(navigation) is not implemented in Firefox and Chrome
08:09:33 [yoav]
slightlyoff: Regarding attribution, it would be significantly easier to be able to get the element(s) back from the timing entries
08:11:14 [yoav]
the list of elements could be populated at query time
08:17:00 [moto]
moto has joined #webperf
08:20:29 [yoav]
todd: It's interesting to look into the use cases and see if we can limit the attribution to resources that would satisfy the use-cases
08:21:09 [yoav]
slightlyoff: it may also be interesting to attribute download initiation to other resources/timing/elements
08:28:47 [igrigorik]
http://www.webpagetest.org/breakdownTimeline.php?test=151026_HS_DQ1&run=2&cached=0
08:34:28 [cristi]
cristi has joined #webperf
08:35:22 [yoav]
yoav has joined #webperf
08:36:19 [yoav]
* Discussion about an API that would expose what the main thread have been doing for RUM
08:49:56 [yoav]
it's possible that just decorating frame timing with that data would be enough to get that data in the hands of users
08:50:29 [yoav]
rniwa: also, it's possible that GC time and layout times can be cheaply measured and exposed
08:52:17 [yoav]
exposing layout time can expose timing events if you wouldn't limit precision
08:57:55 [yoav]
todd: system profiling api is interesting, but we don't have conclusive data that it's needed
08:58:21 [yoav]
igrigorik: Let's add some of this to frame timing, and then see
10:17:07 [yoav]
yoav has joined #webperf
12:14:25 [stakagi]
stakagi has joined #webperf
12:29:00 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/10/25-webperf-minutes.html xiaoqian
12:29:33 [RRSAgent]
I see no action items