Use the Performance Observer API to monitor paint timing, layout shifts, and long tasks in real time.
The Performance Observer API hands your page a log of its own performance: paints, largest-contentful-paint candidates, layout shifts, long tasks, and input events. This playground attaches an observer to a live demo page in your own browser and streams every matching entry as it fires, showing raw fields like name, startTime, duration, and type-specific extras, so you can learn the API before writing production code. The surprise most people hit: observers are blind to the past. An observer created after an event fired sees nothing unless you pass buffered: true.
A concrete input and expected output from the current implementation.
Input
const po = new PerformanceObserver(list => {
for (const e of list.getEntries()) {
console.log(e.name + ': startTime ' + Math.round(e.startTime) + ' ms, duration ' + e.duration);
}
});
po.observe({ type: 'paint', buffered: true }); Expected output
first-paint: startTime 312 ms, duration 0 first-contentful-paint: startTime 342 ms, duration 0
buffered: true makes the observer replay paint entries recorded during page load, in startTime order. first-paint always fires before or together with first-contentful-paint, both carry duration 0, and the millisecond values vary per load, so only the names, ordering, and zero durations are portable.
You pick entry types, and the tool registers a PerformanceObserver for each against the demo page. Matching entries arrive in batches, never one at a time, so the playground calls getEntries() and renders each entry's fields (name, startTime, duration, plus type-specific extras like layout-shift value or task attribution) as a row in a live table, with buffered: true entries replayed immediately at registration.
Paint emits first-paint and first-contentful-paint once each; layout-shift emits only when layout actually moves; longtask fires only for main-thread tasks over 50 ms; largest-contentful-paint re-fires whenever a new largest element appears. The observer cannot produce an entry for an event that never happened, which is why an empty table is itself a finding.
Not necessarily. Scrolling does not create layout-shift entries, and shifts that follow recent user input are still reported but flagged hadRecentInput: true, so they would still show as rows. A truly empty table means either the shifts happened before the observer registered (add buffered: true) or the layout genuinely never moved.
Yes - that is what buffered: true is for. It replays entries of that type recorded since navigation started. Two limits: it reaches back only to the start of the current page load, and the browser's entry buffer can drop old entries when it overflows (common with resource entries), so replaying everything is not guaranteed.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Format, validate, and beautify JSON with syntax highlighting and error detection.
Encode text or files to Base64 and decode Base64 strings back to their original form.
Format and indent SQL queries for better readability across all major dialects.
Convert HTML markup into clean Markdown syntax with support for tables and lists.
Write Markdown and see the rendered HTML output in real time with live preview.
Visualize unified diffs and patch files with color-coded additions and deletions.