Performance Optimisation

Making JavaScript faster — measuring before optimising, common bottlenecks, V8 engine hints, lazy loading, and memory management.

What it is, in plain English: Performance optimisation in JavaScript starts with measurement — you can't know what to fix until you know what's slow. The three main performance concerns are: runtime speed (how fast code executes), load time (how fast the page becomes interactive), and memory (avoiding leaks). The first rule: measure first, optimise second. Premature optimisation adds complexity without guaranteed benefit.

Where this bites you

Memoising an async function caches the Promise it returns, and that includes a Promise that rejected. One network blip on the first call, and for the whole cache lifetime (10 minutes in the getWeather example) every call gets the same old failure back instantly, even though the network recovered seconds later.

function memoizeWithTTL(fn, ttlMs = 5 * 60 * 1000) {
  const cache = new Map();
  return function(...args) {
    const key = JSON.stringify(args);
    const entry = cache.get(key);
    if (entry && Date.now() - entry.time < ttlMs) return entry.value;
    const value = fn.apply(this, args);
    cache.set(key, { value, time: Date.now() });
    return value;
  };
}

let networkUp = false;                       // the first call hits a network blip
async function fetchWeatherFromAPI(city) {
  if (!networkUp) throw new Error("network error");
  return `${city}: 31°C`;
}

const getWeather = memoizeWithTTL(fetchWeatherFromAPI, 10 * 60 * 1000);
await getWeather("Pune").catch(e => console.log("call 1:", e.message));
networkUp = true;                            // the network is back...
await getWeather("Pune").catch(e => console.log("call 2:", e.message));   // ...but the cache isn't
// call 1: network error
// call 2: network error

Measure first, then fix

The first rule of performance: measure before optimising. Making guesses about what's slow is almost always wrong. Use the profiler — then fix what the data says is slow.

Measuring performance

// console.time / timeEnd — easiest way to measure a block:
console.time("data processing");
const result = processData(largeArray);
console.timeEnd("data processing");
// "data processing: 234.5ms"

// performance.now() — more precise, good for comparisons:
const start = performance.now();
doSomethingExpensive();
const elapsed = performance.now() - start;
console.log(`Took ${elapsed.toFixed(2)}ms`);

// Browser DevTools — Performance tab (the real tool):
// 1. Open DevTools → Performance tab
// 2. Click Record → do the slow thing → Stop
// 3. See a flame chart: which functions took the most time
// 4. Fix the slowest ones first (biggest blocks in the chart)

Debounce and throttle — the two most impactful optimisations

