Frontend performance basics for interviews

Think in costs users feel

Performance interview questions usually map to load time, interactivity, and visual stability. You do not need to memorize every metric acronym, but you should know what slows a page: large JS bundles, render-blocking CSS, unoptimized images, and main-thread work.

Separate network cost (bytes and round trips) from runtime cost (parsing JS, layout, paint). Fixes differ: compress and lazy-load assets for the first; reduce work and avoid layout thrash for the second.

Concepts exams expect

Critical rendering path: HTML → DOM, CSS → CSSOM, combine into render tree, layout, paint. Defer non-critical scripts; prefer async/defer correctly. Images: modern formats, dimensions to reduce layout shift, lazy loading below the fold.

Caching and CDN basics matter for “how would you ship faster globally?” questions. Code splitting and tree-shaking reduce unused JS. Measure with Lighthouse or DevTools Performance — interviews often ask what you would look at first.

Practice path

Use the Frontend track for browser and asset questions, and the timed-MCQ strategy guide for pacing when stems include long code. Performance answers should be specific: name the bottleneck class, then the fix.