Repository navigation
PerformanceEntry.id is shadowed by PerformanceElementTiming.id. #218
Description
PerformanceEntry is defined here:
https://w3c.github.io/performance-timeline/#the-performanceentry-interface
PerformanceElementTiming is defined here:
https://w3c.github.io/element-timing/#sec-performance-element-timing
PerformanceElementTiming extends PerformanceEntry - yet both define an id attribute, with different types and different meaning.
interface PerformanceEntry {
readonly attribute unsigned long long id;
...
interface PerformanceElementTiming : PerformanceEntry {
...
readonly attribute [DOMString] id;
...
Looking at both specifications, the id in PerformanceElementTiming appears more useful - it is set to the id of the element that was observed; whereas, the id in Performance entry is some number that increments between subsequent entries, with no further meaning except that it currently takes part in initializing the PerformanceEntry.navigationId (see Step 5 of https://w3c.github.io/performance-timeline/#queue-a-performanceentry).
Therefore, I'm thinking it would be best to remove PerformanceEntry.id, and slightly rephrase the mechanism for assigning PerformanceEntry.navigationId so that it no longer references that attribute.
Please let me know what you think.
Additional references:
Activity
[-]PerformanceEntry.id shadows PerformanceElementTiming.id.[/-][+]PerformanceEntry.id is shadowed by PerformanceElementTiming.id.[/+]npm1 commentedon Mar 18, 2025
Yea incorrectly added in #192. I don't think Chrome shipped the PerformanceEntry
id, it should be removed from the spec. https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/timing/performance_entry.idlRemove PerformanceEntry.id and rephrase id generation.
mmocny commentedon Mar 19, 2025
Thanks @npm1 for chiming in!
I wonder if you or @clelland recall: was there an explicit design goal with introducing an
idtype for every PerformanceEntry (distinct from navigationId)?One reason might be to help with ordering, without relying on startTime.
For example, in Event Timing, it is possible for two sequential events (as per event dispatch / event processing time) to actually not have sequential
timeStampvalues, and so therefore not have a sequentialstartTimevalues [1].Because we currently try to keep performance entries sorted by
startTime, this means reporting isn't actually always in "entry creation" order. Though probably we could solve that without adding anid...[1]: Potentially this could happen if the browser process observes these events in one order, but the hardware timestamps are another order-- especially if using two different input modalities.
But more commonly this happens when we have synthetic events, where the hardware timeStamp is actually somewhat artificially defined in terms of other event timings, and so you have can have a mix of "real" and "synthetic" values.
mmocny commentedon Feb 26, 2026
I'll take a stab to clean this up, together with removing
navigationIdfrom this spec. That work is still part of a wicg project (soft-navigations) and I think that there should be a more generalized approach specific to the performance timeline (something that works for bfcache, prerendering, but maybe also visibilitychange...) andnavigationIdmight not be the right term for that.