JavaScript Performance Tricks That Actually Move the Needle

Storytime: I once inherited a codebase where a "simple" list render was taking over 800ms. The culprit? A loop that was touching the DOM 200 times instead of once. One refactor, four lines changed, and it dropped to 12ms. I've been a little obsessed with JS performance ever since.

The good news: you don't need to understand V8 internals to write fast JavaScript. A handful of patterns cover 90% of the gains you'll ever need. Let's dig in.

Stop Touching the DOM So Much

Every time you modify the DOM, the browser recalculates styles, reruns layout, and repaints. Do it in a loop and you're triggering that whole pipeline on every iteration.

The fix: batch your changes off-screen first, then commit once.

// ❌ Triggers a reflow for every single item
const container = document.getElementById('user-list');
users.forEach(user => {
  const li = document.createElement('li');
  li.textContent = user.name;
  container.appendChild(li); // reflow, reflow, reflow...
});

// ✅ One reflow, no matter how many items
const fragment = document.createDocumentFragment();
users.forEach(user => {
  const li = document.createElement('li');
  li.textContent = user.name;
  fragment.appendChild(li);
});
container.appendChild(fragment); // single reflow here

Same idea applies to style changes. Instead of setting individual properties — which each trigger their own recalculation — swap a CSS class instead:

// ❌ Multiple style changes = multiple reflows
element.style.width = '200px';
element.style.height = '200px';
element.style.backgroundColor = 'blue';

// ✅ One class change = one reflow
element.classList.add('highlighted-box');

Your CSS already lives in a stylesheet. Let the browser do its job.

Write Loops That Know When to Stop

Loops are where I see the most avoidable waste. The classic example: iterating an entire array looking for one item, even after you've found it.

// ❌ Checks all 10,000 users even after finding the one you want
let target;
users.forEach(user => {
  if (user.id === 42) target = user;
});

// ✅ Stops the moment it finds a match
const target = users.find(user => user.id === 42);

find(), some(), and findIndex() all short-circuit — they stop iterating the moment the condition is met. Reach for them before writing a manual loop.

For hot loops over large datasets, cache the array length:

const len = items.length;
for (let i = 0; i < len; i++) {
  // avoids re-evaluating items.length on every iteration
}

Micro-optimization? Maybe. But in tight loops processing thousands of items, it adds up.

Parallel Async Operations with Promise.all

This one is genuinely underused. If you have multiple independent async operations, await-ing them sequentially is leaving performance on the table.

// ❌ Sequential — 6 seconds total
async function loadPage() {
  const users    = await fetchUsers();    // 2s
  const posts    = await fetchPosts();    // 2s
  const comments = await fetchComments(); // 2s
}

// ✅ Parallel — 2 seconds total
async function loadPage() {
  const [users, posts, comments] = await Promise.all([
    fetchUsers(),
    fetchPosts(),
    fetchComments()
  ]);
}

The rule is simple: if the requests don't depend on each other's results, run them together. I personally check for this pattern in every code review — it's one of the easiest wins available.

Lazy Load What You Don't Need Yet

Don't pay the cost of loading something until the user actually needs it. The Intersection Observer API makes this trivial for images:

const observer = new IntersectionObserver(entries => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      img.src = img.dataset.src;
      observer.unobserve(img);
    }
  });
});

document.querySelectorAll('img[data-src]').forEach(img => {
  observer.observe(img);
});

Mark your images with data-src instead of src, and they only load as they scroll into view. For image-heavy pages, this alone can dramatically improve initial load time.

The same principle applies to JavaScript modules. If a feature is only used sometimes, import it dynamically instead of bundling it upfront:

button.addEventListener('click', async () => {
  const { heavyFeature } = await import('./heavyFeature.js');
  heavyFeature.init();
});

Measure First, Optimize Second

Here's the thing I wish someone had told me earlier: don't guess at bottlenecks. Measure them.

const start = performance.now();
doExpensiveThing();
console.log(`Took ${performance.now() - start}ms`);

Or use console.time for quick checks:

console.time('render');
renderList();
console.timeEnd('render'); // "render: 23.4ms"

Open DevTools, run a Performance trace, and let the flame graph show you where time is actually going. Nine times out of ten it's not where you expected.

The Short List

When something feels slow, work through this in order:

• Batch DOM changes with document fragments
• Swap CSS classes instead of inline styles
• Use find() / some() instead of forEach when you need early exit
• Run independent async calls with Promise.all
• Lazy load images and heavy modules
• Measure before and after — every time

Performance work is satisfying precisely because the feedback is immediate. Slow → fast, measured before and after. Go find your 800ms and make it 12. 🎉