ðŸĶ–FrontendDinosaur
Fossils🧠 ConceptualHow Would You Optimize a Slow Web App?
ðŸĶ–DinosaurPerformanceArchitectureStrategy

How Would You Optimize a Slow Web App?

This open-ended question tests your diagnostic framework, not just your knowledge of techniques. Senior engineers have a systematic approach, not a bag of tricks.

How Would You Optimize a Slow Web App?

Interview Question: "A user reports the app is slow. Walk me through how you'd approach this."

The Senior Framework

Don't jump to solutions. Present a systematic diagnostic process:

"I'd approach this in four phases: Measure, Diagnose, Fix, Verify. The biggest mistake is guessing — optimizing the wrong thing wastes effort and can make things worse."

Phase 1: Measure

"First, I need to know what kind of slow:

  • Slow to load? → LCP, TTFB, FCP (network + rendering pipeline)
  • Slow to interact? → INP, TBT (main thread blocking)
  • Visually unstable? → CLS (layout shifts)
  • Slow over time? → Memory leak, growing DOM, timer accumulation

I'd check field data (RUM) if available — real user p75 metrics segmented by page, device, and connection. Then reproduce in lab with Lighthouse and Chrome DevTools Performance tab."

Phase 2: Diagnose

"The Performance tab flame chart tells me where time is spent:

  • Long yellow bars → JavaScript execution (look for specific functions)
  • Purple bars → Layout/Style recalculation (DOM thrashing?)
  • Green bars → Paint (complex CSS, large areas)
  • Red triangle → Dropped frames (main thread blocked too long)

For loading issues: Network waterfall shows critical request chains, render-blocking resources, and slow server responses."

Phase 3: Fix (Prioritized)

"I fix in order of impact:

Loading performance:

  1. Server response (TTFB) — CDN, caching, edge computing
  2. Render-blocking resources — Inline critical CSS, defer/async scripts
  3. Resource loading — Preload hero image, lazy-load below fold
  4. Bundle size — Code split, tree shake, compress

Runtime performance:

  1. Long tasks — Break up, Web Workers, scheduler.yield()
  2. Rendering — Virtualize long lists, content-visibility: auto
  3. State management — Prevent cascading re-renders
  4. Memory — Fix leaks, limit cache sizes"

Phase 4: Verify

"Run the same measurements again. Compare before/after. Set performance budgets in CI to prevent regression. Monitor field metrics for 2 weeks to confirm improvement across real users."

Follow-Ups

"How do you prevent regressions?"

"Three layers: Lighthouse CI on every PR (catches load regressions), bundle size checks (catches dependency bloat), and RUM monitoring with alerts (catches production regressions). Performance budgets should break the build, not just warn."

"What if the app is slow on mobile but fast on desktop?"

"Mobile has 3-5x less CPU power and often slower networks. I'd focus on: reducing JavaScript (parse + compile is the biggest mobile tax), code splitting more aggressively, using content-visibility for off-screen content, and testing on a real mid-range device (not just Chrome throttling)."

"What's the most common mistake you see?"

"Optimizing without measuring. Engineers add React.memo everywhere 'for performance' when the actual bottleneck is a 300KB chart library loading on every route. Always profile first."

The One-Liner

"Performance optimization is a diagnostic discipline, not a bag of tricks. Measure, then fix the highest-impact issue. Repeat."

Red Flags

  • Jumping to "add React.memo" without diagnosing first
  • Only knowing one dimension of performance (loading but not runtime, or vice versa)
  • No mention of measurement tools or methodology
  • Not distinguishing between lab and field data
  • Proposing fixes without knowing the root cause