v139 · network / connectivity

Fetch retry (for keepalive fetches)

Allow web developers to indicate that a fetch() request should be retried, to have a greater guarantee on it being reliably sent, even if network is flaky. This is especially important for keepalive fetches, where the request might outlive the document, which can no longer watch for its failure and do manual retry.

concepts

  1. Retry Options

    Keepalive fetches (used for unload-time logging) now support a retry policy. If the request fails, the browser retries it with the same body — useful for shaky-network sessions.

  2. Beacon Survival Simulator

    Dial a fake failure rate and a retry budget. Toggle the v139 retry policy on and off and watch how many analytics beacons reach the server vs how many vanish on the unload path.

  3. Retry Policy Builder

    Tune maxAttempts, initialDelay, backoffFactor, and maxAge. Simulate 100 beacons and see the success-by-attempt histogram, average delivery time, and how many drop past maxAge.

  4. Beacon Delivery A/B Comparison

    Side-by-side: sendBeacon (no retry) vs fetch keepalive + retry. A failure rate slider (0–80%) drives 20 simulated beacons. Each beacon card shows per-attempt dots; running totals track delivered vs lost counts in real time.

why it shipped

fetch() requests can fail due to transient network errors. Manual JavaScript retries are complex and impossible to be done after page unload (e.g. for keepalive fetches), causing data loss for critical/high-value beacons.

references