Performance Debugging Playbook (Chrome DevTools + Real Signals)

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

1. 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.

2. 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)