Performance Debugging Playbook (Chrome DevTools + Real Signals)
A senior-level workflow to diagnose performance issues: find the bottleneck, verify the hypothesis, ship the fix, and prevent regressions.
Frontend Interview Team
March 01, 2026
What you’ll learn
- A repeatable workflow for performance debugging (not random guessing)
- Which tools answer which questions
- How to avoid “works on my machine” performance fixes
30‑second interview answer
A good performance debugging workflow is: measure → find the bottleneck → form a hypothesis → validate → fix → re-measure → guardrail. In Chrome DevTools, the Performance panel helps you find long tasks and render delays, the Network panel exposes slow resources and caching issues, and Lighthouse is a useful regression signal—but real-user monitoring (RUM) is the truth.
Step 0: Define the problem precisely
“Page is slow” is not a problem statement.
Pick one:
- Slow initial load (LCP)
- UI feels laggy when typing/clicking (INP)
- Scrolling janks
- Memory leak / tab gets slower over time
Step 1: Decide the environment
Performance differs drastically between:
- Desktop vs low-end Android
- Cold cache vs warm cache
- Fast vs slow network
Production rule: Always test on a throttled profile.
Step 2: Use the right tool for the question
Performance panel (CPU + rendering)
Use when:
- INP/jank
- long tasks
- layout thrashing
What to look for:
- long tasks (50ms+)
- forced reflow/layout
- scripting vs rendering vs painting time
Network panel (bytes + blocking)
Use when:
- slow LCP
- slow TTFB
- big bundles/images/fonts
What to look for:
- waterfall critical path
- cache headers (
cache-control,etag) - render-blocking CSS/JS
Lighthouse
Use when:
- quick baseline
- regressions in CI
But don’t treat it as the only truth.
Step 3: Identify the bottleneck (common patterns)
Pattern A: “Network bound”
Symptoms:
- long download times
- slow TTFB
Fixes:
- CDN, caching, compression
- image formats/sizes
Pattern B: “Main thread bound”
Symptoms:
- long tasks
- delayed input handling
Fixes:
- reduce JS
- break up work
- avoid expensive renders
Pattern C: “Render bound”
Symptoms:
- layout/paint dominates
Fixes:
- reduce layout thrash
- use
content-visibility, reduce heavy effects
Step 4: Validate hypotheses with tiny experiments
Example: suspect a heavy component is causing jank.
- Temporarily remove it
- Re-measure
- If INP improves, you found a real root cause
Don’t ship guesses.
Step 5: Prevent regressions
Minimum guardrails:
- A Lighthouse budget in CI (or Vercel checks)
- Bundle size budget
- Track CWV via RUM if possible
Common mistakes
- Optimizing without a baseline
- Fixing the wrong device/profile
- Shipping a performance “fix” that only changes Lighthouse, not real users
Interview questions
-
Q: How do you debug slow LCP?
- A: Identify the LCP element and its critical path (network + render blocking + main thread). Fix the biggest blocker first.
-
Q: How do you debug INP?
- A: Use Performance panel to find long tasks around interactions; reduce main-thread work and rerenders.
Quick recap
- Measure first.
- Find the bottleneck.
- Validate with experiments.
- Fix and add guardrails.
Performance checklist (copy/paste)
- Write a precise problem statement (LCP vs INP vs CLS)
- Record a DevTools trace on a throttled profile
- Find the bottleneck (network vs main thread vs render)
- Ship the smallest fix that changes the metric
- Add a guardrail (budget/CI/RUM)