Make the important work feel fast
Measure loading, interaction, and stability; fix the bottleneck that affects the user’s actual task.
Why this matters
Start with a slow moment you can repeat. Name the task, device, network, content, and state before you pick a fix. A crew member opening tomorrow's assignments on an old phone with weak signal is a task; "the app feels slow" isn't. A fast first paint doesn't prove a filter answers quickly or a save finishes reliably.
What to understand
Waiting time comes in three flavors — loading, responsiveness, and stability. CLS means layout shifting under the user. Judge these at the 75th percentile, mobile and desktop apart. TTFB and FCP help diagnosis but aren't Core Web Vitals. See Web Vitals for definitions and how to measure.
Watch for
- Fixing what you didn't see — caching logic for a slow database query, animation for a slow save.
- Lazy-loading the hero image, or un-sized images and late fonts shifting the layout.
- Assuming an image or font API guarantees zero shift on its own.
- Reading real-user responsiveness off Lighthouse navigation runs.
- Treating a timing win as an automatic business win.
Strong default
Fix the one step that costs the most for this task. Hold back heavy features the first task doesn't need. Keep code on the server when the browser doesn't need to run it. Check the real bundle instead of guessing its size from an import. Size images right, reserve their aspect ratio, and give custom fonts a loading and fallback plan.
When this doesn't apply
Don't apply every optimization everywhere. System fonts skip a download and suit utility-dense tools; custom fonts earn their cost on brand-led surfaces with a proper fallback plan. Code-splitting a rarely-visited admin panel won't speed the crew member's morning list.
In practice
| Metric | Meaning | Good threshold |
|---|---|---|
| LCP | When the largest visible content element renders. | At most 2.5 seconds. |
| INP | Responsiveness across qualifying interactions. | At most 200 milliseconds. |
| CLS | Unexpected movement of visible content. | At most 0.1. |
Add a task measure when it helps: time to open a big crew list, filter by day, or confirm a reassignment.
Find the limiting step: late content means checking request order, server work, content discovery, and saved-copy policy; slow interaction means long main-thread tasks, rendering cost, heavy handlers, and data volume; layout movement means missing image sizes, late fonts, inserted content, and scrollbar changes; slow finish means the API, database, background work, and confirmation path — not just the browser. Ask your agent: "show me the one step that costs the most for this task."
A repeatable lab run helps you compare fixes and explain causes. Field data shows real phones, real taps, real range.
Verify
Measure a production build, keep conditions comparable, and re-run after the fix. Note the route, device and network, metric, and sample limits. Check layout anchors across routes and overlays too: a good CLS score alone doesn't prove a steady screen.
Related skills
Continue with observability to keep watching the user experience after release.
Last updated on