Fetch, Streams, and AbortController

Three WHATWG standards — Fetch, Streams, and DOM §3.3 AbortController — were designed together. response.body is a ReadableStream by spec, not by accident; pipeTo accepts an AbortSignal; and a single signal can tear down the network socket, the response stream, and any downstream transform. Treating them as one system unlocks patterns — incremental parsing, NDJSON tailing, cancel-on-navigation — that take pages of boilerplate with XMLHttpRequest. This article unpacks the integration points, the non-obvious rules (body disturbance, single-reader locks, backpressure semantics, half-duplex uploads), and the browser support cliffs you actually hit in 2026.

Mental model

Three primitives, three responsibilities, one pipeline:

Three rules a senior engineer should hold in their head:

1. The body is the stream. body.json(), body.text(), and friends are convenience wrappers that drain the same ReadableStream. Once it has been read or piped, the stream is “disturbed” and clone()/json() will throw.⁴
2. Backpressure is advisory. controller.desiredSize is computed by the spec, but a misbehaved source that ignores it will happily blow memory; the runtime does not enforce throttling.⁵
3. Cancellation propagates both ways. A pipeTo cancel on the destination cancels the source; a source error aborts the destination. signal on pipeTo plus signal on fetch() is one switch for the whole pipeline.⁶

The Fetch API: request and response lifecycle

The Fetch Standard unifies network requests across the platform — <img> loading, navigation, Service Worker interception, and explicit fetch() calls all funnel through the same algorithm.⁷ That uniformity is the reason Fetch options that look ergonomic (e.g., cache: 'no-store') actually shape the browser’s HTTP cache decisions, not just JavaScript behavior.

Request configuration

Defaults for the options that bite most often in production:

Body source types. A request body may be a string, ArrayBuffer, typed array / DataView, Blob, File, URLSearchParams, FormData, or a ReadableStream.¹¹ The browser sets Content-Type automatically (application/x-www-form-urlencoded for URLSearchParams, multipart/form-data with a generated boundary for FormData, the Blob’s own type for blobs).

