Web Performance Interview Questions and Answers

Core Web Vitals are user-centric metrics for loading, interactivity and visual stability. LCP, Largest Contentful Paint, measures when the largest visible element, usually a hero image or heading, is rendered; good is 2.5 seconds or less. INP, Interaction to Next Paint, replaced FID in 2024 and measures the latency of the worst interaction at a high percentile; good is 200 milliseconds or less. CLS, Cumulative Layout Shift, quantifies unexpected movement of visible content; good is 0.1 or less.

They are evaluated at the 75th percentile of real user visits, combining mobile and desktop. They feed into Google's page experience signal and correlate with user satisfaction and conversion.

Supporting metrics include TTFB, FCP and TBT, which help diagnose root causes but are not vitals. Always optimise the tail, because a good average can hide a poor 75th percentile.

Lazy loading defers work until it is needed. For images, loading="lazy" and decoding="async" defer off-screen loads, but never lazy-load the LCP image because it delays the largest paint. For iframes and heavy media, load on intersection with an IntersectionObserver or loading="lazy".

Code splitting breaks a JavaScript bundle into chunks loaded on demand. Bundlers create a chunk per dynamic import:

const Chart = lazy(() => import('./Chart'));

Route-based splitting is the highest-value pattern, because users only download the page they visit. React.lazy, Vue's defineAsyncComponent and Next.js dynamic imports integrate chunk loading with Suspense boundaries. Also split large vendors and load polyfills conditionally with module and nomodule.

The trade-off is extra network round trips, so preload or prefetch likely next routes and avoid creating hundreds of tiny chunks. Combine splitting with a fast CDN and long-lived caching of hashed filenames.

LCP is dominated by four factors: time to first byte, resource load time, render-blocking resources and client-side rendering delay. First ensure fast TTFB with caching, a CDN and server-side rendering or static generation.

For the LCP element, usually a hero image, add fetchpriority="high", serve modern formats such as AVIF or WebP with a responsive srcset, and never lazy-load the LCP image, because lazy-loading it is a common self-inflicted regression. Preload critical fonts and the image, and inline critical CSS so the render is not blocked.

<img src="/hero.avif" width="1200" height="600"
     fetchpriority="high" alt="Hero" />

Remove or defer unused JavaScript and CSS, and avoid layouts that wait on data. Use next/image or an equivalent to generate srcset and sizes, and always set explicit dimensions to avoid shift. Measure with Lighthouse and the Performance panel, then confirm with field data from CrUX or the web-vitals library.

CLS measures how much visible content moves unexpectedly. The score for a shift is the impact fraction times the distance fraction, summed over the session, excluding shifts within 500 milliseconds of user input.

Common causes: images and videos without width and height or aspect-ratio, ads, embeds and iframes injected above content, web fonts swapping and changing metrics, dynamic content inserted above the fold, and late-loading UI such as cookie banners.

Fixes: always reserve space with width and height or CSS aspect-ratio. Use font-display: optional or preload fonts and match fallback metrics with size-adjust. Use contain-intrinsic-size with content-visibility for long pages. Avoid inserting banners above existing content; overlay them instead, and reserve fixed slots for ads.

Test with the Performance panel and the CLS contribution in Lighthouse, and check field data, because real-world shifts depend on slow networks and font timing.

The critical rendering path is the sequence the browser follows to turn HTML, CSS and JavaScript into pixels: parse HTML into the DOM, parse CSS into the CSSOM, combine them into the render tree, then layout and paint. CSS is render-blocking because the browser cannot build the render tree without the CSSOM, so a stylesheet in the head delays first paint. Synchronous scripts block HTML parsing, and any script that reads or writes layout can force a costly reflow.

Optimising means minimising the number of critical resources and their bytes: inline critical above-the-fold CSS, defer non-critical CSS, load scripts with defer or async, and avoid chained request waterfalls.

Techniques include preloading key resources, preconnect to required origins, removing unused CSS, and keeping the DOM small. content-visibility: auto lets the browser skip rendering off-screen content. The Performance panel flame chart confirms whether a delay comes from CSS, JavaScript execution or resource loading.

Caching avoids re-downloading assets and is one of the cheapest performance wins. Use content-hashed filenames with a long Cache-Control: public, max-age=31536000, immutable for static assets, so repeat visits hit the browser cache. HTML should be short-lived and revalidated with no-cache or a small max-age so deployments are picked up. ETag with If-None-Match and Last-Modified with If-Modified-Since enable conditional requests that return 304 instead of a body. stale-while-revalidate and stale-if-error let a CDN serve slightly stale content while refreshing in the background, improving availability.

CDNs cache at edge locations close to users, reducing TTFB and offloading origin traffic. Configure s-maxage and Vary carefully, because Vary fragments caches, and purge on deploy.

A service worker adds a client-side layer for offline use and instant repeat loads, but cache invalidation must be handled carefully or users get stuck on old versions. Always verify headers in the network panel.

Interaction to Next Paint measures the time from a user interaction such as a click, tap or key press until the browser paints the next frame, across the whole visit, reporting roughly the worst interaction. A long INP means the page felt laggy. It is driven by long tasks that block the main thread: heavy event handlers, large synchronous renders, layout thrashing and third-party scripts. Diagnose with the Performance panel's interactions track and the web-vitals library with attribution.

Improvements: break up long tasks with scheduler.yield() or setTimeout(0) and yield to the browser. Keep event handlers short and debounce high-frequency events. Avoid reading layout properties such as offsetHeight immediately after writes, which forces reflow. Reduce hydration cost and re-render less with fine-grained reactivity or memoisation. Defer and lazy-load non-critical third-party scripts, and move heavy work to Web Workers.

INP is about perceived responsiveness, so optimise the few interactions users actually perform.

Lab tools run in a controlled environment. Lighthouse gives a synthetic score with TTFB, FCP, LCP, TBT and CLS, which is useful in CI and for reproducible comparisons. Chrome's Performance panel profiles the main thread to find long tasks and layout thrashing. WebPageTest adds device and network throttling, filmstrips and waterfall analysis.

Field data reflects real users. Real User Monitoring collects metrics with the web-vitals library through onLCP, onINP and onCLS, plus custom timing from the Performance Observer API. CrUX provides aggregated Chrome data, and Search Console surfaces Core Web Vitals pass and fail by URL group.

The two complement each other: lab data explains why and reproduces issues, field data shows whether real users are affected and at what percentile. The standard target is the 75th percentile, so a good average can hide a poor tail. Segment field data by device, network and geography, and set up alerts on regressions. Ship RUM before optimising so you can measure impact.