v153 · in developer trial (behind a flag)

SpeechRecognitionResult Timestamps (WebSpeech API)

The Web Speech API is a black box about when in the audio a phrase was spoken. A proposal (web-speech-api PR #192, unmerged) adds two nullable attributes — audioStartTime and audioEndTime — to SpeechRecognitionResult, letting you line transcripts up with a media timeline and measure on-device recognition latency. These demos call the real Web Speech API and look for the new fields, degrading honestly when your engine returns null or the attributes are absent.

concepts

  1. On-device latency monitor

    Compute processing lag as event.timeStamp − result.audioEndTime and feed that signal into an application-defined fallback policy.

  2. Caption timeline mapper

    Place each recognised phrase on an audio timeline using audioStartTime and audioEndTime, the way a captioning or transcript-scrubbing tool would.

  3. Result-object capability probe

    Detect the timestamps correctly: SpeechRecognitionResult has no constructor to probe, so you must inspect a live result instance. Covers the nullable contract and the 2 ms fuzzing mitigation.

why timestamps matter

Two problems drove the proposal. Timeline association: the API currently gives no direct way to map a result back to its source-audio segment, complicating caption timelines, transcript scrubbing, and highlight-as-you-play. Latency tracking and failover: as recognition moves on-device for privacy, performance now depends on the visitor's hardware. Exposing audioEndTime lets an app compare it against the result event's timeStamp to detect processing lag and invoke an application-defined fallback if one is configured and appropriate. The timestamps do not themselves provide, authorize, or make a cloud transition seamless.

the shape

partial interface SpeechRecognitionResult {
  readonly attribute DOMHighResTimeStamp? audioStartTime;  // ms, relative to time origin
  readonly attribute DOMHighResTimeStamp? audioEndTime;    // ms, relative to time origin
};

Both attributes are nullable: if the recognition backend does not supply segment timing, they are null — not an error. The explainer proposes fingerprinting mitigation by rounding to 2 ms precision or matching the site-wide timer-resolution policy. That proposal-level value is not evidence of what an eventual implementation will ship.

Availability, per the chromestatus API (updated 2026-07-16): the v153 milestone listing records this as In developer trial (Behind a flag) with desktop dev trial at 153; the feature detail gives no ship milestone and status text “Proposed”. The spec change itself (PR #192) is unmerged as of 2026-07-24, and the attributes are not yet in Chromium main's speech_recognition_result.idl — so treat every value here as proposal/in-flux, not settled platform behavior.

enabling it

ChromeStatus lists a developer trial starting at 153, but the current Chromium IDL and runtime-feature inventory do not yet establish an enabling recipe. If a later implementation is wired to --enable-experimental-web-platform-features, that catch-all may expose it; today, presenting that flag as sufficient would be unsupported. A timing-capable recognition backend is also required, and an on-device backend may require a downloaded speech model. The PR remains unmerged, so the demos report absent attributes honestly. When the attributes are absent or null, the demos say so plainly and offer a clearly-labelled sample walkthrough instead of faking values.

references