// DEBOUNCE — wait until user stops doing something
// Use for: search input, form validation, resize handlers
function debounce(fn, delay) {
  let timer;
  return function(...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

const handleSearch = debounce((query) => {
  fetch(`/api/search?q=${query}`);  // only fires 300ms after user stops typing
}, 300);

searchInput.addEventListener("input", (e) => handleSearch(e.target.value));

// THROTTLE — run at most once per interval
// Use for: scroll events, mouse moves, window resize
function throttle(fn, interval) {
  let lastTime = 0;
  return function(...args) {
    const now = Date.now();
    if (now - lastTime >= interval) {
      lastTime = now;
      fn.apply(this, args);
    }
  };
}

const handleScroll = throttle(() => updateScrollIndicator(), 100);
window.addEventListener("scroll", handleScroll);
// Max 10 updates per second, no matter how fast the user scrolls

Avoiding common slow patterns

// ✗ Slow — querying DOM inside a loop:
for (let i = 0; i < items.length; i++) {
  document.querySelector(".list").appendChild(createItem(items[i])); // reflows each time!
}

// ✓ Fast — build once, insert once:
const fragment = document.createDocumentFragment();
items.forEach(item => fragment.appendChild(createItem(item)));
document.querySelector(".list").appendChild(fragment);  // one reflow

// ✗ Slow — reading layout properties inside a write loop (layout thrashing):
elements.forEach(el => {
  const h = el.offsetHeight;   // forces layout recalculation
  el.style.height = h + 10 + "px";  // then writes
});

// ✓ Fast — read all, then write all:
const heights = elements.map(el => el.offsetHeight);  // read phase
elements.forEach((el, i) => el.style.height = heights[i] + 10 + "px");  // write phase

Try It Yourself

// MEASURE FIRST — always know where the time is going
console.time("sort benchmark");
const arr = Array.from({ length: 100000 }, () => Math.random());
arr.sort((a, b) => a - b);
console.timeEnd("sort benchmark");  // e.g. "sort benchmark: 12.4ms"

// performance.now() — sub-millisecond precision
const t0 = performance.now();
let sum = 0;
for (let i = 0; i < 1000000; i++) sum += i;
const t1 = performance.now();
console.log(`Sum loop: ${(t1 - t0).toFixed(3)}ms, result: ${sum}`);

// MEMOISATION — cache expensive results
function memoize(fn) {
  const cache = new Map();
  return function(...args) {
    const key = JSON.stringify(args);
    if (cache.has(key)) return cache.get(key);
    const result = fn.apply(this, args);
    cache.set(key, result);
    return result;
  };
}

function expensiveFibonacci(n) {
  if (n <= 1) return n;
  return expensiveFibonacci(n-1) + expensiveFibonacci(n-2);
}
const fastFib = memoize(expensiveFibonacci);

console.time("first call fib(35)");
fastFib(35);
console.timeEnd("first call fib(35)");   // slow

console.time("second call fib(35)");
fastFib(35);
console.timeEnd("second call fib(35)");  // instant — cached!

// DEBOUNCE — limit how often a function runs
function debounce(fn, delay) {
  let timer;
  return function(...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

// THROTTLE — ensure function runs at most once per interval
function throttle(fn, interval) {
  let lastTime = 0;
  return function(...args) {
    const now = Date.now();
    if (now - lastTime >= interval) {
      lastTime = now;
      return fn.apply(this, args);
    }
  };
}

const onSearch  = debounce(q => console.log("Searching:", q), 300);
const onScroll  = throttle(() => console.log("Scroll!"), 100);

// Simulate rapid calls:
["a","ab","abc","abcd"].forEach((q, i) => setTimeout(() => onSearch(q), i * 50));
// Only the last search "abcd" fires (300ms after the last call)

Memoisation, lazy loading, and Web Workers

Memoisation — cache expensive calculations

// Generic memoize:
function memoize(fn, keyFn = JSON.stringify) {
  const cache = new Map();
  return function(...args) {
    const key = keyFn(args);
    if (cache.has(key)) return cache.get(key);
    const result = fn.apply(this, args);
    cache.set(key, result);
    return result;
  };
}

// Time-bounded cache (auto-expire after 5 minutes):
function memoizeWithTTL(fn, ttlMs = 5 * 60 * 1000) {
  const cache = new Map();
  return function(...args) {
    const key = JSON.stringify(args);
    const entry = cache.get(key);
    if (entry && Date.now() - entry.time < ttlMs) return entry.value;
    const value = fn.apply(this, args);
    cache.set(key, { value, time: Date.now() });
    return value;
  };
}

const getWeather = memoizeWithTTL(fetchWeatherFromAPI, 10 * 60 * 1000); // 10 min cache

The memoizeWithTTL above has exactly this gap. When the cached value is a Promise, remove the entry if it rejects, so the next call tries again. Successful results stay cached as before:

function memoizeWithTTL(fn, ttlMs = 5 * 60 * 1000) {
  const cache = new Map();
  return function(...args) {
    const key = JSON.stringify(args);
    const entry = cache.get(key);
    if (entry && Date.now() - entry.time < ttlMs) return entry.value;
    const value = fn.apply(this, args);
    cache.set(key, { value, time: Date.now() });
    if (value instanceof Promise) {
      value.catch(() => cache.delete(key));  // never keep a failure in the cache
    }
    return value;
  };
}
// call 1: network error
// call 2: Pune: 31°C

Lazy loading — only load what you need, when you need it

// Dynamic imports — load a module only when needed:
button.addEventListener("click", async () => {
  // 'chart.js' is only downloaded when the user clicks:
  const { Chart } = await import("./chart.js");
  new Chart(canvas, data);
});

// Lazy load images (native HTML):
// <img loading="lazy" src="big-image.jpg" alt="...">

// IntersectionObserver for custom lazy loading:
const observer = new IntersectionObserver(entries => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      img.src = img.dataset.src;  // swap placeholder for real image
      observer.unobserve(img);
    }
  });
});

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

Web Workers — move heavy work off the main thread

// The main thread handles UI — blocking it freezes the page.
// Move CPU-intensive work to a Worker:

// worker.js:
// self.onmessage = ({ data }) => {
//   const result = heavyComputation(data);  // runs in separate thread
//   self.postMessage(result);
// };

// main.js:
const worker = new Worker("worker.js");
worker.postMessage(largeDataset);
worker.onmessage = ({ data }) => {
  displayResult(data);  // back on main thread for DOM update
};

// Modern approach — Comlink (wraps Workers with a clean async API):
// import { wrap } from "comlink";
// const worker = wrap(new Worker("worker.js"));
// const result = await worker.heavyComputation(data);  // feels like async function

V8 optimisation hints and bundle performance

How V8 optimises your code

// V8 uses JIT (Just-In-Time) compilation.
// It monitors "hot" code paths and compiles them to native machine code.
// To help V8 optimise well:

// 1. Keep object shapes consistent (hidden classes):
// ✓ Good — all Car objects have the same structure:
function createCar(make, model) { return { make, model, speed: 0 }; }
// ✗ Bad — different shapes prevent optimisation:
const a = { x: 1 };
const b = { x: 1, y: 2 };  // different "hidden class" — harder to optimise

// 2. Initialise all properties in the constructor (not added later):
class Point {
  constructor(x, y) {
    this.x = x;
    this.y = y;
    // Don't add this.z later — it changes the shape
  }
}

// 3. Use typed arrays for numerical data:
const positions = new Float32Array(1000);  // much faster than regular Array for numbers

// 4. Avoid deoptimisation triggers:
// - mixing types in an array: [1, "two", 3] → falls back to slow path
// - try/catch around hot code (optimiser can't inline)
// - arguments object (use rest params instead)

Bundle size — load performance

// Tree-shaking — only import what you use:
// ✓ Named import (tree-shakeable):
import { debounce } from "lodash-es";

// ✗ Default import pulls everything:
import _ from "lodash";

// Analyse your bundle:
// npx vite-bundle-visualizer    → visual treemap of what's in your bundle
// npx webpack-bundle-analyzer   → webpack equivalent

// Code splitting in Vite/webpack — automatic with dynamic imports:
// Each await import() becomes its own chunk (lazy loaded on demand)

// Target: < 200KB initial JS for good core web vitals
// Check: pagespeed.web.dev

Official Sources

The Codex links only to official documentation and the ECMAScript specification. No third-party tutorials.