Summary

  • The W3C's 2013 Performance Timeline Recommendation gave pages PerformanceEntry records and getters such as getEntriesByType(). Authors could inspect the browser's collected measurements.
  • A 2015 Level 2 draft added PerformanceObserver: a callback for new entries as the browser records them. The 2016 Candidate Recommendation and current specification refine the notification and buffer rules.

A newsroom may know that its front page feels slow without knowing which part kept the reader waiting. The browser has a timing ledger: a navigation, a resource, an author mark. In the W3C's 2013 Performance Timeline Recommendation, each item has a name, type, start time and duration. Methods such as getEntries() and getEntriesByType() return copies of the entries already in the ledger. It was a useful drawer. The editor still had to decide when to open it.

The awkward part arrives after the first check. New measurements keep coming while images load, scripts work and the page changes. Code can check the drawer again and again, hoping to catch the right card before a finite buffer fills. That is a peculiar job for an application: the browser knows exactly when it writes an entry, while the application keeps asking whether the browser has written one yet. A person ringing the office bell would make a better clerk.

The Performance Timeline Level 2 Working Draft of September 2015 introduced that bell. Its examples set the two styles side by side: one reads buffered entries; another creates a PerformanceObserver, supplies a callback and observes selected entry types. The callback receives an entry list when the browser records matching metrics. The page can process fresh evidence in batches and disconnect when the watch is over. The browser has taken the timing of notification onto its side of the desk.

The W3C publication history dates the Level 2 first public draft to 16 July 2015 and records the later drafts. The Candidate Recommendation of 8 December 2016 carries the observer into a more settled account of registration, entry types and callback delivery. This was a change in who notices a measurement, not a new definition of whether a slow page feels slow. The reader's patience has always been more direct than an API.

An observer needs an editorial assignment. A team may listen for resource entries while investigating a page's image loading, or for author marks around a costly interaction. It chooses which types to watch and what conclusion to draw. The platform supplies a common entry shape and a notification path; the site supplies the question. A bell that rings for every card without anyone reading them only makes a noisy office.

The current Performance Timeline specification describes new entries and, when requested, buffered entries. It also describes per-type buffers and counts for entries that get dropped. The newsroom analogy has a sharp edge: a full tray cannot prove that nothing happened while no card was retained. An observer should register early enough for its investigation, use buffered retrieval where the type supports it, and inspect the records it receives rather than treating the bell as an all-seeing witness.

The result is a small but consequential shift in control. Browser engineers define how timing entries enter the common timeline and when observers are notified. Page authors decide which signals deserve attention, how to relate them to a real reader's experience, and when to stop listening. The clock does its own clerical work. The newsroom still has to write the story of why the page kept someone waiting.