CHAPTER 11 / 13 · READ → DECIDE → BUILD

Measure before making it clever.

Find the real bottleneck and keep improvements honest.

18 min + practiceA performance baselineJump to practice ↓

Measure a user journey

Choose a representative task: load the board and claim a task. Record environment, data size, device/network conditions, and repeated samples. Separate database time, server time, transfer, and browser work where your tools allow it. A slow first request may differ from a warm request. Without a repeatable baseline, a faster-feeling page can be a different network condition rather than an improvement.

Optimize the measured constraint

If the task list fetches one extra record for every card, inspect query counts before adding a cache. If the browser ships a large library for one small interaction, inspect the bundle. If images move the page while loading, reserve dimensions. Each change has trade-offs: indexes cost writes and storage, caches introduce freshness and permission questions, and lazy loading can delay useful controls. Choose the smallest change that addresses the observed problem.

Bound resource use

Set deliberate request timeouts and sensible concurrency limits. An unbounded retry loop can turn a small outage into a large bill. For a learning deployment, avoid load testing public production services. Use an authorized isolated environment, stop conditions, and synthetic data. Treat a proposed latency target as a target until measurements demonstrate it. Keep correctness, accessibility, and permissions in the verification after optimization.

SEE THE DIFFERENCE

A small example. A better decision.

THE INITIAL APPROACH

The app feels slow. Add caching everywhere.

THE MORE USEFUL APPROACH

The trace shows 21 queries for 20 tasks. Batch the related read, compare repeated measurements, and recheck visibility rules.

A specific observation supports a focused change and makes the result easier to assess.

Your build steps

Record a repeatable baseline for the critical journey.
Identify one bottleneck using actual measurements.
Make one focused improvement or explain why none is needed yet.
Repeat the measurement and rerun correctness checks.

FROM THE PROMPT LIBRARY

A useful brief for this step.

Establish a performance baseline ↗Prevents optimization based on impressions rather than measurements.Investigate a slow database query ↗Finds the actual cause of a slow read before adding infrastructure.Find an N-plus-one fetch pattern ↗Reduces repeated round trips hidden inside loops and nested rendering.All performance & reliability prompts

MAKE THE CALL

Think like the reviewer.

A query is slow and there is no execution plan or measurement yet. What is the best first move?Replace the database immediately.Add several indexes and assume it is fixed.Capture a safe baseline and inspect the query plan.

BUILD YOUR WORKBOOK

A performance baseline

0/3 notes ready

Use the lesson and your project evidence. Your workbook saves privately; keep credentials and private records out. The checks below assess completion of the exercise, not the correctness of an external app.

1. Baseline and conditionsAdd a specific note of at least 20 characters.2. Bottleneck hypothesis and changeAdd a specific note of at least 20 characters.3. Comparison and limitationsAdd a specific note of at least 20 characters.

Before moving on

The comparison uses similar conditions.The proposed improvement follows a measured observation.I checked that the improvement preserves correct behavior.

Loading your workbook…