Fetch API and browser network stack: concurrent request deduplication across Chromium and Firefox

Answer – Do the requests collapse into one?

Short answer: No, the HTML5 Fetch spec does not require it. In current stable releases, Chromium‑based browsers (Chrome, Edge, Brave) collapse identical in‑flight fetches into a single network transaction, while Firefox issues separate requests for each concurrent fetch, even when the cache is empty.

Confirmed facts

• Spec: request deduplication is implementation‑defined.
• Chromium: two fetches started in the same event‑loop tick to the same URL, with identical headers, result in one network request and the same Response promise is returned to both callers.
• Firefox: the same scenario produces two distinct network requests; each Response is independent.
• When the response is cached and fresh, both browsers hit the cache and no network traffic occurs – this is separate from deduplication.
• Behavior can change between minor releases; it is not a stable guarantee.

Why it matters for applications

• Assuming a single HTTP transaction can lead to hidden duplicate traffic in Firefox, affecting bandwidth and load‑balancing.
• Security or idempotency guarantees that rely on a single request should explicitly coordinate or serialize the calls.
• Feature detection or request sequencing is the safest approach if you need consistent behavior.

How to verify in your own project

1. Open DevTools Network panel in both Chrome and Firefox.
2. Write a small script that starts two identical fetches in the same tick:

const url = 'https://example.com/data.json';
Promise.all([fetch(url), fetch(url)])
  .then(responses => Promise.all(responses.map(r => r.json())))
  .then(console.log);

3. Observe the Network tab:
   • Chrome shows a single GET /data.json request.
   • Firefox shows two separate GET /data.json requests.
4. Repeat the test with a Cache‑Control: max‑age=600 header on the server to confirm that both browsers hit the cache and no network traffic appears.
5. Optionally, add a Service Worker that logs each fetch event to see if it intercepts the requests; a Service Worker can bypass the browser’s deduplication logic.

What to do if you need consistent behavior

• Serialize the requests – start the second fetch only after the first resolves.
• Use a shared promise – store the in‑flight promise in a cache keyed by URL and headers, and reuse it.
• Implement feature detection by checking if the browser’s fetch returns the same promise object for concurrent calls (not part of the spec, but can be tested).
• Consider a Service Worker that enforces deduplication by queuing identical requests and responding with a cached or pending promise.

Diagnostic detail that could change the recommendation

If you are already using a Service Worker that intercepts these requests, the deduplication behavior may differ because the Service Worker can choose to forward or merge requests. In that case, the recommendation would shift toward controlling deduplication inside the Service Worker rather than relying on the browser’s network stack.