Question 1

What is the difference between debounce and throttle?

Accepted Answer

Debounce waits until events pause before running; throttle runs at most once per interval while events continue. Debounce: useful for search-as-you-type — fire after the user stops typing. Throttle: useful for scroll/resize handlers — ensure periodic updates without flooding. Both reduce main-thread work. Implement carefully with leading/trailing options. Prefer framework utilities but understand the semantics in interviews. Combine with requestAnimationFrame for visual updates.

Question 2

What is the critical rendering path, and how can JavaScript affect it?

Accepted Answer

CRP is the sequence to first paint: HTML/CSS/JS → DOM/CSSOM → render tree → layout → paint. JS can block parsing and delay first render. Parser-blocking scripts delay DOM construction. CSS blocks rendering. Strategies: defer/async scripts, split bundles, minimize critical CSS, preload key resources, avoid long tasks before hydration. Measure with LCP/FCP and waterfall charts. Inline only tiny critical JS. Understand that hydration JS can delay interactivity even after paint.

Question 3

How does code splitting and dynamic import() improve performance?

Accepted Answer

Load only the JS needed for the current route/feature, shrinking initial download/parse/compile cost. Bundlers create separate chunks loaded via dynamic import() when a route or feature is activated. Benefits: faster startup, better caching of stable vendor chunks. Costs: waterfalls if poorly designed, layout shift if UI isn't reserved, complexity in prefetching. Prefetch/preload critical next routes. Measure with coverage and bundle analysis. Combine with tree-shaking and deleting dead code.

Question 4

What are long tasks, and how do they relate to INP (Interaction to Next Paint)?

Accepted Answer

Long tasks are main-thread blocks roughly >50ms; they delay event handling and rendering, hurting INP and responsiveness. INP measures how quickly the page responds visually to user interactions across the page lifetime. Heavy JS in click handlers, synchronous JSON parse, or hydration can inflate INP. Fixes: break work into chunks, defer non-essential work, move compute to workers, optimize handlers, avoid large style/layout in events. Use Long Tasks API / Performance panel to find culprits. Prioritize interaction paths over background analytics.

Question 5

When is memoization a good performance strategy in JS, and when does it hurt?

Accepted Answer

Memoize pure expensive functions with stable inputs; avoid memoizing cheap functions or unbounded caches that leak memory. Memoization trades memory for CPU. Good: parsing, complex derived data with repeated identical inputs. Bad: functions with unique inputs each call (cache thrash), impure functions, or caches without eviction. In UI frameworks, over-memoization adds comparison overhead and complexity. Profile first. Prefer algorithmic improvements over micro-memo. Use WeakMap when keys are objects that should not retain memory.

Question 6

How would you build a performance culture for a JS frontend org (budgets, tooling, ownership)?

Accepted Answer

Set Core Web Vital budgets, RUM + lab CI gates, clear owners per surface, and make performance a release criterion—not a one-off project. Define budgets (LCP/INP/CLS, JS KB gzipped per route). Instrument RUM (real users) and synthetic checks on critical journeys. Fail CI on bundle regressions and lab regressions beyond thresholds. Assign feature owners; require perf impact in RFCs for heavy UI. Provide playbooks for images, fonts, JS. Educate via reviews and dashboards. Balance business features with degradation strategies. Avoid vanity micro-benchmarks without user impact. Celebrate wins with metric deltas.

Performance JavaScript Interview Questions

Other JavaScript interview topics