[TOC]
- Publish public proposal on smoothness.
- Responsiveness:
- Socialize publicly our definition of interactions and normalization options.
- Implement interactionID.
- Enable exposing information about Single Page Apps via navigation IDs.
- Expose performance information about back-forward cache navigations to performance timeline.
- Specify and launch redefined (window-based) Cumulative Layout Shift.
- Ship JS Sampling Profiler.
- Facilitate Resource Timing integration into Fetch and change implementation as needed.
- Obtain more accurate abandonment rates on Chrome to determine what to do about the problem.
- Implement and ship droppedEntriesCount.
- performance.measureMemory was shipped! See the blog post.
- Single Page Apps:
- Provided feedback to the AppHistory explainer.
- Discussed how to extend performance timeline to include SPAs in the WebPerf WG.
- Improved abandonment data on Chrome to account for FCP more accurately.
- Continued work on smoothness and responsiveness proposals.
- Proposed way to include back-forward cache performance information to the WebPerf WG.
- Organized A/B testing workshop to better understand the problem space: see notes.
- Completed GC integration work for the JS Sampling Profiler.
- Various improvements for Layout Instability which especially impact carousels. See changelog.
- Decided redefinition of Cumulative Layout Shift and announced in post.
- performance.measureMemory: ship the API.
- Single Page Apps:
- Publish an explainer about SPA issues.
- Determine whether User Timing hints conventions are still useful.
- Abandonment:
- Gather concrete feedback form analytics providers and other potential users of this API.
- Improve confidence on the abandonment rates computed by implementing a renderer-side flushing.
- Update analysis on rates when the above fix has reached Chrome Stable.
- Smoothness:
- Continue refining the definition of dropped frames.
- Move proposal to WICG.
- Back-forward cache:
- Expand scope to include FCP and FID in the values reported after back-forward navigations.
- Investigate backwards compatibility of adding new entries and propose an API shaped based on the outcome.
- Responsiveness:
- Investigate correctness of existing internal metrics and implement fixes as needed.
- Further investigate scrolling performance and how it should be integrated with metric.
- Define user interactions that we care about for this API.
- Create a manual test corpus to test ideas about the 'end time' of a user interaction.
- First Contentful Paint: improve implementation to pass more tests.
- Longtasks: add system time, including garbage collection
(bug).
- Present proposal to security team, and begin socializing the proposal externally.
- A/B testing: organize workshop on client-side A/B testing.
- JS Sampling Profiler:
- Complete the GC integration work.
- Ship the API.
- performance.measureMemory: added support for cross-origin iframes in the same process and sent Intent to Ship.
- Page abandonment: made some data available publicly and socialized it in a blogpost.
- JS Sampling Profiler:
- Implemented the API so it requires COOP/COEP and gated it behind Document Policy.
- Finished a prototype of GC integration for the V8 sampling profiler (which will help reduce profiler startup time).
- Landed some initial support for code object refcounting.
- Smoothness: published a proposal around dropped frames and presented it at TPAC.
- Back-forward cache: determined that it is backwards compatible to expose a PerformanceNavigationTiming entry for back-forward navigations.
- Responsiveness:
- Investigated some internal metrics, but found some metric quality issues that need to be investigated.
- Started brainstorm on capturing asynchronous work as well as which user interactions to capture.
- Did investigation on scrolling and determined that in most cases pages do not seem to suffer from poor scrolling performance.
- Largest Contentful Paint: include removed nodes (bug) and ignored images occupying the full viewport (bug).
- Cumulative Layout Shift: implemented various fixes, see changelog.
- {#measure-memory-20204}performance.measureMemory:
- Add support for cross-origin iframes.
- Send Intent to Ship and ship --- API would become available early next year.
- {#spas-20204}Single Page Apps:
- Publish document for feedback on measurement issues, attributions issues, and other issues specific to SPAs.
- Land support for User Timing hints in Chrome, and get 2+ frameworks to start using such hints.
- {#page-abandonment-20204}Page abandonment: publish data on abandonment rates, making a case for or against an abandonment API.
- {#js-profiler-20204}JS Sampling Profiler:
- Implement the API so it requires COOP/COEP.
- Add support for warm codemap initialization.
- Add web platform tests.
- (Stretch) Send Intent to Ship.
- {#smoothness-20204}Smoothness (FrameTiming):
- Discuss and socialize API shape.
- Propose API on WICG.
- Start a TAG review.
- {#bf-cache-20204}Back-forward cache: document and socialize a concrete proposal on a web API that supports monitoring performance of sites on browsers that may perform back-forward navigations.
- {#responsiveness-20204}Responsiveness:
- Investigate internal metrics and potentially add new metrics to capture end-to-end responsiveness.
- Document how popular frameworks handle user interactions.
- Brainstorm on how to expand Event Timing to capture user handling for asynchronous work and to handle multiple events referring to a single user interaction.
- Complete on-going investigation on whether scroll performance is also a problem in the web that needs a web API.
- {#lcp-20204}Largest Contentful Paint:
- Complete investigation on removed nodes and if needed update the API.
- Ignore images that occupy the full viewport.
- {#cls-20204}Cumulative Layout Shift: evaluate the impact of triggering on empty or invisible content and update spec and implementation accordingly.
- {#fcp-20204}First Contentful Paint: improve implementation to pass more tests.
- {#rt-worker-20204}Navigation Timing: Fix encoded/decoded body sizes when going through service workers.
- performance.measureMemory:
- Spec was reviewed and polished.
- API support was added for workers (available from Chrome 87).
- Page abandonment: improved data was gathered, but more accuracy improvements are needed.
- VisibilityStateEntry: explainer, discussion, and TAG review kicked off, but no consensus yet on API shape.
- FrameTiming: a lot of research on defining a good metric to capture smoothness.
- isInputPending: shipped and available from Chrome 87!
- LargestContentfulPaint:
- Did analysis on how LCP would change when removed content is included.
- Ignored paints occurring with opacity 0.
- CumulativeLayoutShift fixes:
- Ignored shifts from video thumb sliders.
- Fixed computations for ink overflow and transforms.
- Updated computations when child moves alongside their parent element.
- Web vitals specs: triaged new issues as well as existing ones.
- Paint Timing: fixed two FCP tests by improving our implementation.
- {#measure-memory-20203}Continue previous work on performance.measureMemory.
- Extend the scope of the API to workers and cross-site iframes.
- Do a review over the spec and polish it.
- {#spas-20203}Continue previous work on Single Page Apps (SPAs).
- Complete partnerships with frameworks and begin gathering data using the strategy based on User Timing annotations.
- {#page-abandonment-20203}Continue previous work on page load abandonment.
- Decide a path forward for a potential new web API based on data from the metric we recently implemented.
- {#page-visibility-20203}Continue previous work on exposing full Page Visibility history. We intend to spec and ship the VisibilityStateEntry.
- {#frame-timing-20203}Work on the
Frame Timing proposal.
- Draft a spec.
- (Stretch) Land a prototype of the API.
- {#fb-driven-20203}Continue previous work on Facebook-driven APIs.
- Based on the iframe layerization experiment results, send Intent to Ship for isInputPending.
- (Stretch) Implement warm initialization logic for the JS Self-Profiling API.
- {#lcp-20203}Improve quality of Largest Contentful Paint.
- Decide whether LCP including removals is better than the current definition (which excludes removals).
- Address problems with LCP not correctly accounting for opacity in some cases due to optimizations in paint code: see relevant bug.
- {#normalization-20203}Brainstorm ideas around better normalization techniques for existing web performance metrics and socialize these ideas with the W3C Web Perf WG.
- {#vitals-specs-20203}Triage spec issues filed on GitHub. We intend to give higher priority to feeedback on web vitals specs.
- {#event-timing-20203}Reduce WPT test flakiness on Event Timing.
- {#paint-timing-20203}Change more of Chrome's Paint Timing implementation to pass more of the currently failing WPTs.
- performance.measureMemory:
- Crafted a plan to enable extending the API to workers as well as to cross-site iframes with the appropriate COEP headers.
- Drafted a spec, but it requires review.
- Single Page Apps:
- Designed a strategy for routing frameworks to report the start and end of SPAs via User Timing.
- Began conversations with such frameworks but haven't started gathering data with the strategy we designed.
- Presented our data-driven approach to the W3C Web Perf WG.
- Page abandonment: Socialized a proposal for how to define abandonment and brainstormed ways in which we could expose the data to web developers. However, we have not yet reached a decision on how we plan to expose the data because there is no one actively working on solving design issues with Origin Policy.
- Event Timing: Shipped the API, which should be available on Chrome 85 (see chromestatus entry).
- Page Visibility: Socialized our proposal and based on feedback will work on shipping VisibilityStateEntry (see the explainer).
- Layout Instability sources: Shipped the
sourcesattribute, which should be available on Chrome 84 (see chromestatus entry). - Fixed layout shifts being reported from controls in the video element, see relevant bug. The fix is available on Chrome 85.
- Largest Contentful Paint removal: Added a metric that computes an experimental version of LCP which includes content that is removed from the page. We're waiting to get Stable data in order to decide whether this is an improvement over the existing LCP metric.
- Final Largest Contentful Paint: Wrote a proposal on how to surface the final LCP candidate to a page, but this work has been deprioritized for the time being.
- Paint Timing: Implemented a couple of fixes and now pass two more tests, but more work is needed to pass all of them.
- Documentation: Submitted feedback on some of the metrics content on web.dev, most of which was actioned upon. Updated MDN entries for core web vitals metrics.
- Facebook-driven APIs: Landed support for predicting touch and gesture events for isInputPending.
-
{#measure-memory-20202}Work towards shipping performance.measureMemory. This API intends to provide memory measurements for web pages without leaking information. It will replace the non-standard performance.memory and provide more accurate information, but will require the website to be cross-origin isolated. Try it out with the Origin Trial here! Deliverables for this quarter:
- Extend the scope of the API to workers.
- Draft a spec.
-
{#spas-20202}Work towards web perf support for Single Page Apps (SPAs). SPAs have long been mistreated by our web performance APIs, which mostly focus on the initial page load for ‘multi-page apps’. It will be a long process to resolve all measurement gaps, but we intend to start making progress on better performance measurements for SPAs by using a data-driven approach. Deliverables for this quarter:
- Implement a strategy for measuring the performance of SPA navigations in RUM, based on explicit navigation annotations via User Timing.
- Partner with some frameworks to gather data using said strategy.
- Socialize an explainer with our ideas.
-
{#page-abandonment-20202}Work towards web perf support for page abandonment. Currently, our APIs are blind to a class of users that decide to leave the website very early on, before the performance measurement framework of the website is set into place. This quarter, we plan to create and socialize a proposal about measuring early page abandonment.
-
{#event-timing-20202}Ship the full Event Timing API. Currently, Chrome ships only ‘first-input’ to enable users to measure their First Input Delay. We intend to ship support for ‘event’ so that developers can track all slow events. Each entry will include a ‘target’ attribute to know which was the EventTarget. We’ll support a durationThreshold parameter in the observer to tweak the duration of events being observed. Finally, we’ll also have performance.eventCounts to enable computing estimated percentiles based on the data received.
-
{#page-visibility-20202}Ship a Page Visibility observer. Right now, the Page Visibility API allows registering an event listener for future changes in visibility, but any visibility states prior to that are missed. The solution to this is having an observer which enables ‘buffered’ entries, so a full history of the visibility states of the page is available. An alternative considered was having a boolean flag in the PerformanceEntry stating that the page was backgrounded before the entry was created, but there was overwhelming support for the observer instead.
-
{#fb-driven-20202}Provide support for two Facebook-driven APIs: isInputPending and JavaScript Self-Profiling. The isInputPending API enables developers to query whether the browser has received but not yet processed certain kinds of user inputs. This way, work can be scheduled on longer tasks while still enabling the task to stopped when higher priority work arises. The JS Self-Profiling API enables developers to collect JS profiles from real users, given a sampling rate and capacity. It enables measuring the performance impact of specific JS functions and finding hotspots in JS code.
-
{#cls-sources-20202}Ship the sources attribute for the LayoutInstability API. The Layout Instability API provides excellent information about content shifting on a website. This API is already shipped in Chrome. However, it’s often hard to figure out which content is shifting. This new attribute will inform developers about the shifting elements and their locations within the viewport.
-
{#lcp-removal-20202}LargestContentfulPaint: gather data about LCP without excluding DOM nodes that were removed. The Largest Contentful Paint API exposes the largest image or text that is painted in the page. Currently, content removed from the website is also removed as a candidate for LCP. However, this negatively affects some websites, for instance those with certain types of image carousels. This quarter, we’ll gather data internally to determine whether we should start including removed DOM content. The API itself will not change for now.
-
{#final-lcp-20202}(Stretch) Work on exposing the ‘final’ LargestContentfulPaint candidate. Currently LCP just emits a new entry whenever a new candidate is found. This means that a developer has no way to know when LCP is ‘done’, which can happen early on if there is some relevant user input in the page. We could consider surfacing an entry to indicate that LCP computations are finished and including the final LCP value, when possible. There’s also an idea to include some heuristics to get a higher quality signal regarding whether the LCP obtained seems ‘valid’. If we have time this quarter, we’d be happy to do some exploration on this.
-
(Stretch) ResourceTiming: outline a plan to fix the problem of TAO (Timing-Allow-Origin) being an opt-in for non-timing information such as transferSize. This may mean using a new header or relying on some of the upcoming new security primitives in the web. If we have time this quarter, we’d like to begin tackling this problem by socializing a concrete proposal for a fix.
-
{#paint-timing-20202}Paint Timing: change the Chromium implementation so it passes new web platform tests. These tests are based on the feedback from WebKit. They intend to ship First Contentful Paint in the near future!
-
{#documentation-20202}Improve the documentation of our APIs on MDN and web.dev. We have been busily shipping new web perf APIs, but some of the documentation of them has lagged behind. For instance, we’ll make sure that there’s MDN pages on all of the new APIs we’ve shipped, and we’ll collaborate with DevRel to ensure that the documentation on web.dev is accurate.