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