~/tools / 10 / delayed-api-response
Latency Simulator
On localhost every response lands in 5ms and every spinner looks perfect. Reality ships 3G. Dial in real latency — a 3-second delay to watch your skeleton screens actually render, or an 8-second stall to prove your AbortController timeouts and retry toasts fire before users rage-refresh. The delay is honored client-side by the interceptor, no throttling proxy required.
— validating —
$ man slow-network
Everything above is encoded into the #data= fragment of the exported URL — deflated and base64url-packed by your browser. Fragments are never sent to any server, so this mock is shareable and private. Paste the URL anywhere: a teammate's browser decodes it identically.
cat ./tldr.txt
A slow API response simulator holds a response for a configurable delay — 3 seconds to see skeleton screens render, or 8 seconds to trip timeouts — so loading states, spinners, and AbortController logic can be verified without a throttling proxy.
./when-to-use-this
- Every request on localhost resolves in milliseconds, so your skeleton screens have never actually been seen.
- You need to confirm an AbortController timeout fires and shows a retry affordance rather than hanging.
- You are demonstrating to a reviewer how the interface behaves on a poor connection.
./frequently-asked
- How is this different from Chrome DevTools network throttling?
- Throttling slows every request in the tab and simulates bandwidth. This delays one specific response by an exact, repeatable number of milliseconds, which is better for asserting a particular timeout threshold or sharing a reproducible case with a teammate via URL.
- What delay should I test with?
- Three seconds is enough to confirm loading states actually render and are not a flash of empty layout. Eight seconds pushes past most sensible client timeouts, which is where you find out whether the interface shows a retry path or simply hangs. Testing both is more informative than picking one.
- Does the delay happen on the server?
- No. The delay is applied client-side by the interceptor before it renders the response, since the payload travels in the URL fragment and never reaches a server. The observable effect on your loading UI is the same, but it does not reproduce server-side connection or TLS latency.