5 exercises — choose the best-structured answer to common Frontend Performance Engineer interview questions. Focus on precise vocabulary, correct use of technical terms, and demonstrating real experience.
Structure for frontend performance interview answers
Name the specific metric: LCP, CLS, INP — with the target threshold and what it measures
Cite lab vs field data: distinguish Lighthouse (lab) from CrUX (field) and explain why field data matters for ranking
Explain user impact: connect the technical metric to a real user experience outcome
Provide measurable targets: always state the "good" threshold and a realistic improvement goal
0 / 5 completed
1 / 5
The interviewer asks: "Can you explain the Core Web Vitals and how you would measure them in a real production environment?" Which answer best demonstrates web performance expertise?
Option B is strongest: it gives precise definitions with targets for all three metrics, names the INP replacement of FID with the exact date (March 2024 — showing current knowledge), explains the lab vs field distinction at the ranking level (CrUX is what Google uses, not Lighthouse), names the web-vitals library as the production measurement mechanism, and gives the concrete failure scenario (Lighthouse pass, CrUX fail on mobile 4G). Key structure: three metrics with targets → INP replaced FID (March 2024) → lab vs field distinction → CrUX for ranking → web-vitals library for production → Search Console for URL-level data → lab/field divergence example. Option C is accurate but does not explain the lab vs field distinction clearly or mention the INP replacement date. Option D mentions PageSpeed Insights and DevTools but does not explain why field data matters for ranking.
2 / 5
The interviewer asks: "How would you analyse and reduce JavaScript bundle size?" Which answer best covers bundle optimisation techniques?
Option B is strongest: it names the correct analyser for each build tool (webpack-bundle-analyzer vs Rollup visualiser), explains the tree-shaking preconditions (ES modules + named imports + sideEffects: false in package.json — often missed), names specific real-world culprits with sizes (moment.js locales at 100KB+), explains CI budget enforcement with specific tools, distinguishes route-based from vendor chunk separation with their respective benefits, and reframes the goal as critical path reduction rather than raw size (the expert framing). Key structure: tool by bundler type → tree-shaking preconditions → code splitting patterns → specific culprits → CI budget enforcement → route vs vendor chunk separation → critical path not total size. Option C is accurate but does not explain tree-shaking preconditions or the critical path reframing. Option D mentions sideEffects implicitly but does not name the package.json field or give the critical path insight.
3 / 5
The interviewer asks: "How do you optimise images for the web to improve LCP?" Which answer best demonstrates image optimisation expertise?
Option B is strongest: it leads with AVIF over WebP (with specific size percentages), explains the picture/source element for format selection, gives the critical rule that LCP images must not be lazy-loaded, names fetchpriority="high" (often missed), explains the CLS connection to width/height attributes, explains content-visibility for off-screen rendering deferral, and names CDN image transformation services. Key structure: AVIF first, WebP fallback with size savings → srcset and sizes for viewport sizing → LCP image: no lazy load + rel preload + fetchpriority high → below-fold: loading lazy (native) → width/height for CLS → CDN image transformation → content-visibility. Option C is accurate and covers preload but does not mention AVIF savings or fetchpriority. Option D mentions Squoosh/sharp (tools, not CDN services) and does not explain the critical path or fetchpriority.
4 / 5
The interviewer asks: "How do HTTP caching headers work, and what is your caching strategy for a web application?" Which answer best demonstrates caching header expertise?
Option B is strongest: it correctly defines no-cache as revalidate-on-every-request (not the same as no-store — a critical distinction commonly confused), explains the immutable directive for hashed assets, gives three distinct asset type strategies with reasoning, explains 304 Not Modified as the ETag/Last-Modified mechanism, distinguishes max-age from s-maxage for browser vs CDN, and introduces service worker strategies as an extension. Key structure: hashed assets: immutable + 1 year → HTML: no-cache (revalidate, not no-store) + ETag/304 → API: private/public by sensitivity → stale-while-revalidate use case → max-age vs s-maxage (browser vs CDN) → service worker extension. Option C is accurate but conflates no-cache with no-store and does not distinguish max-age from s-maxage. Option D does not explain the no-cache vs no-store distinction or s-maxage.
5 / 5
The interviewer asks: "What are the different lazy loading patterns, and when would you use each?" Which answer best explains lazy loading strategies?
Option B is strongest: it distinguishes five distinct patterns with use cases for each, explains Intersection Observer as the mechanism behind common libraries (not just "an API"), explains React.lazy/Suspense with concrete examples of what to lazy load (modals, chart libraries, third-party widgets), introduces skeleton screens with the key insight (perceived performance, not actual), and ends with the critical antipattern (never lazy load LCP). Key structure: native loading lazy (zero JS) → Intersection Observer (programmatic, rootMargin for pre-load) → component splitting with React.lazy for heavy components → route-based as standard pattern → skeleton screens for perceived performance → never lazy load LCP. Option C is accurate but does not explain rootMargin for pre-loading, the specific component use cases, or skeleton screen mechanics. Option D does not cover route-based splitting rationale or explain rootMargin.