JavaScript Performance Interview Questions

The rendering pipeline — what JavaScript blocks

The browser renders frames. Each frame has a budget (16.7ms at 60fps). JavaScript runs on the same thread as rendering. Long tasks block the rendering pipeline.

// ❌ Long synchronous task — blocks rendering, freezes input
function processLargeDataset(items) {
  return items.map(item => expensiveTransform(item))  // might take 500ms
}

// ✓ Chunked with setTimeout — yields to the event loop between chunks
function processInChunks(items, chunkSize = 100) {
  return new Promise(resolve => {
    const results = []
    let i = 0

    function processChunk() {
      const end = Math.min(i + chunkSize, items.length)
      while (i < end) {
        results.push(expensiveTransform(items[i++]))
      }
      if (i < items.length) {
        setTimeout(processChunk, 0)  // yield — let browser paint/respond
      } else {
        resolve(results)
      }
    }
    processChunk()
  })
}

// ✓ Web Worker — run on a separate thread, never blocks main thread
const worker = new Worker('./processor.worker.js')
worker.postMessage(items)
worker.onmessage = (e) => displayResults(e.data)

requestAnimationFrame — animation timing

// ❌ setTimeout for animation — not tied to display refresh, causes jank
function animateBad() {
  element.style.transform = `translateX(${x++}px)`
  setTimeout(animateBad, 16)  // might fire between frames, causes visual stuttering
}

// ✓ requestAnimationFrame — synced to display refresh, cancellable
let frameId
function animateGood(timestamp) {
  element.style.transform = `translateX(${x++}px)`
  frameId = requestAnimationFrame(animateGood)
}
frameId = requestAnimationFrame(animateGood)

// Cancel:
cancelAnimationFrame(frameId)

// Throttle any callback to 60fps:
function throttleToFrame(fn) {
  let scheduled = false
  return function(...args) {
    if (!scheduled) {
      scheduled = true
      requestAnimationFrame(() => {
        fn.apply(this, args)
        scheduled = false
      })
    }
  }
}

DOM performance — reads, writes, and layout thrashing

// ❌ Layout thrashing — alternating reads and writes forces reflow each time
for (const el of elements) {
  const height = el.offsetHeight     // READ — forces layout calculation
  el.style.height = height * 2 + 'px'  // WRITE — invalidates layout
  // Next READ in loop forces recalculation — browser recalculates EVERY iteration
}

// ✓ Batch reads then writes — browser only recalculates once
const heights = elements.map(el => el.offsetHeight)  // all reads first
elements.forEach((el, i) => {                         // then all writes
  el.style.height = heights[i] * 2 + 'px'
})

// Properties that trigger layout (reflow):
// offsetWidth/Height, scrollTop, getBoundingClientRect(),
// clientWidth/Height, getComputedStyle()

// Properties safe to write without triggering layout:
// CSS transform, opacity — handled by compositor thread, not main thread
// el.style.transform = 'translateX(100px)' — GPU-composited, no layout
// el.style.opacity = '0.5'                 — GPU-composited, no layout

Memory management — avoiding leaks

// ❌ Classic memory leak — event listener never removed
function setupButton() {
  const data = fetchLargeDataset()  // 10MB in closure
  button.addEventListener('click', () => {
    process(data)  // data is kept alive as long as this listener exists
  })
  // If setup is called multiple times, listeners accumulate
}

// ✓ Remove listeners when done
function setup() {
  const handler = () => process(data)
  button.addEventListener('click', handler)
  return () => button.removeEventListener('click', handler)  // cleanup
}

// ❌ Timer leak — interval never cleared
function startPolling() {
  setInterval(() => fetchData(), 5000)
  // Even if the component that called this is destroyed, interval keeps running
}

// ✓ Always keep a reference and clear it
function startPolling() {
  const id = setInterval(() => fetchData(), 5000)
  return () => clearInterval(id)  // return cleanup function
}

// ❌ Detached DOM node with event listeners
let element = document.createElement('div')
element.addEventListener('click', heavyHandler)
container.appendChild(element)
container.innerHTML = ''  // element removed from DOM but listener holds reference
// element and heavyHandler are NOT garbage collected yet

// ✓ Remove listeners before removing elements, or use AbortController
const controller = new AbortController()
element.addEventListener('click', handler, { signal: controller.signal })
controller.abort()  // removes ALL listeners attached with this signal at once

JavaScript engine optimisations — what V8 does for you

// V8 uses "hidden classes" — objects with the same shape share a class
// ✓ Consistent property order — V8 optimises this pattern
function createPoint(x, y) {
  this.x = x  // always in this order
  this.y = y  // V8 creates one hidden class for all Points
}

// ❌ Inconsistent shape — V8 creates different hidden classes, deoptimises
const p1 = { x: 1, y: 2 }
const p2 = { y: 1, x: 2 }  // different property order = different hidden class

// ❌ Adding properties after creation — hidden class transition
const obj = {}
obj.x = 1   // transition 1
obj.y = 2   // transition 2 — slower than defining at creation

// ✓ Monomorphic functions — operate on one shape = inline cache hits
function getX(point) { return point.x }
getX({ x: 1, y: 2 })  // always the same shape = V8 optimises this path

// Inline caching — V8 remembers the type at each call site
// After seeing the same type a few times, it compiles a fast path
// Passing different types (polymorphic) kills the fast path

Measuring performance — the right tools

// Performance API — high-resolution timing
const start = performance.now()
expensiveOperation()
const duration = performance.now() - start
console.log(`Took ${duration.toFixed(2)}ms`)

// Mark and measure — named checkpoints in DevTools timeline
performance.mark('parse-start')
parseData(raw)
performance.mark('parse-end')
performance.measure('parse', 'parse-start', 'parse-end')
// Shows as named block in Performance tab

// User Timing API for production monitoring:
performance.mark('hero-image-start')
img.onload = () => {
  performance.mark('hero-image-end')
  performance.measure('hero-image-load', 'hero-image-start', 'hero-image-end')
  const [entry] = performance.getEntriesByName('hero-image-load')
  sendToAnalytics({ metric: 'hero-image-load', value: entry.duration })
}

// Long task detection — tasks > 50ms
const observer = new PerformanceObserver(list => {
  list.getEntries().forEach(entry => {
    console.warn(`Long task: ${entry.duration.toFixed(0)}ms`)
  })
})
observer.observe({ entryTypes: ['longtask'] })

Common JavaScript performance patterns

// Memoization — cache expensive computation 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
  }
}

const expensiveCalc = memoize((n) => {
  // simulate expensive work
  return fibonacci(n)
})

// Object pool — reuse objects instead of allocating new ones in hot paths
class ParticlePool {
  constructor(size) {
    this.pool = Array.from({ length: size }, () => ({ x: 0, y: 0, active: false }))
  }
  acquire() { return this.pool.find(p => !p.active) || { x: 0, y: 0, active: false } }
  release(p) { p.active = false }
}

// Avoid repeated property lookups in tight loops:
// ❌ Reads .length on every iteration
for (let i = 0; i < arr.length; i++) { ... }
// ✓ Cache it (micro-optimisation — engines often do this anyway)
for (let i = 0, len = arr.length; i < len; i++) { ... }

// Document fragment — batch DOM insertions
const frag = document.createDocumentFragment()
items.forEach(item => {
  const li = document.createElement('li')
  li.textContent = item
  frag.appendChild(li)  // no reflow yet
})
ul.appendChild(frag)  // ONE reflow