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