renderer/core/timing directory contains files related to various web performance APIs.
The HR-Time specification introduces the Performance interface, which exposes a high resolution monotonic clock via performance.now() and enables comparing timestamps across various contexts via performance.timeOrigin. This interface is exposed on both Windows and Workers and implemented on the Performance file, with window and worker specific code on WindowPerformance and (WorkerPerformance)(./worker_performance.h), respectively. The Performance interface is tied to its DOM via DOMWindowPerformance and WorkerGlobalScopePerformance.
Any new high resolution timestamps exposed through the web need to be set to the correct resolution to prevent privacy or security issues, and hence should go through the MonotonicTimeTo* methods in Performance, which will delegate the rounding details to the TimeClamper.
The Performance-Timeline specification enables exposing additional performance measurements via two methods: directly to the Performance, which can be polled via getter methods, or to a PerformanceObserver, which runs a callback upon receiving new entries. The latter interface is implemented in PerformanceObserver, and is the recommended way to query entries. A single nugget of performance information is encapsulated in a PerformanceEntry, which is the
base interface. The type of the PerformanceEntry is codified in its
entryType attribute. Newer types of performance entries may not support polling queries via the Performance object, whereas all must support callback queries via PerformanceObserver. This information is the
availableFromTimeline bit in the registry. This registry also contains some additional useful information that is entry-type specific. Note that all of the interfaces listed in that table have corresponding files in this folder. While the objects exposing performance measurements via JS are concentrated in this folder, many of the computations are located in other folders. For instance, the Resource-Timing specification measures timing on fetches, and that timing needs to occur at the specific locations in code where the fetching occurs and then plumbed all the way to this folder.
The PerformanceEventTiming interface provides timing information about the latency of the first discrete user interaction, specifically one of
pointerdown followed by a
pointerup. (Pointer down may be the start of scrolling, which is not tracked.) This is a subset of the EventTiming API, and provides key metrics to help measure and optimize the first impression on responsiveness of web users. FirstInputStateMachine visualizes the state machine logic of how the first input event timing entry got dispatched from a pipeline of performance event entries.
The PerformanceEventTiming interface exposes timing information for each non-continuous event(fullList). Certain events can be further grouped up as interactions by assigning the same non-trivial interactionId. Others will have interactionId with value 0. The purpose of defining an interaction is to group events that fire during the same logical user gesture, so further analysis like INP can be done to better reflect the page responsiveness on user interactions.
PointerInteractionStateMachine visualizes the state machine logic of how the pointer related events (
click) get grouped up as a single interaction and get dispatched from the event timing pipeline.