Skip to content

Add types for window.performance.getEntriesByType #33866

Open
microsoft/TypeScript-DOM-lib-generator
#2572

Description

@third774

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.

Activity

  1. third774 commented on Oct 8, 2019

    @third774
    Author

    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?

  2. TaylorPzreal commented on Jul 30, 2020

    @TaylorPzreal

    Waiting the feature.

  3. DerGernTod commented on Feb 3, 2022

    @DerGernTod

    any updates on this?

  4. HolgerJeromin commented on Sep 8, 2022

    @HolgerJeromin
    Contributor

    This is fixed since a few versions. Probably 4.4 or even earlier.
    microsoft/TypeScript-DOM-lib-generator#1094 (comment)

  5. HolgerJeromin commented on Sep 21, 2022

    @HolgerJeromin
    Contributor

    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.

  6. schickling commented on Apr 9, 2023

    @schickling

    Is someone aware of any available NPM package that provides the missing types as a workaround for now?

  7. RyanCavanaugh commented on Jul 25, 2025

    @RyanCavanaugh
    Member

    Confirmed on 5.9, the requested specialization is still not there.

    It'd be great if OP's code example were correct (it's .performance not .navigator) and clarified the current behavior

  8. DerGernTod commented on Jul 28, 2025

    @DerGernTod

    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/getEntriesByName

    I 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 a PerformanceMark.

  9. Ankith-B commented on Oct 11, 2026

    @Ankith-B

    I'd like to take this. The change belongs in TypeScript-DOM-lib-generator, so I've prepared it there using additionalSignatures in overridingTypes.jsonc, the same mechanism getContext("2d") uses:

    • getEntriesByType("mark" | "measure" | "resource") → PerformanceMark[] / PerformanceMeasure[] / PerformanceResourceTiming[]
    • the matching getEntriesByName(name, type) overloads (as Gernot Raudner (@DerGernTod) suggested)
    • on both Performance and PerformanceObserverEntryList; other strings keep returning PerformanceEntryList

    These three entry types exist in every environment that exposes Performance, so the worker libs get the same overloads. npm test passes. 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.

  10. added a commit that references this issue on Oct 11, 2026
    ec22274
  11. Ankith-B commented on Oct 11, 2026

    @Ankith-B
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    BugA bug in TypeScriptDomain: lib.d.tsThe issue relates to the different libraries shipped with TypeScriptHelp WantedYou can do this

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions