Frontend Performance Optimization Questions

Comprehensive techniques and trade offs for improving client side performance in web applications and single page applications. Candidates should understand the browser rendering pipeline and critical rendering path including parsing, style calculation, layout, paint, and compositing, and how layout and paint costs produce reflow and repaint. They should know how component design and code patterns affect rendering and how to avoid layout thrashing and unnecessary re rendering. Candidates must be able to diagnose and mitigate JavaScript execution bottlenecks and long tasks that block the main thread using browser developer tools and performance application programming interfaces. Key topics include bundling and module strategies such as code splitting, lazy loading, tree shaking, and bundle size reduction; image optimization and responsive image techniques; network optimization including resource prioritization, compression, and caching strategies; service workers for offline capabilities and advanced caching patterns; and use of web workers to offload computation. Advanced considerations include virtual scrolling for large lists, progressive enhancement, server side rendering and client side rendering trade offs and hydration cost for universal applications, browser memory management and garbage collection implications, and how frontend decisions interact with backend constraints and overall system architecture. Candidates should also be familiar with measuring user experience using Core Web Vitals such as Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift, with real user monitoring and synthetic testing, and with establishing performance budgets and continuous performance monitoring.

EasyTechnical

61 practiced

Walk me through using Chrome DevTools to measure a slow single-page app's load and runtime performance. List the DevTools panels and recordings you would use (e.g., Performance, Coverage, Network) and the steps to collect data for diagnosing long main-thread tasks and large bundle impact.

Sample Answer

**Approach (why)** As a full‑stack dev I collect both runtime traces (main‑thread work / long tasks) and network/bundle data to link slow UX to heavyweight JS or slow resources.

**Panels & recordings to use**- Performance — CPU profile, main‑thread, flame chart, long tasks, filmstrip- Network — resource sizes, waterfall, transfer vs. parsed/compiled time- Coverage (under Sources > Coverage) — unused JS/CSS bytes- Lighthouse (Audits) — overall metrics (FCP, TTI, LCP) and bundle suggestions- Memory — GC pressure causing jank (optional)- DevTools Console/Source maps — map heavy stacks to source code

**Step-by-step data collection**1. Reproduce the slow scenario in an incognito window with cache disabled (Network > Disable cache).2. Simulate real conditions: Network throttling (e.g., Slow 3G) and CPU throttling (e.g., 4x).3. Open Performance panel → click Record → perform the slow interaction → Stop. - Inspect Filmstrip, Timings (FCP, TTI), Main thread flame chart. - Use "Bottom-Up" and "Call Tree" to find long tasks (>50ms) and heavy functions. - Hover to see script URLs / line numbers; open Sources for source‑map mapping.4. In Network tab, reload with throttling → sort by Size and Time → identify large bundles, long TTFB, and blocking scripts. - Look at Initiator column to see which import/chunk caused load.5. Run Coverage to capture unused code: Start recording, exercise the app, then stop → find large files with low used bytes.6. Run Lighthouse audit (mobile/desktop) to get prioritized recommendations (code‑splitting, tree‑shaking, caching).7. Correlate: map long tasks from Performance to specific bundle files in Network and unused bytes in Coverage.

**What to look for & actions**- Long main‑thread tasks caused by parsing/compiling large bundles or heavy scripting → split bundles, lazy-load routes, web workers.- Large initial JS payloads → code‑split, remove polyfills, enable gzip/brotli, set proper caching.- Repeated GC or memory spikes → optimize memory usage, avoid retention, or use requestIdleCallback for non‑urgent work.

This process gives traceable evidence tying UX slowness to specific files and functions, enabling targeted fixes.

MediumSystem Design

83 practiced

Design a virtual scrolling (windowing) solution for rendering a list of 100k items in a SPA. Address dynamic item heights, keyboard accessibility, focus management, and how you'd test correctness and performance. Mention libraries you might use and why.

Sample Answer

**Clarify requirements & constraints**- Render 100k items in a SPA with good scroll performance, support dynamic item heights, keyboard access, predictable focus, and testable correctness/performance. Likely React frontend, optional paginated backend.

**High-level architecture**- Client-side virtualized list that only mounts visible items (+overscan).- Optional backend: API to fetch item ranges for infinite lists.

**Core components**- Virtualizer: maintains index → offset/height map, total scroll height, and window of rendered indices.- Measurement layer: measure items on mount (ResizeObserver) and update offsets; use estimated height until measured.- Focus manager: roving tabindex or aria-activedescendant; ensure the focused item is mounted (scrollIntoView) and preserve focus when list changes.- Accessibility: semantic roles (list/listitem), keyboard handlers (Up/Down/Home/End/PageUp/PageDown), announce changes with live regions when necessary.

**Handling dynamic heights**- Start with an estimated item height to compute initial offsets.- When an item mounts, measure its height, update map and total height, and adjust scroll position to avoid jump (compensate by adjusting container scrollTop).- Use ResizeObserver to handle height changes (images, async content).- Buffer/overscan to avoid re-render thrash when heights change.

**Keyboard & focus**- Use roving tabindex pattern: only one item tabindex=0; others -1. On arrow keys, move focus and call scrollIntoView if target not mounted.- For large jumps (PageDown), compute target index by offset/estimated height; ensure it's mounted before focusing.- Use aria-activedescendant if you want to keep container focus and announce active child.

**Libraries & why**- react-virtuoso — good built-in support for dynamic heights and smooth scrolling.- react-window with react-virtualized's VariableSizeList — lighter-weight; needs custom measurement for truly dynamic content.- use-resize-observer / ResizeObserver API — for height changes.- lodash.throttle/debounce — limit measurement updates.

**Testing correctness & performance**- Unit: jest + react-testing-library — mount with mocked heights, assert rendered index ranges, focus behaviors.- Integration/E2E: Cypress — simulate keyboard navigation, large scroll jumps, focus preservation, accessibility checks (axe).- Performance: Lighthouse, Chrome DevTools Performance/Memory, measure FPS and main-thread time during scroll. Load test with synthetic 100k data and verify memory and mount counts.- Metrics: time-to-first-paint, scroll latency (ms), mounted DOM nodes, JS main-thread time, memory footprint.

**Trade-offs**- Full measurement ensures accuracy but costs complexity; libraries like react-virtuoso reduce custom work. For maximum control choose react-window + custom measurement.

HardTechnical

82 practiced

Create a realistic performance budget for a medium-sized SPA (home page LCP target 2.5s). Include numeric budgets for: total JS bundle size, initial server payload (HTML), number of critical requests, time-to-first-byte, LCP, CLS, and max long task duration. Explain how you'd enforce this budget in CI and handle false positives.

MediumTechnical

78 practiced

Design a font-loading strategy to avoid FOIT (flash of invisible text) but also avoid large layout shifts. Explain how to use <link rel="preload">, font-display: swap, font subsets, and variable fonts. Include trade-offs for using system fonts vs web fonts.

Sample Answer

**Approach (goal):** avoid FOIT by showing text quickly, but prevent large layout shifts by keeping fallback metrics close to the web font so layout doesn't jump when the web font loads.

**Key techniques**- Preload the most-critical font files so the browser fetches them early.- Use font-display: swap so fallback text shows immediately then swaps to web font.- Use font subsets (e.g., latin-basic) to reduce preload size for initial render; lazy-load extended subsets.- Prefer variable fonts to replace multiple static files (weights/styles) with one compressed file.

**Example**

html

<link rel="preload" href="/fonts/Inter-var.woff2" as="font" type="font/woff2" crossorigin>

css

@font-face{
  font-family: "InterVar";
  src: url("/fonts/Inter-var.woff2") format("woff2");
  font-weight: 100 900;
  font-style: normal;
  font-display: swap;
}
body { font-family: InterVar, system-ui, -apple-system, "Segoe UI", Roboto, sans-serif; }

