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

104 practiced

Explain the Core Web Vitals relevant to frontend developers: Largest Contentful Paint (LCP), First Input Delay (FID) / Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). For each metric describe what it measures, common frontend causes for poor scores in SPAs, and at least two practical techniques you would use to improve each metric.

MediumTechnical

85 practiced

In plain JavaScript (no framework), implement a simplified virtual scroller for a list with a very large number of fixed-height items. The component should: accept `containerHeight`, `itemHeight`, and `totalCount`, render only the visible items into a scrollable container with a correctly sized spacer element, and update rendered items on `scroll`. Focus on correctness, not styling. Provide the implementation in ES6.

Sample Answer

**Approach (brief)**- Compute how many fixed-height items fit in container + a small buffer.- Use a tall spacer div to create correct scrollbar height.- Render only visible items positioned absolutely inside the container.- Update on scroll by recalculating start index and reusing DOM nodes.

**Implementation (ES6)**

javascript

// VirtualScroller constructor
class VirtualScroller {
  constructor({ containerHeight, itemHeight, totalCount, renderItem }) {
    this.containerHeight = containerHeight;
    this.itemHeight = itemHeight;
    this.totalCount = totalCount;
    this.renderItem = renderItem; // function(index) -> HTMLElement or string

    this.viewport = document.createElement('div');
    Object.assign(this.viewport.style, {
      position: 'relative',
      height: containerHeight + 'px',
      overflowY: 'auto',
    });

    // spacer to produce full scroll height
    this.spacer = document.createElement('div');
    this.spacer.style.height = (totalCount * itemHeight) + 'px';
    this.viewport.appendChild(this.spacer);

    // pool container where visible items are absolutely positioned
    this.pool = document.createElement('div');
    Object.assign(this.pool.style, { position: 'absolute', top: 0, left: 0, right: 0 });
    this.viewport.appendChild(this.pool);

    // compute counts
    this.visibleCount = Math.ceil(containerHeight / itemHeight) + 1; // +1 buffer
    this.firstIndex = 0;
    this.rendered = new Map();

    this.onScroll = this.onScroll.bind(this);
    this.viewport.addEventListener('scroll', this.onScroll);

    // initial render
    this.onScroll();
  }

  mount(parent) {
    parent.appendChild(this.viewport);
  }

  onScroll() {
    const scrollTop = this.viewport.scrollTop;
    const newFirst = Math.floor(scrollTop / this.itemHeight);
    if (newFirst === this.firstIndex) return;
    this.firstIndex = Math.max(0, Math.min(newFirst, this.totalCount - 1));
    this.update();
  }

  update() {
    const start = this.firstIndex;
    const end = Math.min(this.totalCount, start + this.visibleCount);
    // recycle: remove items outside range
    for (let [idx, el] of Array.from(this.rendered)) {
      if (idx < start || idx >= end) {
        this.pool.removeChild(el);
        this.rendered.delete(idx);
      }
    }
    // add missing items
    for (let i = start; i < end; i++) {
      if (!this.rendered.has(i)) {
        const node = this.renderItem(i);
        const el = (typeof node === 'string') ? document.createElement('div') : node;
        if (typeof node === 'string') el.innerHTML = node;
        Object.assign(el.style, {
          position: 'absolute',
          top: (i * this.itemHeight) + 'px',
          height: this.itemHeight + 'px',
          width: '100%',
          boxSizing: 'border-box',
        });
        this.pool.appendChild(el);
        this.rendered.set(i, el);
      } else {
        // update position in case scroll moved fractional px
        const el = this.rendered.get(i);
        el.style.top = (i * this.itemHeight) + 'px';
      }
    }
  }

  // cleanup
  destroy() {
    this.viewport.removeEventListener('scroll', this.onScroll);
    if (this.viewport.parentNode) this.viewport.parentNode.removeChild(this.viewport);
    this.rendered.clear();
  }
}

