Summary

  • W3C's first public Resource Timing draft of 24 May 2011 moved the stopwatch from the page as a whole to individual resources such as images, with fields for fetching, name, initiator and network phases.
  • The 30 March 2017 Level 1 Candidate Recommendation described a performance timeline of resource entries, a finite buffer and the Timing-Allow-Origin handoff for detailed cross-origin timings. The browser recorded the splits; the publisher still had to investigate the slow guest.

The page was slow, and every part of it pointed at another part. The hero image blamed the stylesheet. The stylesheet blamed a script. The script mumbled something about the server. A single page-load time could confirm that the reader had waited. It could not tell the editor which suitcase had jammed the baggage carousel. Resource Timing took out a tray of stopwatches and handed one to each arriving piece.

The W3C's first public Resource Timing Working Draft of 24 May 2011 began with the need to understand latency inside a page. Its example looked at the fetch time of an image rather than treating the entire page as one duration. This was a different scale from the document's navigation clock. A page arrives with many separate resources: photographs, styles, scripts and other fetches. A late image can be investigated as an image, with its own request and response, instead of disappearing into the page's total.

The draft described a record for each resource with a name, a type of initiator and points along the fetch. fetchStart, domainLookupStart, connectStart, requestStart, responseStart and responseEnd gave the editor a way to ask where the time went. The answer might involve name lookup, connection setup, waiting for the first byte or receiving the rest. A stopwatch with several hands is more useful than a red light labeled “slow.” It directs attention toward a stage of work, not a convenient scapegoat.

There was a practical joke hidden in the fields: some hands can barely move. A browser may reuse a connection or retrieve a resource from cache. Then parts of the usual network journey do not need to happen again, and timing points can coincide. The record is an account of the particular fetch the browser observed. An equal pair of timestamps can describe reuse, not a malfunctioning instrument. If a team wants to compare two page visits, it has to know whether one used a warm cache and the other arrived cold.

By the W3C Resource Timing Level 1 Candidate Recommendation of 30 March 2017, the interface sat in a performance timeline. The text's example called performance.getEntriesByType('resource'), looked for entries whose initiatorType was img, and compared responseEnd with startTime. An editor could line up the page's image requests and see which one occupied time. The same model extended to other resource types. The browser had a ledger of arrivals; the publisher could finally stop interviewing the entire page as one suspect.

The ledger had a size. The 2017 text described a resource timing buffer and methods such as setResourceTimingBufferSize() and clearResourceTimings(). A page with many fetches could fill its allotted space. The publisher collecting measurements needed to decide how much to retain and when to clear it. A notebook that runs out of paper halfway through a busy page is still a notebook; the missing entries make the subsequent diagnosis thin. The buffer turns measurement into an operating choice rather than a free, infinite diary.

A more interesting choice belonged to someone outside the page. A resource from another origin could appear in the timeline, but the browser limited detailed fields by default. The Timing-Allow-Origin response header allowed the resource's own server to authorize more detailed timing for a named origin. This was a bargain between the page that wanted a clock and the supplier whose resource was being timed. The publisher could measure its own work in detail. It could not demand the same intimate stopwatch reading from every foreign image or script merely because it placed one on the page.

That limit shaped what an editor could conclude. A timing entry might name an external image and show a duration, while DNS, connection and response details remained unavailable. Calling the blank fields “zero milliseconds of work” would be a poor reading of the ledger. They represented a boundary on disclosure. If the supplier granted timing access, the browser could reveal more phases; if it did not, the page had to diagnose with the fields actually visible. The outside server held the curtain cord for its own clock.

The W3C Candidate Recommendation Draft dated 1 September 2026 still develops this per-resource view. It is a later document with more attributes and a larger described buffer than the early texts. The chronology matters because the 2011 draft, 2017 Candidate Recommendation and 2026 draft do not describe one frozen interface. The durable idea is the same: the browser records the time of a resource fetch in a standard shape, and the site can inspect the entries that its page produced.

A stopwatch can make one image a promising subject for investigation. It cannot tell the editor whether that image was above the fold, whether its delay held the headline back or whether readers noticed. Those questions require the page's layout and an observation of what readers actually saw. Resource Timing supplied the fetch record. The decision about which resource to change remained with the team that built the page. The image may have taken longest; perhaps the real fix is to move it, resize it, serve it differently or let it arrive later.

Resource Timing changed the conversation in the control room. “The page was slow” was a complaint. “This image request waited here, this stylesheet used a reused connection, and this foreign resource's detailed clock is closed” was a set of things an operator could check. The page still needed an editor willing to read the stopwatches. At least the hero image could no longer blame the stylesheet without producing its own timecard.