Browser interfaces · 4 / 4
Diagnose a slow interface
Your challenge
A product page feels slow despite a fast API. Describe a measurement-first investigation and the changes you would make.
Try it first. Write down your assumptions and explain your reasoning.
1.Identify the slow part
Use a browser performance trace and network waterfall. Distinguish initial content loading, input responsiveness and visual movement. Check device and network conditions; a fast laptop can conceal expensive client work. Measure a repeatable scenario before changing code.
2.Reduce work on the critical path
Render public content on the server where possible. Resize images, specify dimensions and prioritize only the main image. Delay optional widgets and large editors until needed. Avoid loading an entire chart library to draw a small decorative graphic.
3.Verify interaction costs
Look for long tasks, unnecessary renders and layout recalculation. Memoization helps only when measured repeated computation or prop churn matters. Virtualize genuinely large lists, not short lists. Repeat the same trace after changes, and check keyboard behavior and content visibility so performance fixes do not break usability.
Take it one step further
- 1.How can hydration delay usable interactions?
- 2.Why might a loading animation worsen perceived performance?
Self-review
Can you explain each point without looking at the solution?
- Use measurements before guesses
- Distinguish network from main-thread work
- Validate the same scenario after changes