This page is mostly a lookup table, but it is the one to internalise: in an interview you will be given a symptom, and you get credit for reaching for the right instrument before the right fix.

Know

• Quote numbers, not adjectives. "TTFB p95 was 900 ms, three sequential fetches accounted for 640 ms of it, parallelising took it to 310 ms" is the sentence that ends the question.
• Say what you would not do. Refusing to cache a personalised route, or refusing to add a lever you cannot measure, reads as seniority.
• Distinguish p50 from p95. Averages hide the cache misses and the cold starts, which is exactly where the complaints come from.
• Know the cheap wins that are not free: prerendering breaks personalisation, SWR serves stale HTML after a deploy, lazy hydration delays interactivity, prefetching spends the user's bandwidth.

How it works

Four commands worth having in muscle memory:

# TTFB on a warm, built server (run it a dozen times, look at the spread, not one number)
curl -s -o /dev/null -w 'ttfb=%{time_starttransfer}s total=%{time_total}s size=%{size_download}B\n' http://localhost:3000/

# Throughput and latency percentiles under load
npx autocannon -c 20 -d 30 http://localhost:3000/

# Build time with and without a change, repeated and averaged
hyperfine --warmup 1 --runs 5 'pnpm nuxt build'

# Where the client bundle went
pnpm nuxt analyze

A Server-Timing header turns the browser's Network panel into a server profiler, which is the fastest way to show a team where the time goes:

export default defineNitroPlugin((nitroApp) => {
  nitroApp.hooks.hook('request', (event) => {
    event.context.startedAt = performance.now()
  })
  nitroApp.hooks.hook('beforeResponse', (event) => {
    const started = event.context.startedAt as number | undefined
    if (!started) return
    setResponseHeader(event, 'Server-Timing', `total;dur=${(performance.now() - started).toFixed(1)}`)
  })
})

Exercise

Be able to say