Repository navigation
Add types for window.performance.getEntriesByType #33866
Description
Search Terms
getEntriesByType
PerformanceMark
PerformanceMeasure
PerformanceResourceTiming
Suggestion
Add types for the getEntriesByType API
I found this old issue (Jul 5, 2018) and saw that experimental API's are not included in lib.dom.d.ts. The following API's don't appear to have experimental warnings on them on the MDN docs. Hopefully this means these are no longer experimental and types can be added now?
https://developer.mozilla.org/en-US/docs/Web/API/PerformanceMark
https://developer.mozilla.org/en-US/docs/Web/API/PerformanceMeasure
https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming
Use Cases
Getting specific strongly typed information for the entries when accessed via this API.
Examples
// resources would be of type PerformanceResourceTiming[]
const resources = window.navigation.getEntriesByType("resource");
// resources would be of type PerformanceMeasure[]
const measures = window.navigation.getEntriesByType("measure");
// marks would be of type PerformanceMark[]
const marks = window.navigation.getEntriesByType("mark");
// paints would still be of type PerformanceEntryList
const paints = window.navigation.getEntriesByType("paint");Checklist
My suggestion meets these guidelines (not sure about the first one):
- This wouldn't be a breaking change in existing TypeScript/JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
- This feature would agree with the rest of TypeScript's Design Goals.
Reacted by Gernot Raudner, Christian Muñoz, TaylorPzreal, Lorenzo Pieri, Florian Schuck, Simon Siefke, Kesavan Kushalnagar, Timur Yerzin, Brad Frost, Leonardo Nascimento Cintra and 5 more
Activity
third774 commentedon Oct 8, 2019
Doh! Tried to open a PR for this, but looks like the work is over in https://github.com/Microsoft/TSJS-lib-generator. Should I move this issue to that repo?
TaylorPzreal commentedon Jul 30, 2020
Waiting the feature.
DerGernTod commentedon Feb 3, 2022
any updates on this?
HolgerJeromin commentedon Sep 8, 2022
This is fixed since a few versions. Probably 4.4 or even earlier.
microsoft/TypeScript-DOM-lib-generator#1094 (comment)
billyvg commentedon Sep 20, 2022
Holger Jeromin (@HolgerJeromin) That is a different issue that doesn't address the return type of
getEntriesByType(), see https://www.typescriptlang.org/play?ssl=14&ssc=1&pln=14&pc=61#code/PTAEAUFMCcDMHtoFsCGA7AxpAcigbgJYDmKALgfGgCoFIFpEDaAugFAaUDOpoa+xZCmgCiaUtAKROoALygA7vQAm8eQDoADjATJ0WNUUilR4yZwBCATyqWtACgDkfQiXKUHASgDcrViAjaiKiYkABKUvAArtBYNHQMLOxcPNAR0VjScopoKupacEF6kAZGJhJSVjb2AESpnFExkNXevv5QBbohALKQKJzRkIkcaNygSL39dbIKyqqagZ36hsZi5RbWtpB21eN9A80+fmDtOsFYXSjQANZDyWOXV5kzOXP5p0UlK6YVGzWo1wdWscFmdIOAUPRSHF6EQkiMeBoIWIntlcvMOqDPmUzJVNttEZCDkAHolgerJeromin commentedon Sep 21, 2022
Ok, missed that detail. Current state models spec:
https://w3c.github.io/performance-timeline/#extensions-to-the-performance-interface
But yes could be more clear by adding overridingTypes:
https://github.com/microsoft/TypeScript-DOM-lib-generator#when-the-type-exists-but-is-wrong
BTW, added type debug information to your playground link.
schickling commentedon Apr 9, 2023
Is someone aware of any available NPM package that provides the missing types as a workaround for now?
RyanCavanaugh commentedon Jul 25, 2025
Confirmed on 5.9, the requested specialization is still not there.
It'd be great if OP's code example were correct (it's
.performancenot.navigator) and clarified the current behaviorDerGernTod commentedon Jul 28, 2025
If this is going to be worked on, I'd like to highlight that this also applies to
performance.getEntriesByName- it supports a second argument specifying the type: https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByNameI think it makes sense to type these function return types depending on the second argument, so that if I call e.g.
performance.getEntriesByName("myMark", "mark"), I properly get aPerformanceMark.Ankith-B commentedon Oct 11, 2026
I'd like to take this. The change belongs in TypeScript-DOM-lib-generator, so I've prepared it there using
additionalSignaturesinoverridingTypes.jsonc, the same mechanismgetContext("2d")uses:getEntriesByType("mark" | "measure" | "resource")→PerformanceMark[]/PerformanceMeasure[]/PerformanceResourceTiming[]getEntriesByName(name, type)overloads (as Gernot Raudner (@DerGernTod) suggested)PerformanceandPerformanceObserverEntryList; other strings keep returningPerformanceEntryListThese three entry types exist in every environment that exposes
Performance, so the worker libs get the same overloads.npm testpasses. Types like"navigation","paint"and"largest-contentful-paint"only exist in the DOM lib, so I left them for a follow-up rather than make the worker libs reference missing types. Happy to add them if there's a preferred way to make overloads DOM-only.I'll open the PR on TypeScript-DOM-lib-generator unless you'd prefer a different approach.
Add typed overloads for Performance.getEntriesByType/getEntriesByName
Ankith-B commentedon Oct 11, 2026
Opened microsoft/TypeScript-DOM-lib-generator#2572.