PerformanceEntry

PerformanceEntry is the common browser interface for describing a measured performance event. It provides identifying information such as `name` and `entryType`, plus timing data such as `startTime` and `duration`.

A `PerformanceEntry` represents one recorded item in the browser's performance timeline. Different Web Performance APIs create different entry types, but they expose a shared set of timing-oriented properties.

The `name` property identifies the entry, while `entryType` identifies what kind of performance entry it is. For example, navigation, resource, paint, and user-timing measurements can appear as different entry types.

`startTime` indicates when the event began relative to the page's performance time origin. `duration` indicates how long the measured event lasted. These values use high-resolution timing rather than ordinary wall-clock timestamps.

You commonly access entries through the Performance API, such as `performance.getEntries()`, `performance.getEntriesByType()`, or `PerformanceObserver`. The concrete entry object may expose additional properties depending on its specific entry type.

Key points

Interview questions

How would you get all resource performance entries?

You can call `performance.getEntriesByType('resource')`. It returns the resource entries currently available in the performance timeline. Each result follows the `PerformanceEntry` interface and can also expose resource-specific properties. For a long-running page, an observer can be more appropriate when you need to react to entries as they arrive.

What is a PerformanceEntry?

A `PerformanceEntry` is a standardized object representing a measured item in the browser's performance timeline. It includes common information such as its `name`, `entryType`, `startTime`, and `duration`. Different Web Performance APIs can create different kinds of entries. The concrete entry type may also provide additional fields.

What is the difference between `startTime` and `duration`?

`startTime` describes when the measured event began relative to the performance time origin. `duration` describes how long that event took. They are both expressed using the browser's high-resolution performance timing model. Neither should be interpreted as a Unix timestamp.

Why shouldn't you assume every PerformanceEntry has the same fields beyond the common properties?

`PerformanceEntry` defines the common interface, but specialized entry types extend the information available for particular measurements. A resource entry, for example, can expose resource-specific timing information that is not part of the generic interface. Code should therefore use the entry type when accessing specialized properties. This avoids relying on fields that may not exist on another entry type.

When would you use PerformanceObserver instead of directly reading PerformanceEntry objects?

Direct performance methods are useful when you want to inspect entries already present in the performance timeline. `PerformanceObserver` is useful when you want to react to matching entries as the browser makes them available. This is particularly useful for measurements that occur after initial script execution. The observer can filter the entry types it is interested in.