5 async/await Mistakes That Slow Your JavaScript Code

1. 1

   Sequential Awaits When Tasks Are Independent

   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.

   javascriptCopy

   // ❌ 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),
   ]);

   • 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.
2. 2

   await Inside forEach

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

   javascriptCopy

   // ❌ 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);
   }

   • 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.
3. 3

   Promise.all Without Handling Partial Failures

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

   javascriptCopy

   // ❌ 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 : [];

   • 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.
4. 4

   The Silent Missing await

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

   javascriptCopy

   // ❌ 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);
   }

   • 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.

   Enable the ESLint rule that catches this automatically:

   javascript — eslint.config.mjsCopy

   import tseslint from 'typescript-eslint';
   
   export default tseslint.config({
     rules: {
       '@typescript-eslint/no-floating-promises': 'error',
     },
   });

5. 5

   Awaiting a map That Returns Promises

   When you use async inside a map callback, map returns an array of Promises, not resolved values. Awaiting the array itself resolves immediately, since it's not a Promise. Related to Mistake 2 (forEach) but with a different cause.

   javascriptCopy

   // ❌ 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

   • 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))).
6. 6

   When Sequential Is the Right Choice

   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.

   javascriptCopy

   // ✅ Sequential (fetchOrders needs userId from the user object)
   const user = await fetchUser(userId);
   const orders = await fetchOrders(user.id); // depends on user result

   javascriptCopy

   // ✅ Sequential queue (order matters, concurrent writes risk race conditions)
   for (const item of queue) {
     await processItem(item);
   }

Quick Decision Guide

// forEach (fire-and-forget, broken)
items.forEach(async (item) => await fn(item));

// for...of (sequential, correct)
for (const item of items) { await fn(item); }

// Promise.all + map (parallel, correct)
await Promise.all(items.map(item => fn(item)));