Orientation: measure first, fix second, measure again

1. The promise

You'll know what this chapter covers, what it skips, and how the next seventeen units fit together. You'll run your first Lighthouse report — the Chrome-built-in audit that scores a page on performance — against your own deployed app. You'll write down four numbers. Those numbers are your baseline, the measurement you take before changing anything so you can prove a change helped. By the end of the chapter, you'll beat them.

2. The mental model

Performance work is a doctor's appointment. You don't prescribe before you check vitals. You measure, you diagnose, you treat, you re-measure. This chapter is a chain of those steps, in order.

The four areas the chapter covers:

• Frontend. What the browser does between bytes arriving and pixels showing up.
• Backend. What your Node server does while it holds a request open.
• Database. What Postgres does when you ask it a question.
• Caching. Four caches stacked in front of all three.

(DIAGRAM: the chapter map — flowchart — measure to frontend to backend to database to caching to queues to load test to flame charts to assignment)

3. You do it, with me

You'll measure your deployed app once. Not your localhost. Not your dev server. The real URL from Ch 24.

Open Chrome. Go to your deployed app in a fresh incognito window — a Chrome window with extensions disabled and no cookies — so the score isn't mangled by ad blockers.

Open DevTools (Cmd+Option+I on macOS, F12 on Windows). Click the Lighthouse tab. Pick Performance as the category. Pick Mobile as the device. Click Analyze page load.

(SCREENSHOT: Chrome DevTools Lighthouse panel before running an audit — full window — the "Analyze page load" button highlighted)

Wait for the report. It takes about 30 seconds.

(SCREENSHOT: Chrome DevTools Lighthouse report for the student's app — full window — Performance score and LCP/INP/CLS values highlighted)

You'll see a big circle with a number from 0 to 100. Underneath it, four metrics. Three of them — LCP, INP, CLS — are the Core Web Vitals (CWV), the three Google-tracked numbers that summarise how fast a page felt. You'll meet them in detail in 26.3.

Open VSCode. Create a file called PERF.md at the root of your project. Write down today's date and four numbers: Performance score, LCP, INP, CLS.

# PERF.md

## Baseline — 2026-06-18

Measured: deployed URL, Chrome incognito, Lighthouse Mobile, throttled.

- Performance score: 64
- LCP: 3.8s
- INP: 280ms
- CLS: 0.18

(SCREENSHOT: a plain text file with the baseline numbers written down — VSCode — full window)

That's your baseline. You'll beat it by the end of the chapter.

4. What you should be seeing

• A Lighthouse report from the deployed URL, not localhost.
• Four numbers written into PERF.md.
• An honest score. If you scored 100, you ran on localhost — re-run on the deployed URL.

If your score looks too good to be true, it is. Check the URL bar. Localhost has no network latency.

5. Common stumbles

• You ran Lighthouse on localhost. No network, no real CPU constraint. Score is fiction. Run against the deployed URL.
• You ran with extensions on. Ad blockers, password managers, and dev tools extensions skew the result. Use an incognito window.
• You forgot to save the baseline. Without a baseline, you can't prove a fix helped. Write the four numbers down before you touch any code.

6. You should know