1const response = await fetch(`${API_BASE}/users`, {2  method: "POST",3  headers: { "Content-Type": "application/json" },4  body: JSON.stringify({ name: "Alice", role: "admin" }),5  credentials: "include", // send cookies cross-origin6  signal: AbortSignal.timeout(5000),7})89if (!response.ok) {10  throw new Error(`HTTP ${response.status}: ${response.statusText}`)11}12const user = await response.json()

Response tainting and CORS

The Response.type property surfaces the security context applied by the browser:

The opaque response is, per spec, “indistinguishable from a network error” to JavaScript — by design, so no-cors cannot leak data through side channels.⁸

Body consumption: stream under the hood

In the spec, a body is a (stream, source, length) triple where stream is always a ReadableStream.⁴ Every consumption helper — json(), text(), blob(), arrayBuffer(), formData() — drains that stream to completion. Once drained, the body is disturbed and cannot be read again:

1const response = await fetch("/api/data")2const data1 = await response.json()3const data2 = await response.json() // TypeError: body has already been used

response.clone() is the spec’s escape hatch: it teases the underlying stream into two independent branches via ReadableStream.tee() and returns a new Response over the second branch.¹² The cost is real: tee buffers the chunk queue for the slower branch. In browsers the queue grows as fast as the faster consumer reads, so a parked clone can hold the whole body in memory.¹³

HTTP errors do not reject

A spec corner that costs juniors at least one outage: fetch() only rejects on network failure (DNS, TCP, TLS, CORS, abort).¹⁴ HTTP 4xx/5xx are valid responses — the server replied — so the promise resolves and response.ok is false.

1const response = await fetch("/api/data")2if (!response.ok) {3  // 4xx/5xx land here, not in the catch block4  throw new HTTPError(response.status, response.statusText)5}6const data = await response.json()

The Streams API: incremental data with backpressure

ReadableStream is the bridge between source-pacing (push or pull) and consumer-pacing.

Constructor anatomy

1const stream = new ReadableStream<Uint8Array>(2  {3    start(controller) {4      // run-once setup; return a Promise to delay the first pull()5    },6    pull(controller) {7      // called whenever the queue can accept more (desiredSize > 0)8      // controller.enqueue(chunk) | controller.close() | controller.error(e)9    },10    cancel(reason) {11      // consumer aborted; release sockets, file handles, timers12    },13  },14  { highWaterMark: 3, size: (chunk) => 1 }, // queue 3 chunks before backpressure15)

Backpressure: desiredSize and pipe chains

desiredSize is defined by the spec as highWaterMark - (sum of queued chunk sizes). When zero or negative, the stream is at or over capacity; well-behaved sources stop enqueuing until pull() is called again.¹⁵ A pipeTo chain composes these signals end-to-end: WritableStream.writer.ready resolves when the sink’s queue drains, which lets the upstream TransformStream resume write() calls, which lets its upstream stream call pull() again.¹⁶

A push source that respects backpressure looks like this:

1const stream = new ReadableStream({2  start(controller) {3    let offset = 04    const produceChunk = () => {5      if (offset >= TOTAL_SIZE) {6        controller.close()7        return8      }9      // Honor backpressure: bail out and try again later10      if (controller.desiredSize !== null && controller.desiredSize <= 0) {11        setTimeout(produceChunk, 50)12        return13      }14      controller.enqueue(generateChunk(offset, CHUNK_SIZE))15      offset += CHUNK_SIZE16      queueMicrotask(produceChunk)17    }18    produceChunk()19  },20})

Reading: three patterns

1// 1. Manual reader — most control, must release the lock2const reader = stream.getReader()3try {4  while (true) {5    const { done, value } = await reader.read()6    if (done) break7    process(value)8  }9} finally {10  reader.releaseLock()11}1213// 2. Async iteration — cleanest; auto-cancels on `break` unless you opt out14for await (const chunk of stream) {15  process(chunk)16}17for await (const chunk of stream.values({ preventCancel: true })) {18  if (foundTarget) break // stream remains live for another consumer19}2021// 3. pipeTo — one call handles read, backpressure, error and cleanup22await stream.pipeTo(writableStream, { signal })

for await...of is the WHATWG-spec’d async iterator on ReadableStream and accepts { preventCancel: true } via stream.values().¹⁷ Browser support arrived late: Chrome 124, Firefox 110, Safari 26.4.¹⁸

Single-reader lock and tee()

getReader() locks the stream — calling it twice throws TypeError. The single-reader rule is what enables the runtime to optimize the queue without per-consumer buffering. When you genuinely need two consumers, call stream.tee() to get two independent branches, accepting the buffering cost for the slower branch.

WritableStream and the writer’s ready promise

WritableStream is the destination half of the pipeline. The most useful detail for production code is writer.ready: it’s a promise that resolves when the sink’s desiredSize > 0, i.e., when there is room for another write().¹⁹ Awaiting it before each write is the manual equivalent of pipeTo backpressure:

1const writer = writableStream.getWriter()2for (const chunk of chunks) {3  await writer.ready          // wait until the sink has capacity4  await writer.write(chunk)   // resolves when the chunk is accepted5}6await writer.close()

TransformStream and built-in transforms

A TransformStream is a paired (writable, readable) whose transform(chunk, controller) runs between them. The built-ins cover most of what you would otherwise hand-roll:

pipeTo and pipeThrough accept an options object that controls error and close propagation:

1await readableStream.pipeTo(writableStream, {2  preventClose: false,  // default: close the sink when the source closes3  preventAbort: false,  // default: abort the sink on source error4  preventCancel: false, // default: cancel the source on sink error5  signal,               // tear the whole pipe down on abort6})

AbortController: composable cancellation

AbortController is the single cancellation primitive across fetch, streams, timers (via AbortSignal.timeout), and your own async code. Its design is intentionally small: a controller emits one signal; the signal fires 'abort' exactly once and exposes aborted, reason, and throwIfAborted().

Static factories

AbortSignal.timeout(ms) returns a signal that auto-aborts after the given duration with a TimeoutError DOMException (distinct from the AbortError raised by manual controller.abort()).²² The timer is active time, not wall clock — it pauses while the document is in the back/forward cache or in a suspended worker, which prevents bfcache restores from firing stale timeouts.

1try {2  const response = await fetch("/api/data", { signal: AbortSignal.timeout(5000) })3  return await response.json()4} catch (err) {5  if (err.name === "TimeoutError") /* exceeded 5 s */ ;6  else if (err.name === "AbortError") /* user-initiated */ ;7  else throw err8}

AbortSignal.any([...signals]) returns a signal that aborts as soon as any of its inputs aborts, propagating that input’s reason.²³ It is the right tool for “cancel on user click or timeout”:

1const userCancel = new AbortController()2const response = await fetch("/api/data", {3  signal: AbortSignal.any([userCancel.signal, AbortSignal.timeout(10_000)]),4})5cancelButton.onclick = () => userCancel.abort()

signal.throwIfAborted() throws signal.reason if the signal already aborted — useful at the top of long-running async work to bail out before doing the expensive thing.

One-shot rule

A signal can only abort once. Reusing an already-aborted signal causes the next fetch() to reject synchronously with AbortError, which is the most common cause of “why is my retry call failing instantly”:

1const ctrl = new AbortController()2ctrl.abort()3await fetch("/a", { signal: ctrl.signal }) // rejects immediately4await fetch("/b", { signal: ctrl.signal }) // rejects immediately5// Always create a fresh controller per logical operation.

Custom abortable operations

Wire AbortSignal into your own code with addEventListener('abort', …, { once: true }) for long waits, signal.throwIfAborted() between unit-of-work iterations, or a polled signal.aborted inside tight loops:

1function delay(ms: number, signal?: AbortSignal): Promise<void> {2  return new Promise((resolve, reject) => {3    if (signal?.aborted) return reject(signal.reason)4    const timer = setTimeout(resolve, ms)5    signal?.addEventListener("abort", () => {6      clearTimeout(timer)7      reject(signal.reason)8    }, { once: true })9  })10}

Streaming downloads

Streaming with progress

The naive “loaded / Content-Length” progress UI has a sharp edge:

1type ProgressCallback = (loaded: number, total: number | null) => void23async function downloadWithProgress(4  url: string,5  onProgress: ProgressCallback,6  signal?: AbortSignal,7): Promise<Uint8Array> {8  const response = await fetch(url, { signal })9  if (!response.ok) throw new Error(`HTTP ${response.status}`)1011  const total = response.headers.get("Content-Length")12  const totalBytes = total ? parseInt(total, 10) : null1314  const reader = response.body!.getReader()15  const chunks: Uint8Array[] = []16  let loaded = 01718  while (true) {19    const { done, value } = await reader.read()20    if (done) break21    chunks.push(value)22    loaded += value.length23    onProgress(loaded, totalBytes)24  }2526  const result = new Uint8Array(loaded)27  let offset = 028  for (const chunk of chunks) { result.set(chunk, offset); offset += chunk.length }29  return result30}

Line-delimited and NDJSON streaming

For NDJSON or any newline-framed protocol — distinct from SSE, which has its own grammar and framing rules covered below — pipe response.body through TextDecoderStream and split on \n. The decoder buffers partial UTF-8 sequences across chunk boundaries, but you must still buffer the trailing partial line yourself:

1async function* streamNDJSON<T>(response: Response): AsyncGenerator<T> {2  const reader = response.body!3    .pipeThrough(new TextDecoderStream())4    .getReader()5  let buffer = ""6  while (true) {7    const { done, value } = await reader.read()8    if (done) {9      if (buffer.trim()) yield JSON.parse(buffer) as T10      return11    }12    buffer += value13    const lines = buffer.split("\n")14    buffer = lines.pop()! // keep incomplete trailing line15    for (const line of lines) {16      if (line.trim()) yield JSON.parse(line) as T17    }18  }19}2021for await (const record of streamNDJSON<UserRecord>(response)) {22  await processUser(record)23}

Range requests and resumable downloads

Range: bytes=N- is the spec-defined way to resume a broken download or grab a slice of a large object.²⁵ Servers advertise support with Accept-Ranges: bytes; a successful partial returns 206 Partial Content with Content-Range: bytes N-M/Total. Three failure modes worth wiring into your retry path:

• 200 OK — the server ignored the Range header. Discard whatever you already have and start over.
• 416 Range Not Satisfiable — the offset is past the end of the resource. Refetch metadata; the resource may have shrunk.
• If-Range mismatch — pair the Range request with If-Range: <ETag> (or Last-Modified). If the validator no longer matches, the server returns the full 200 instead of a stale partial, and the client knows to restart.²⁶

1async function resumableFetch(url: string, etag: string, offset: number, signal?: AbortSignal) {2  const response = await fetch(url, {3    signal,4    headers: {5      Range: `bytes=${offset}-`,6      "If-Range": etag, // server returns full 200 if the resource changed7    },8  })9  if (response.status === 200) return { mode: "restart", body: response.body! }10  if (response.status === 206) return { mode: "resume", body: response.body! }11  if (response.status === 416) throw new Error("Stored offset past EOF")12  throw new Error(`Unexpected ${response.status}`)13}

The Range header also enables parallel chunked downloads (request 0-N, N+1-2N, … in parallel) and on-demand seeks for HLS / DASH players, where the player asks for a few seconds of media at a time rather than the whole file.

Background Fetch (Chromium-only escape hatch)

The Background Fetch API lets a Service Worker hand a long download (AI model weights, podcast episode, large dataset) to the user agent so it survives tab close and connectivity blips:²⁷

1const reg = await navigator.serviceWorker.ready2const bgFetch = await reg.backgroundFetch.fetch(3  "ai-model-2026-04",4  ["/models/llama-7b.bin"],5  { title: "Downloading model", downloadTotal: 4_200_000_000 },6)

It is a WICG draft, not a W3C Recommendation, and ships in Chromium only as of 2026-04 (Chrome 74+, Edge 79+); Firefox and Safari have not implemented it. Use it as an opportunistic upgrade — fall back to plain fetch() when 'backgroundFetch' in registration is false.

Server-sent events vs streaming fetch

Server-Sent Events (EventSource) and streaming fetch() solve overlapping problems with very different ergonomics. Both ride on a single long-lived HTTP response; only one of them gives you reconnection for free.

SSE wire format

The HTML Living Standard defines text/event-stream as a UTF-8 line-oriented format with five legal field names: event, data, id, retry, plus comments starting with :.²⁸ An empty line dispatches the accumulated event:

1retry: 500023id: 424event: tick5data: {"ts": 1714579200, "load": 0.42}67: keepalive

Reconnection semantics

EventSource is the only browser API with built-in reconnect. The processing model:

1. On any disconnect that is not a fatal error (non-200 status, wrong Content-Type, connection.close()), the user agent waits for the current reconnection time and re-opens the request.²⁹
2. The retry: <ms> field updates that reconnection time for the lifetime of the EventSource. The default is user-agent defined — Chromium and Firefox ship 3000 ms — and the spec leaves room for exponential backoff.
3. If any received event has an id: field, the user agent stores it as the last event ID. On every reconnection attempt, that value is sent back as the Last-Event-ID request header so the server can resume from the right offset.³⁰
4. An empty id: resets the stored value; subsequent reconnects omit Last-Event-ID.

1const es = new EventSource("/api/ticks", { withCredentials: true })2es.addEventListener("tick", (e) => render(JSON.parse(e.data)))3es.onerror = () => {4  // The browser will already reconnect; only intervene to give up.5  if (es.readyState === EventSource.CLOSED) showOfflineBanner()6}

Decision matrix

Service Worker stream relay

A Service Worker’s FetchEvent.respondWith() can resolve to a Response whose body is any ReadableStream you assemble — including one composed from a TransformStream written to from multiple sources. This is how App Shell + dynamic content stitching achieves first-byte latency near the cache and rest-of-document latency near the network.³²

1self.addEventListener("fetch", (event) => {2  const url = new URL(event.request.url)3  if (url.pathname !== "/article") return45  const { readable, writable } = new TransformStream()6  event.respondWith(new Response(readable, {7    headers: { "Content-Type": "text/html; charset=utf-8" },8  }))910  event.waitUntil((async () => {11    const cache = await caches.open("shell-v1")12    const shell = await cache.match("/shell.html")13    if (shell?.body) {14      await shell.body.pipeTo(writable, { preventClose: true })15    }16    const body = await fetch(`/api/articles${url.search}`)17    if (body.body) await body.body.pipeTo(writable) // closes writable on completion18  })())19})

Operational gotchas a senior engineer should hold:

• Lifetime. A Service Worker can be terminated when idle. event.waitUntil(...) keeps it alive only as long as the controlled client is open and the worker has time budget; very long-running streams (multi-GB downloads) are precisely what BackgroundFetch is for.³³
• Bytes only. A Response body coming from a ReadableStream must enqueue Uint8Array chunks. Strings need TextEncoder/TextEncoderStream first.
• Stream identity is not transferred. When a ReadableStream crosses from a Service Worker to a controlled page via respondWith, the runtime relays chunks — both sides get distinct stream objects, not the same instance.

Request metadata: Sec-Fetch-* and priority hints

Two newer Fetch ecosystem features change how your requests are labelled on the wire — one for security, one for performance.

Fetch Metadata headers (Sec-Fetch-*)

The W3C Fetch Metadata Request Headers spec asks the user agent to attach four forbidden request headers describing why a request was made. They are forbidden — JS cannot set or override them — which is exactly what makes them useful as a server-side trust signal:³⁴

A “Resource Isolation Policy” pattern reduces a wide class of CSRF / XS-Leaks to a few lines:

1function isAllowed(req: Request): boolean {2  const site = req.headers.get("Sec-Fetch-Site") ?? "none"3  const mode = req.headers.get("Sec-Fetch-Mode") ?? "navigate"4  const dest = req.headers.get("Sec-Fetch-Dest") ?? "document"5  if (site === "same-origin" || site === "none") return true   // own pages, bookmarks, address bar6  if (mode === "navigate" && req.method === "GET" && dest === "document") return true7  return false                                                  // reject cross-site image/script/etc.8}

Always include the three discriminating headers in the response Vary so caches do not collapse a permitted same-origin response into a cached cross-origin one.

Priority Hints (fetchpriority and RequestInit.priority)

The Priority Hints spec (now folded into the Fetch Standard and HTML Standard as fetchpriority) lets you nudge the browser’s internal request-priority queue with three values: 'high', 'low', 'auto'. The hint is advisory — browsers reserve the right to override based on resource type and network conditions.³⁵

1<img src="/hero.jpg" fetchpriority="high" alt="…" />

1fetch("/api/critical", { priority: "high" })   // boost a critical XHR above siblings2fetch("/api/analytics", { priority: "low" })   // deprioritise so it never competes with LCP

Two patterns that pay off:

• Boost the LCP image / API call that paints above the fold. Browsers default <img> to “low” until layout proves visibility — fetchpriority="high" lets you skip that round trip.
• Deprioritise telemetry, prefetch warming, and cache hydration. Reserve scarce bandwidth for the requests that block paint and interactivity.

Browser support reached cross-engine interop in 2024 (Baseline 2024); use it freely in 2026.

Streaming uploads

Browsers gained ReadableStream request bodies, but the path is narrower than most articles suggest.

1async function uploadStream(2  url: string,3  source: AsyncGenerator<Uint8Array>,4  signal?: AbortSignal,5): Promise<Response> {6  const body = new ReadableStream({7    async pull(controller) {8      const { done, value } = await source.next()9      if (done) controller.close()10      else controller.enqueue(value)11    },12  })13  return fetch(url, {14    method: "POST",15    body,16    duplex: "half", // mandatory when body is a ReadableStream17    signal,18  })19}

Operational constraints to internalise before designing around it:

• HTTP/2 or HTTP/3 required. HTTP/1.1 needs Content-Length or chunked encoding up front; streaming bodies provide neither, so the browser will not negotiate it.³⁷
• Half-duplex only. duplex: 'half' means the response is held until the request finishes — there is no bidirectional streaming via fetch() in browsers. WebTransport/WebSocket are the bidirectional escape hatches.³⁷
• CORS preflight always. Streaming requests are never “simple”, so every cross-origin call costs a round trip.
• 303 is the only redirect honored. Non-303 redirects on a streaming body are rejected, because the body cannot be replayed to the new URL.³⁷
• Server buffering negates the win. Many origins and proxies buffer the full request before invoking the handler — measure end-to-end before building a UX around streaming uploads.

For the long tail (Firefox, Safari, older Chromium), XMLHttpRequest remains the only way to stream uploads with progress events.

1function uploadWithProgress(2  url: string,3  formData: FormData,4  onProgress: (loaded: number, total: number) => void,5  signal?: AbortSignal,6): Promise<Response> {7  return new Promise((resolve, reject) => {8    const xhr = new XMLHttpRequest()9    xhr.upload.addEventListener("progress", (e) => {10      if (e.lengthComputable) onProgress(e.loaded, e.total)11    })12    xhr.addEventListener("load", () =>13      resolve(new Response(xhr.response, { status: xhr.status })))14    xhr.addEventListener("error", () => reject(new Error("Upload failed")))15    signal?.addEventListener("abort", () => {16      xhr.abort()17      reject(signal.reason)18    })19    xhr.open("POST", url)20    xhr.send(formData)21  })22}

BYOB readers: zero-copy byte streams

A “Bring Your Own Buffer” reader fills a caller-provided ArrayBuffer instead of allocating a new one per chunk. It is only available on streams whose underlying source declares type: 'bytes' (a ReadableByteStreamController), or via autoAllocateChunkSize on the same source.³⁸

1async function readWithBYOB(stream: ReadableStream<Uint8Array>): Promise<Uint8Array[]> {2  const reader = stream.getReader({ mode: "byob" })3  const chunks: Uint8Array[] = []4  let buffer = new Uint8Array(64 * 1024)5  while (true) {6    const { done, value } = await reader.read(buffer)7    if (done) break8    // value is a view into the now-detached buffer; copy what was filled9    chunks.push(value.slice())10    // The original buffer's ArrayBuffer was transferred; rebuild a view.11    buffer = new Uint8Array(value.buffer)12  }13  return chunks14}

When BYOB pays off:

• Long-running binary processing (media demuxing, archive extraction) where allocation pressure dominates.
• WebAssembly interop, where you pre-allocate memory inside the Wasm heap.
• Anything where you measured GC pressure from per-chunk Uint8Array allocations.

For everyday use, the default reader is simpler, faster to write, and within a few percent of BYOB throughput.

Error handling

Three error sources, three strategies. Combine them in one wrapper:

1class HTTPError extends Error {2  constructor(public status: number, public statusText: string) {3    super(`HTTP ${status}: ${statusText}`)4    this.name = "HTTPError"5  }6}7class NetworkError extends Error { name = "NetworkError" as const }89async function robustFetch<T>(url: string, options: RequestInit = {}): Promise<T> {10  const { signal: userSignal, ...rest } = options11  const timeoutSignal = AbortSignal.timeout(30_000)12  const signal = userSignal13    ? AbortSignal.any([userSignal, timeoutSignal])14    : timeoutSignal1516  let response: Response17  try {18    response = await fetch(url, { ...rest, signal })19  } catch (e) {20    if (e instanceof Error && e.name === "TimeoutError") {21      throw new NetworkError("Request timed out after 30 s")22    }23    if (e instanceof Error && e.name === "AbortError") throw e24    throw new NetworkError(`Network failure: ${e}`)25  }2627  if (!response.ok) throw new HTTPError(response.status, response.statusText)28  const contentType = response.headers.get("Content-Type")29  if (!contentType?.includes("application/json")) {30    throw new Error(`Expected JSON, got ${contentType}`)31  }32  return (await response.json()) as T33}

For partial downloads, Range: bytes=N- lets you resume after a network blip — but only if the server returns 206 Partial Content. Anything else (200, 416) means fall back to a full retry.

Browser support, verified

All version numbers below are from caniuse and MDN browser-compat-data as of 2026-04-21. Where the article previously reported earlier versions, those were copied from older support tables that conflated “feature exists” with “feature behaves to spec”.

Feature detection

1const supportsUploadStreaming = (() => {2  let duplexAccessed = false3  try {4    new Request("data:,", {5      method: "POST",6      body: new ReadableStream(),7      get duplex() { duplexAccessed = true; return "half" },8    })9  } catch { return false }10  return duplexAccessed11})()1213const supportsSignalAny = typeof AbortSignal.any === "function"14const supportsSignalTimeout = typeof AbortSignal.timeout === "function"15const supportsAsyncIteration =16  typeof (ReadableStream.prototype as any)[Symbol.asyncIterator] === "function"

Practical takeaways

• Treat response.body as the default way to consume large payloads; reach for .json()/.text() only when the response fits comfortably in memory.
• Always pass an AbortSignal from your call site, even if it’s just AbortSignal.timeout(...). Untimed fetch() calls are how tabs leak.
• Compose with AbortSignal.any([userSignal, AbortSignal.timeout(ms)]) — one signal, two reasons to cancel, native cleanup.
• Honour controller.desiredSize in custom sources. The runtime will not save you.
• Avoid response.clone() on large bodies. If you need two consumers, design the second one to operate on parsed data.
• Don’t ship “loaded / Content-Length” progress UI on compressed endpoints; either disable encoding or stop showing a percentage.
• Streaming uploads are still a Chromium-only optimisation in 2026. Plan the fallback path before you build the happy path.
• Reach for EventSource when reconnect-with-Last-Event-ID is the spec you would otherwise re-implement; reach for streaming fetch() when you need POST, custom headers, or non-text framing.
• For App Shell + dynamic body, compose a TransformStream inside FetchEvent.respondWith — it is the fastest way to ship cached HTML before the network responds.
• Trust Sec-Fetch-Site / Sec-Fetch-Mode server-side as a cheap, unforgeable defense-in-depth check, and remember to add them to Vary.
• Use fetchpriority="high" (or priority: 'high') on the LCP-critical request and 'low' on telemetry / prefetch — most apps mis-prioritize at least one of the two.

Appendix

Terminology

• Backpressure — flow-control mechanism where consumer pacing throttles producer output via desiredSize.
• Body source — the spec name for the original data backing a body (a byte sequence, Blob, FormData, etc.) before it becomes a stream.
• BYOB (Bring Your Own Buffer) — a reader mode that fills a caller-allocated ArrayBuffer instead of allocating per-chunk; only available on byte streams.
• Disturbed — a body whose stream has had read() called on it; cannot be re-read or cloned.
• Half-duplex — request must finish before the response can be read; full-duplex would allow interleaved reads and writes (browsers do not).
• High water mark — the queue-size threshold at which a stream signals backpressure (desiredSize <= 0).
• Locked — the state of a stream while a reader holds it; only one reader can be active at a time.
• Opaque response — cross-origin response with mode: 'no-cors'; status 0, headers empty, body null. Indistinguishable from a network error.
• Tee — duplicating a stream into two independent branches; the slower branch causes the queue to grow.

References

Specifications

• Fetch Standard — WHATWG Living Standard (Request, Response, body, CORS, response tainting)
• Streams Standard — WHATWG Living Standard (ReadableStream, WritableStream, TransformStream, pipe chains, backpressure)
• Encoding Standard — TextEncoderStream, TextDecoderStream
• DOM Standard §3.3 Aborting ongoing activities — AbortController, AbortSignal
• HTML Standard §9.2 Server-sent events — EventSource, text/event-stream, reconnection
• Service Workers — W3C — FetchEvent.respondWith, ExtendableEvent.waitUntil
• Background Fetch — WICG — BackgroundFetchManager
• Fetch Metadata Request Headers — W3C — Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, Sec-Fetch-User
• RFC 9110 — HTTP Semantics — Range requests, conditional requests, response status codes
• Compression Streams — CompressionStream/DecompressionStream

Official documentation and engineering posts

• Using the Fetch API — MDN
• ReadableStream — MDN
• Using readable byte streams — MDN
• AbortSignal.timeout() — MDN
• AbortSignal.any() — MDN
• Streaming requests with the fetch API — Chrome for Developers
• Streams — the definitive guide — web.dev
• We deserve a better streams API — Cloudflare
• Fetch streams are great, but not for measuring upload/download progress — Jake Archibald, 2025