Sequential vs Parallel Requests
Run the same set of requests as a waterfall and in parallel, and compare timelines and total duration.
What you'll learn
- Spot accidental awaits that serialize independent work
- Read a request timeline
Interactive laboratory
Controls
simulated network operationsThese are simulated requests - promises that settle after a delay - not real HTTP calls.
Request waterfall
bars from measured timestamps- Request A: idle
- Request B: idle
- Request C: idle
Sequential · not run
Parallel · not run
Shared scale: 0 ─ 1600 ms
- Sequential total
- -
- Parallel total
- -
- Sum A+B+C
- 1600 ms
- Max(A,B,C)
- 800 ms
Totals are measured with performance.now() around the actual awaits; nothing is predicted. Timer scheduling adds a few milliseconds of overhead.
What happened?
Run both strategies with the same durations to compare.
Parallelise independent work; preserve ordering where a dependency requires it. If B needs A's response, B cannot start early - and rate limits or connection limits can make unbounded concurrency slower, not faster.
Why it happened
An await inside a loop is the most common way to turn a fast page into a slow one.
Seeing the timeline makes the cost obvious.
Key takeaways
- Independent requests should start together
- Parallelism is bounded by connection limits, not intent
Tags
- http
- concurrency
- waterfall
- promises