**Notes, complexity & edge cases**- Time: O(visibleCount) per scroll update. Space: O(visibleCount).- Handle very large totalCount by using number arithmetic only (no full DOM).- Consider adding requestAnimationFrame debounce for smoother scroll handling and a slightly larger buffer to avoid visible gaps.

HardTechnical

57 practiced

Explain advanced compositing and layer management techniques to reduce paint cost: how properties like `transform`, `opacity`, and `will-change` create compositing layers, the role of CSS containment (`contain`), when to use `translateZ(0)` or `will-change` to promote layers, and the trade-offs (memory usage, rasterization cost) of overusing layers. Describe how you'd debug layer and paint issues using DevTools.

Sample Answer

**Brief overview**Compositing layers let the GPU rasterize and composite parts of the page independently so changes (transforms, opacity) avoid full re-paints. Use them judiciously to reduce paint cost and jank.

**How layers are created**- Properties that typically promote to a compositor layer: `transform` (any non-none), `opacity` (when animated), `filter` (some engines), `will-change` hints, `position: fixed/sticky` in some contexts.- `will-change: transform, opacity` tells the browser you intend to animate those properties and can pre-create a layer.- `translateZ(0)` or `transform: translate3d(0,0,0)` forces GPU compositing by creating a 3D context—useful as a last-resort promotion.

**CSS containment**- `contain: layout paint size` or just `contain: paint` limits layout/paint scope so changes inside don’t force parent repaint. Useful to isolate complex widgets and reduce repaint chains.

**When to promote**- Promote elements that are frequently animated (transforms, opacity) or have rolling repaint costs (sticky toolbars, animated sprites).- Prefer `will-change` during the short time before/while animating; remove it afterwards to avoid long-term memory cost.

**Trade-offs**- Memory: each layer consumes memory for offscreen buffers (rasterized bitmaps), increasing RAM.- Rasterization cost: initial rasterization or re-rasterization on size/content change can stall frames.- Overuse: too many layers overwhelm GPU and can regress performance (OOM, increased memory transfers).

**Debugging with DevTools**- Use Chrome DevTools Rendering > "Show paint rectangles" to see paint areas.- Enable "Layer borders" / "Show composited layer borders" to visualize layers.- Use Performance tab: record, inspect "Paint", "Composite Layers", "Rasterize" events and look for long tasks.- Use Coverage / Memory to watch GPU memory usage and check if layers are retained too long.- Experiment: toggle `will-change`, remove transforms, or add `contain: paint` and re-profile to confirm impact.

Overall: promote only hot-path elements, prefer GPU-friendly animations (transform, opacity), use containment to isolate heavy paint, and profile with DevTools to verify real-world benefits.

MediumTechnical

76 practiced

Design a service worker caching strategy for a news web application that must deliver the freshest headlines on load but also allow users to read previously viewed articles while offline. Explain which caching strategies (network-first, cache-first, stale-while-revalidate) you would use for: the homepage/headlines, article pages, article images/assets, and API responses for search. Mention how you would handle cache invalidation and offline analytics/events.

Sample Answer

**Approach summary**I design per-resource strategies driven by UX: homepage/headlines must be as fresh as possible on load; article pages must be readable offline if previously visited; images/assets should load fast but be bounded; search needs fresh results but fallback to cache when offline.

Homepage / Headlines- Strategy: network-first (with short timeout, e.g. 2s) then fallback to cached snapshot.- Why: deliver freshest headlines on load, but show last-known headlines when network slow/offline.- Implementation note: cache a lightweight JSON snapshot (cache name: headlines-v1).

Article pages- Strategy: cache-first with stale-while-revalidate.- Why: users expect to read previously opened articles offline; background revalidation fetches updates for next visit.- Implementation: store HTML/JSON article payload keyed by article-id; respond from cache immediately and fetch to update.