**Practical tips to reduce layout shift**- Match fallback metrics: choose a system fallback that approximates width/line-height; use font-size-adjust or CSS variable line-height to reduce reflow.- Reserve vertical space: set consistent line-height and prevent FOUT-driven height changes.- Use subsets for critical UI (nav, hero) and lazy-load full set for content-heavy pages.

**Trade-offs**- System fonts: instant, zero download, minimal CLS, but limited branding & weight variety.- Web fonts: better brand control and consistent rendering, but add payload and potential CLS if not tuned. Variable fonts + subsets + preload mitigate these costs.

**When to pick what**- Content-heavy apps where brand consistency matters: web fonts with preload + swap + subsets.- Performance-sensitive or localized UIs: prefer system fonts or only small subsets.

MediumTechnical

75 practiced

A popular content page has a high CLS score due to images and ads that load and shift content. Describe a step-by-step plan to reduce CLS including HTML/CSS changes, image attributes, ad sizing, and any runtime techniques. What metrics or tests would you run to validate the fix?

Sample Answer

**Situation & goal**Reduce CLS from images and ads by reserving space, loading efficiently, and avoiding layout shifts at runtime. Below is a step‑by‑step plan with concrete HTML/CSS/JS changes and validation tests.

**Step‑by‑step fixes**1. Reserve image space (intrinsic size / aspect-ratio)- Add width/height and responsive srcset; or use CSS aspect-ratio so browser can allocate layout before load.

html

<img src="hero.jpg" srcset="hero-800.jpg 800w, hero-1600.jpg 1600w"
     sizes="(min-width:800px) 1600px, 800px"
     width="1600" height="900" alt="...">

css

img { display:block; width:100%; height:auto; aspect-ratio: 16 / 9; object-fit:cover; }

2. Use low‑quality placeholders or LQIP/blur-up to avoid big visual jumps- Render a blurred tiny image or CSS background color matching dominant color until the full image loads.

3. Ads: reserve fixed slots & fallback content- Provide a container with explicit dimensions or min-height; use aspect-ratio for responsive ad slots. Only replace placeholder content, not insert new nodes above content.

html

<div class="ad-slot" id="ad-1" aria-hidden="true"></div>

css

.ad-slot { width:100%; aspect-ratio: 6 / 1; min-height: 90px; background:#f3f3f3; }

- Coordinate with ad provider to request sizes ahead of render, or use async loading into reserved element.

4. Runtime techniques- Use IntersectionObserver to lazy-load images below the fold (but keep reserved space).- Use a ResizeObserver on ad containers to avoid unexpected shifts; if ad expands, animate height changes or reserve for max size.- Avoid DOM insertions above existing content; append below or absolutely position overlays.- For client-side rendering, hydrate placeholders with the same dimensions server-rendered.

**Validation & metrics**- Synthetic: Lighthouse (Performance > CLS), Web Vitals extension for simulated pages; measure CLS (must be <0.1 good).- Real User Monitoring (RUM): capture cumulative_layout_shift per session, report % of users >0.1. Use Google Web Vitals JS or custom analytics.- Track layout shift events (element, start time) via PerformanceObserver:

javascript

new PerformanceObserver(list => {
  for (const entry of list.getEntries()) console.log(entry);
}).observe({type: 'layout-shift', buffered: true});

- A/B test before/after to ensure perceived UX improved and ad revenue unaffected.- Regression checks: run on multiple viewports and network conditions.

**Trade-offs & notes**- Reserving large ad slots may reduce content visible area — balance UX and revenue.- Preloading large images increases LCP cost; use preload only for hero images.- Collaborate with ad ops to serve predictable creatives.

This plan shows specific HTML/CSS/JS changes, runtime guards, and measurable validation to drive CLS improvements.

Unlock Full Question Bank

Get access to hundreds of Frontend Performance Optimization interview questions and detailed answers.

Join thousands of developers preparing for their dream job.