An Interaction to Next Paint score can tell a commerce team that responsiveness is poor, but not which customer action created the delay. A filter chip, variant selector, quantity stepper, cart drawer, address lookup, and payment accordion all compete for the same main thread. Treating them as one site-wide number makes prioritization unnecessarily vague.
The Event Timing API supplies a better diagnostic layer. It exposes timing entries for supported interactions, including an interactionId that groups related events and timestamps that separate queueing from event-handler work. This guide turns those primitives into an ecommerce operating method. The examples are illustrative; they are not universal conversion benchmarks.
Table of Contents
- Start with the customer action
- Understand the three latency phases
- Group events into interactions
- Build an ecommerce interaction scorecard
- Use percentiles without hiding reach
- Connect diagnosis to fixes
- Protect privacy and data quality
- The EcomToolkit view
Start with the customer action
Performance work becomes useful when the unit of analysis matches a decision. “Product page INP is slow” is a symptom. “Colour-swatch selections on products with the recommendations widget loaded have high input delay” is a testable operational statement.
Define a small interaction taxonomy before collecting detailed entries. Use stable names such as filter_apply, variant_select, add_to_cart, cart_quantity, and checkout_section_expand. Record the page template and feature state, but avoid high-cardinality labels such as raw product titles, search queries, or customer identifiers.
The W3C Event Timing specification defines timing information for supported user interactions and exposes PerformanceEventTiming. Continuous events such as pointer movement are outside the useful scope of this API. That makes the interface a diagnostic source for discrete actions, not a complete replay of everything a shopper does.
Understand the three latency phases
For an event entry, input delay can be represented as processingStart - startTime. Processing duration is processingEnd - processingStart. The remaining time until the next rendered frame is the presentation portion of the entry’s total duration. These pieces point to different fixes.
| Latency phase | What it usually means | Ecommerce investigation |
|---|---|---|
| Input delay | The main thread was busy before the handler began | Long tasks, third-party scripts, hydration, tag execution |
| Processing | Event handlers and synchronous work consumed time | Variant logic, cart calculation, DOM work, state updates |
| Presentation | Work after handlers delayed the next paint | Layout, style recalculation, image decode, rendering complexity |
Suppose an illustrative add-to-cart interaction lasts 420 milliseconds: 210 milliseconds before processing, 70 milliseconds in handlers, and 140 milliseconds before paint. Rewriting the click handler alone cannot remove the largest component. The first investigation should ask what occupied the main thread before the click was serviced.
The opposite pattern needs a different response. If a filter action has little input delay but 260 milliseconds of processing, inspect synchronous filtering, serialization, state propagation, and DOM mutation. A phase breakdown prevents teams from assigning every slow interaction to “too much JavaScript” without identifying where that JavaScript matters.
Group events into interactions
A single physical action can create more than one low-level event. The specification’s interactionId exists to connect relevant entries to the same user interaction. Reporting individual event rows as if each were a separate shopper action can inflate counts and pick the wrong duration.
Aggregate entries by interaction ID within the page lifecycle, then retain the longest duration and the relevant phase values for that interaction. Also keep the semantic action name assigned by your application instrumentation. Browser IDs are diagnostic join keys; they are not durable business identifiers and should not be compared across page loads.
Support varies, so feature-detect the entry type and record coverage. A dashboard should show both the number of measured interactions and the total eligible action count from application events. If only a subset of sessions exposes the timing data, the latency distribution describes that subset.
Do not attach raw DOM text or unrestricted selectors. A button target can contain customer-entered information, localized content, or unstable generated class names. Map targets to an allow-listed component name in the browser and discard anything outside that list.
Build an ecommerce interaction scorecard
The scorecard should help a product or engineering owner decide what to fix. At minimum, segment by action, template, device class, release version, and a coarse feature state. Keep the dimensions bounded so the dataset remains affordable and the sample size remains visible.
| Illustrative action | Measured interactions | p75 total | Dominant phase | First owner |
|---|---|---|---|---|
| Variant select | 18,400 | 180 ms | Processing | Product UI |
| Filter apply | 9,700 | 310 ms | Processing | Search team |
| Add to cart | 12,100 | 260 ms | Input delay | Platform performance |
| Cart quantity | 4,900 | 220 ms | Presentation | Cart UI |
| Checkout expand | 6,300 | 140 ms | Mixed | Checkout owner |
These values are hypothetical. Their purpose is to show the structure: reach, tail latency, phase, and ownership appear together. A 400-millisecond issue affecting fifty internal users may rank below a 260-millisecond issue encountered by thousands of shoppers.
Link the scorecard to release annotations. If add-to-cart input delay changes after a marketing tag release, the annotation narrows the investigation. If latency is stable but the interaction count falls, that can indicate broken instrumentation or a journey change rather than an improvement.
Use percentiles without hiding reach
Interaction latency is usually skewed. A mean can remain stable while a meaningful minority experiences very slow responses. Report at least the median and p75, and use p90 or p95 for diagnostic triage when the sample is large enough. Avoid comparing unstable high percentiles from tiny slices.
Always show the denominator. A p75 based on 80 observations is not equivalent to one based on 80,000. Also report the share of sessions with at least one measured interaction. The existing pooled percentile guide explains why averaging precomputed percentiles across groups produces misleading totals.
Do not rank actions on latency alone. Combine latency with interaction reach and commercial criticality. A slow image-zoom control may affect many sessions but carry less immediate risk than a moderately slow payment-method selector. The weighting is a prioritization policy, not proof of revenue caused by milliseconds.
Connect diagnosis to fixes
When input delay dominates, inspect long tasks around the interaction timestamp and identify script ownership. Defer nonessential tags, split application work, and verify that a change improves real-user entries rather than only a laboratory trace. The scheduler.yield guide covers one cooperative scheduling technique.
When processing dominates, profile the handler path. Look for repeated parsing, broad state updates, synchronous storage access, and work that can happen after the next paint. For filters, separate immediate visual acknowledgement from a network response. For add-to-cart, avoid blocking feedback on unrelated recommendation refreshes.
When presentation dominates, inspect layout invalidation, component size, animations, and image decode. Confirm that the intended UI state actually becomes visible at the next paint. A spinner that paints quickly but leaves the control unusable is not a completed commerce interaction.
Validate fixes by action and release cohort. A global INP improvement can hide a regression in a low-volume but high-value checkout step. Conversely, one extreme event should not block a release if the regression is not repeatable and does not affect the measured population materially.
Protect privacy and data quality
Sample if volume or cost requires it, but keep the sampling probability and scale counts appropriately. Use the same policy across comparison windows. If sampling changes, annotate the series; otherwise a coverage change can look like a performance change.
Drop or hash no customer data because the safer design is not to collect it. Keep only approved action names, coarse page types, timings, browser capability, and release identifiers. Define retention according to diagnostic need. Interaction telemetry should not become an accidental behavioral profile.
Run automated checks for impossible sequences: processing should not begin before the event start, phase values should not be negative, and one interaction should not be counted several times in the same aggregation. Track browser-support coverage so a change in the client mix does not silently shift the metric.
The EcomToolkit view
Site-wide responsiveness is a useful alarm. Action-level Event Timing turns the alarm into work: which control, how many shoppers, which latency phase, and which team owns the next test. The best report preserves that line from browser evidence to operational decision.
If your performance dashboard cannot identify which commerce actions create the slow tail, request an EcomToolkit audit to build an interaction-level diagnostic model.
For a related practical question, read our guide to event delegation and ownership in dynamic product grids.
