Wait for all promises to resolve in JavaScript

Two sequential awaits wait for the first operation before the second even starts:

const values = await store.getAll()
const keys = await store.getAllKeys()

When the work is independent, start both and wait together:

const [values, keys] = await Promise.all([
  store.getAll(),
  store.getAllKeys()
])

Results stay in input order, not completion order. Total wait time is roughly the slowest call, not the sum.

Promise.all() rejects as soon as one input rejects. The others keep running unless you cancel them with AbortController where the API supports it.

Use sequential awaits when step two needs step one’s result, when order matters, or when firing everything at once would overload a service. For long lists, limit concurrency instead of spawning thousands of requests.

When you need every outcome even if some fail, use Promise.allSettled() and read each { status, value } or { status, reason } entry.

Wrap the group when you want one error path for the UI:

try {
  const [profile, orders] = await Promise.all([getProfile(), getOrders()])
  renderAccount(profile, orders)
} catch (error) {
  showError('The account could not be loaded')
}

Compare sequential and concurrent timing with two setTimeout promises that resolve after 500 ms and 1000 ms. Concurrent Promise.all() should finish near one second, not one and a half.

See the promise combinators tool for side-by-side behavior.

When one branch fails, log which operation rejected before you show a generic error in the UI.

When one branch fails, log which operation rejected before you show a generic error in the UI.

If you only need the first success among several slow requests, Promise.any() fits better than Promise.all().

Measure both patterns in DevTools Network when the calls hit real endpoints. The waterfall makes the time savings obvious.

Compare sequential and concurrent timing with two delayed promises. Concurrent Promise.all() should finish near the slowest single call, not the sum of both.