In a browser, how do you use performance.mark() and performance.measure() to time a block of your own application code, and where do the results end up?

## What the User Timing API is The browser already records timestamps for things it does itself — the navigation, every subresource fetch, paint milestones. The User Timing API lets *your* code contribute entries to that same timeline, so application-level phases ("hydrate", "first render of the dashboard", "filter recomputed") sit next to the browser's own events in one ordered list of `PerformanceEntry` objects. Every entry has four common fields: `name`, `entryType`, `startTime` and `duration`. A mark has `entryType: 'mark'` and a `duration` of 0. A measure has `entryType: 'measure'` and a real duration. ## Marks `performance.mark(name)` records the current high-resolution time under a name. "High resolution" means a `DOMHighResTimeStamp`: a floating-point number of milliseconds measured from `performance.timeOrigin` (the moment the document's time began), not a Unix-epoch value. In modern browsers the call also *returns* the created `PerformanceMark`, so you can use it immediately. Marks are not unique. Marking the same name twice creates two entries; both are kept, and `performance.measure` resolving a mark by name uses the most recent one with that name. If you need extra context on the entry, `performance.mark('x', { detail: { userId: 7 } })` attaches arbitrary structured data. ## Measures `performance.measure(name, startMark, endMark)` computes the interval between two named marks and stores it as one entry. Both mark arguments are optional in useful ways: - `performance.measure('boot')` — measures from the start of the timeline to now. - `performance.measure('boot', 'boot:start')` — measures from that mark to now, which is the common shape when you only bothered to mark the beginning. There is also an options form, `performance.measure(name, { start, end, duration, detail })`, where `start`/`end` may be mark names *or* raw timestamps. That matters when the numbers came from somewhere else — a server-provided timing, or a value you already captured with `performance.now()`. ```javascript performance.mark('filter:start'); applyFilters(); performance.measure('filter', 'filter:start'); ``` ## Reading the results Two ways, and they are not interchangeable: - **Pull.** `performance.getEntriesByType('measure')` or `performance.getEntriesByName('boot')` returns what is currently in the buffer. Simple, but you have to choose a moment to look, and you may look too early. - **Push.** A `PerformanceObserver` observing `{ entryTypes: ['mark', 'measure'] }` invokes your callback as entries are created. This is what a real-user-monitoring script uses, because it never has to guess when the work finished. ```javascript new PerformanceObserver((list) => { for (const entry of list.getEntries()) { report(entry.name, entry.duration); } }).observe({ entryTypes: ['measure'] }); ``` ## Where the entries show up Beyond your own code, marks and measures are surfaced by tooling. A performance recording in browser devtools renders measures as named bars on a timings track, aligned with the main thread — so a 900 ms "hydrate" measure can be read directly against the long task that produced it. Some analytics and RUM vendors also collect `measure` entries automatically, which makes User Timing a cheap way to get app-specific phases into a dashboard without inventing a transport. ## Why not just subtract timestamps `const t = Date.now()` then `Date.now() - t` gives you a number, and nothing else. It is millisecond-granular, it is wall-clock time (subject to the system clock changing under you), and it produces no timeline entry, so no tool can see it. `performance.now()` fixes the precision and monotonicity problems but still produces no entry. Marks and measures are the version that other tools can consume. ## Hygiene The timeline buffer is finite and shared. In a single-page app that marks something on every route change, entries accumulate for the life of the tab. Call `performance.clearMarks(name)` and `performance.clearMeasures(name)` once you have reported a phase, or the entry list you later query gets long and the retained detail objects keep references alive. Also note that marking is not free-of-charge instrumentation you can sprinkle everywhere at maximum density: each call does real work. The cost is small enough for phase-level instrumentation and far too high inside a hot loop that runs thousands of times per frame. ## Naming Pick a convention and keep it, because these names become dashboard keys. A common one is `area:phase` — `checkout:start`, `checkout:end`, measure `checkout`. Keep the measure name stable even if the mark names change; the measure is the thing you will chart.