Article images / static assets (CSS/JS)- Strategy: cache-first with expiration and LRU (or workbox expiration plugin).- Why: improve performance and reduce bandwidth; bound storage.- Implementation: cache name assets-v1, maxEntries (e.g. 100), maxAgeSeconds (7 days).

API responses for search- Strategy: network-first with cache fallback; for frequent repeated queries consider stale-while-revalidate with short TTL for identical queries.- Why: users expect up-to-date search results; but allow fallback when offline.- Implementation: cache by normalized query string, short TTL (e.g. 1–5 minutes).

Cache invalidation & freshness- Use versioned cache names (headlines-v2) to force hard invalidation when breaking changes occur.- Respect HTTP caching headers (ETag/Last-Modified) and conditional requests to reduce payload.- Use background revalidation to update cached entries after serving stale content.- Periodic cleanup: during activate event, delete old caches; enforce maxEntries and maxAge.

Offline analytics & events- Queue events in IndexedDB and use Background Sync to flush when connectivity returns; as fallback attempt navigator.sendBeacon on visibility change or on reconnect.- Include metadata (timestamp, client-id, user-state) and dedupe on server.

Tools / Implementation hints- Use Workbox to implement stale-while-revalidate, expiration plugins, background sync, and routing rules to keep code concise and robust.

MediumTechnical

111 practiced

Describe practical tree-shaking gotchas when using mixed module types and bundler configurations: why CommonJS and dynamic `require()` hamper dead-code elimination, how `package.json` `sideEffects` affects bundling, and examples of source code patterns (mutated exports, dynamic property lookups) that prevent optimizers from removing unused code. Suggest fixes or mitigation steps.

Sample Answer

**Answer (Structured):**

**Short summary**Tree-shaking fails when bundlers can't statically determine which exports are unused. CommonJS, dynamic require, mutated exports, and runtime property access are common gotchas. Use ESM, avoid mutation/dynamic imports, and mark modules side-effect-free.

**Why CommonJS & dynamic require hurt**- CommonJS (module.exports / require) is dynamic: require() can run arbitrary code and exports can be reassigned, so static analyzers can’t guarantee safety and conservatively keep more code.- Dynamic require(e.g. require(variable) or conditional require) prevents static resolution of import graph → bundlers include whole modules.

**package.json sideEffects**- "sideEffects": false tells bundlers (webpack, rollup) modules have no module-level side effects so unused exports can be removed.- If a package contains files with side effects (CSS, polyfills), list them or use true/array. Wrong setting can break app or prevent tree-shaking.

**Source patterns that block tree-shaking (examples)**- Mutated exports:

javascript

// bad
export let count = 0;
export function inc(){ count++; }

Mutating exported bindings prevents removal because runtime state matters.

- Reassigning module.exports (CommonJS):

javascript

// bad
module.exports = { a: fnA, b: fnB }; // non-ESM shape

- Dynamic property lookups:

javascript

const handlers = { a: fnA, b: fnB };
const key = getKey();
handlers[key](); // bundler cannot prune unreachable fn

- Side-effectful top-level code:

javascript

// does DOM mutation at import time
console.log('init'); document.body.classList.add('x');
export const util = () => {};

**Fixes / mitigations**- Prefer ESM static imports/exports:

javascript

import { fnA } from './lib.js';

- Avoid mutating exported bindings; export pure functions/consts.- Replace dynamic require with dynamic import() where possible (code-splitting + static analyzable).- Set "sideEffects" in package.json accurately; list files with side-effects.- Use explicit named exports rather than exporting an object default to help bundlers.- For third-party CJS packages, use tools like esm-shim, or bundle-transforms (babel plugin-transform-modules-commonjs -> tree-shaking-unfriendly — prefer leave as ESM).- Run bundle analyzer and enable production mode (minification + tree-shaking) to verify.

**Outcome**Following these rules reduces bundle size and avoids mysterious runtime breakage while preserving correctness.

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.