Do not stop your AI video timer at provider success

howard hua — Fri, 04 Sep 2026 06:30:24 +0000

A successful video-generation response is not the same event as a video becoming playable in a browser. If a dashboard stops its timer at provider success, the number can exclude output transfer, browser loading, and the creator's review.

Here is a small, provider-independent pattern for instrumenting that gap. It is an example you can adapt, not a benchmark or a claim that one model is faster than another.

Disclosure: this engineering note was written with AI assistance and is published by FreyaVideo, an AI video tool. The related company-blog guides are linked where they provide background.

Give each milestone a precise meaning

Start by naming what the browser actually observes:

Event	Meaning in this example	What it does not prove
`submitted`	The user starts the generation request	The provider has accepted or begun work
`acknowledged`	The app receives a job acknowledgement	Rendering is finished
`provider_done_observed`	A poll or notification tells the app that output is ready	The browser can play that output
`playing`	The browser emits its first `playing` event for the output	The result meets the creator's brief
`accepted`	A person marks the output usable after review	Every previous attempt was successful

The word observed matters. A polling client can learn about completion several seconds after it happened. That delay belongs in a user-facing waiting-time measurement, but it is not evidence about GPU inference time.

Similarly, playing is a practical playback milestone, not an exact “first pixel appeared on the screen” measurement. It can also occur after playback resumes. Record the first event for a particular output, and document the definition.

This distinction is the central question in our guide to comparing AI video speed claims: which clock is the claim actually measuring?

Use one local clock for a single page visit

For elapsed time within one document, performance.now() provides a monotonic clock. It avoids the wall-clock adjustments that can affect a subtraction of two Date.now() values. The MDN reference also documents precision limits and differences in how browsers handle operating-system sleep.

Do not subtract a server timestamp from performance.now(). Do not take a value from an old page load and subtract it from a new page's reading. Both cases mix clock contexts.

The following ledger deliberately exists only in memory. Call start() directly before initiating the generation request, rather than when the page loads:

function createRunLedger(runId, now = () => performance.now()) {
  const startedAt = now();
  const marks = new Map();

  return {
    runId,
    mark(name) {
      // Keep the first observation of each milestone.
      if (!marks.has(name)) marks.set(name, now() - startedAt);
    },
    snapshot(outcome) {
      return {
        runId,
        outcome,
        clock: "browser-document-monotonic",
        elapsedMs: Object.fromEntries(marks),
      };
    },
  };
}

function start(runId) {
  const ledger = createRunLedger(runId);
  ledger.mark("submitted");
  return ledger;
}

The now argument makes the ledger easy to check with a deterministic clock. Calling mark("acknowledged") twice must keep the first value. An event that never happened stays absent; it is not recorded as zero milliseconds.

This code is only the ledger. Your application still needs request handling, authentication, polling, cancellation, persistence, and an explicit job state machine. Keeping those responsibilities separate makes the timing definitions easier to inspect.

Attach playback observation to the correct output

After the application observes a completed job, mark provider_done_observed. Before assigning the new output URL to its video element, register a listener for the media element's playing event:

function observeFirstPlayback(video, ledger) {
  const onPlaying = () => ledger.mark("playing");
  video.addEventListener("playing", onPlaying, { once: true });
  return () => video.removeEventListener("playing", onPlaying);
}

Use this with an element dedicated to that output. Call the returned cleanup function when abandoning the run or replacing the element. Otherwise, a listener from an old run could record playback of a different result.

A play button and autoplay have different implications. If the browser waits for the user to click Play, submission-to-playing includes that human delay. If autoplay is blocked, the job may still be perfectly valid even though no playing mark exists. Store the playback mode alongside the measurements and avoid mixing the two populations.

If your question is instead “when was media data available?”, choose and document a different milestone. Do not silently rename a media-loading event “visible to the user.”

Keep run outcomes and review decisions explicit

One local run should have its own identifier. A retry should receive a new run identifier and retain a reference to the overall user request. This avoids overwriting the time and outcome of the first attempt with the successful second attempt.

The application, not the sample ledger, must decide when a run is failed, cancelled, timed out locally, or complete. A local timeout means the observer stopped waiting; it does not prove that the provider stopped working. Keep that distinction in reconciliation and avoid treating it as permission to dispatch another chargeable job automatically.

Record acceptance through a separate, deliberate review action. This gives submission-to-acceptance for one run; measuring brief-to-accepted-result across retries needs a separate workflow-level starting point. An output can be playable but unusable because it changed the product, missed a requested action, or broke continuity. Conversely, “not reviewed yet” should remain unknown rather than being converted into rejection.

For a first experiment, an empty worksheet is enough:

request_id	run_id	model_version	settings	outcome	elapsed_ms	accepted
Fill from a real run	Fill from a real run	Record exact version	Record actual settings	Explicit state	Milestone map	yes / no / unknown

This table contains no measurements. Populate it from real observations before publishing performance conclusions. Avoid storing prompts, signed media URLs, or personal data unless they are necessary for the analysis and have appropriate handling.

Compare the same brief before comparing the clocks

Timing data is difficult to interpret when one run uses a shorter duration, lower resolution, or a different input image. Record those settings and keep the creative brief stable. For model-specific context, our H3 Max and Kling comparison separates documented controls and specifications from measured results.

For an initial H3 Max workflow, the first-shot tutorial provides a scoped starting point. The instrumentation above applies regardless of the selected provider; a tutorial's example settings are not a substitute for recording the settings your application actually sent.

Only after collecting enough comparable runs should you summarize distributions. Report the number of observations, the outcome breakdown, and the measurement definition next to a median or percentile. If you report successful runs separately, label that selection clearly and show how many attempts failed or remain unresolved.