5 async/await Mistakes That Slow Your JavaScript Code

The most expensive performance mistake in async JavaScript. When tasks don't depend on each other, awaiting them one-by-one means 3 one-second calls take 3 seconds instead of 1.

• Promise.all kicks off all three requests simultaneously and waits for all of them to finish.
• The total time equals the duration of the slowest request, not the sum of all requests.
• The rule: if Task B doesn't need Task A's result, don't await Task A first.

// ❌ Sequential — 3 requests × 1 second = 3 seconds total
const user  = await fetchUser(userId);
const posts = await fetchPosts(userId);
const stats = await fetchAnalytics(userId);

// ✅ Parallel with Promise.all — ~1 second (slowest request wins)
const [user, posts, stats] = await Promise.all([
  fetchUser(userId),
  fetchPosts(userId),
  fetchAnalytics(userId),
]);

forEach was not designed to understand Promises. When you mark its callback async, it starts each promise but doesn't wait — execution continues immediately.

• forEach calls each callback and moves on, ignoring any returned Promise.
• Use for...of with await when tasks must run in order.
• Use Promise.all + map when tasks can run in parallel.

// ❌ await inside forEach — fire-and-forget
orderIds.forEach(async (id) => {
  await processOrder(id); // not waited for
});
console.log('Done!'); // runs immediately — nothing has processed yet

// ✅ Parallel: Promise.all + map
await Promise.all(orderIds.map(id => processOrder(id)));
console.log('Done!'); // waits for all orders

// ✅ Sequential: for...of with await
for (const id of orderIds) {
  await processOrder(id);
}

Promise.all is fast but unforgiving — if one promise rejects, the entire call rejects and you lose results from every promise that succeeded.

• Use Promise.all when you need every result and a partial failure genuinely means you can't continue.
• Use Promise.allSettled when partial data is better than a full error — most dashboard UIs fall here.

// ❌ One failure kills all three results
const [user, posts, stats] = await Promise.all([
  fetchUser(userId),
  fetchPosts(userId),
  fetchAnalytics(userId), // throws 500 → you get nothing
]);

// ✅ Promise.allSettled — partial results on failure
const results = await Promise.allSettled([
  fetchUser(userId),
  fetchPosts(userId),
  fetchAnalytics(userId),
]);
const user  = results[0].status === 'fulfilled' ? results[0].value : null;
const posts = results[1].status === 'fulfilled' ? results[1].value : [];

The most dangerous mistake: forgetting await on an async function produces no error. The operation runs fire-and-forget and execution continues immediately.

• If validatePost throws, the rejection is silently swallowed and savePost runs anyway.
• Tests often miss this because they only check the happy path — the bug surfaces in production.
• TypeScript with @typescript-eslint/no-floating-promises catches missing await calls statically.

// ❌ Missing await — validation runs but isn't waited for
async function createPost(data) {
  validatePost(data);          // fires and is forgotten
  return await savePost(data); // runs before validation finishes
}

// ✅ With await — validation must complete before saving
async function createPost(data) {
  await validatePost(data);
  return await savePost(data);
}

When you use async inside a map callback, map returns an array of Promises, not resolved values. Awaiting the array itself resolves immediately — it's not a Promise.

• map returns a new array synchronously — it does not wait for async callbacks.
• The outer await resolves the array synchronously (arrays are not Promises).
• The fix is always await Promise.all(items.map(async item => fn(item))).

// ❌ await on the array — resolves immediately with [Promise, Promise, Promise]
const results = await items.map(async (item) => fetchData(item));
// results is [Promise {}, Promise {}, Promise {}], not actual values

// ✅ Wrap with Promise.all — resolves all promises in the array
const results = await Promise.all(
  items.map(async (item) => fetchData(item))
);
// results is now the actual fetched values

Not every situation calls for parallel execution. Sequential await is the correct choice in specific scenarios:

• Task B depends on Task A's result — fetch a user, then fetch their orders using the user ID.
• You are writing to a database where concurrent writes on the same record create race conditions.
• You are processing a queue where order matters and each item must complete before the next begins.

Pick the right async pattern by asking whether each task depends on the previous result:

• Independent tasks, need all results: await Promise.all([task1(), task2(), task3()])
• Independent tasks, partial failures acceptable: await Promise.allSettled([task1(), task2()])
• Sequence where each result feeds the next: sequential await or for...of with await
• Array of items processed in parallel: await Promise.all(items.map(async item => fn(item)))
• Array of items processed one at a time: for (const item of items) { await fn(item); }