The 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 keydown, mousedown, click, a 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 (pointerdown, pointerup, pointercancel, click) get grouped up as a single interaction and get dispatched from the event timing pipeline.
KeyInteractionStateMachine visualizes the state machine logic of how the keyboard related events (keydown, input, keyup) get grouped up as a single interaction and get dispatched from the event timing pipeline.
The convention mark_feature_usage marks the usage of a user feature which may impact performance so that tooling and analytics can take it into account. This requires the following steps:
Add a feature id to web_feature.mojom. It's recommended where applicable to prefix the feature name with kUserFeature..., indicating that this feature tracks a user defined feature. For an example, see the entry corresponding to kUserFeatureNgOptimizedImage.
Allow-list the feature added to be used with UKM-based UseCounter, by making an entry in UseCounterMetricsRecorder::GetAllowedUkmFeatures().
Add an entry to the map in PerformanceMark::GetUseCounterMapping() tying the user defined feature name (NgOptimizedImage in our example) to the UKM feature.
Instrument user framework/application code with performance.mark('mark_feature_usage', as described in the User Timing Level 3 specification.