1 din 12

Interactions and Event Timing

2 din 12

Responsiveness

  • Current metric in Core Web Vitals: First Input Delay

Problems:

  • Does not capture ‘end to end’
  • Only measure the ‘first’

3 din 12

End-to-end

4 din 12

Problem: determining ‘end’

  • Async work requires tracking some form of ‘causality’, but this would need to be a heuristic
  • Related: Patrick Hulce’s talk on longtasks

5 din 12

Problem: aggregating

  • A single user interaction may correspond to a large sequence of events

�pointerdown, touchstart, pointerup, touchend, mousedown, mouseup, click�

6 din 12

Problem: aggregating

We want to be able to enable tracking performance:

  • Per events
    • Event handler durations
    • Event queueing times
  • Per user interaction
    • End-to-end latency

7 din 12

Proposed solution

Event Timing already exposes per-event information, so we can enable per-interaction information by adding some interaction identifier.

partial interface PerformanceEventTiming {

unsigned long long interactionID;

}

8 din 12

9 din 12

Example: longest duration

const processedInteractions = {};�observerCallback(list) {� entries.forEach(entry => {� if (processedInteractions[entry.interactionID])� continue;� processedInteractions[entry.interactionID] = true;� processInteraction(entries, entry.interactionID);�}

10 din 12

Example (cont)

�processInteraction(entries, id) {� const relevantEntries = entries.filter(� e => e.interactionID = id);� const interactionDuration = Math.max(relevantEntries.map(� e => e.duration));� // Send interactionDuration to analytics.�}

11 din 12

Alternatives considered

  • New Interactions API
    • Would require yet another API
    • Would be able to support some notion of input delay.
    • Unclear how to interpret event handling durations.
  • Polyfill on top of Event Timing
    • Events with ‘close’ timeStamps should belong in the same interaction
    • Problem with synthetic events: heuristic complicated and not perfect

12 din 12

Thanks!