- From: Mike Jackson <notifications@github.com>
- Date: Fri, 06 Jun 2025 08:45:40 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/878/2949687656@github.com>
mwjacksonmsft left a comment (w3ctag/design-reviews#878) Hi @martinthomson - Thank you for the reply, and your patience with my delayed response. I'm concerned that if we allow the API to fail (or return an empty list), we will end up causing web interop issues. A quick search on GitHub reveals that many developers assume that an entry is always returned: https://github.com/search?q=performance.getEntriesByType%28%27navigation%27%29%5B0%5D.&type=code Additionally, samples of how to use the API also exclude empty list/null checks: * https://web.dev/articles/navigation-and-resource-timing * https://w3c.github.io/navigation-timing/#example-3 If we were able to address those interop concerns, I'd be concerned that it would be less private in the "high" confidence case. The goal of this work is to provide developers and RUM providers a signal indicating that the metrics might not accurately represent the website’s performance due to external factors beyond their control. Improving the privacy of existing metrics returned by this API is not within the scope of this work. The noise being added is to prevent the confidence bit from serving as an additional entropy source for user identification. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/878#issuecomment-2949687656 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/878/2949687656@github.com>
Received on Friday, 6 June 2025 15:45:44 UTC