Frontend Performance45-70 min
Network Waterfall Optimization
Read the waterfall, identify blocking chains, parallelize independent requests, and cache or prefetch predictable data.
Chrome DevToolsRESTReact QueryCDN
Prerequisites
- A page with slow loading caused by multiple network requests.
- Network tab access with cache disabled.
- Knowledge of which requests depend on each other.
1
Plan the implementation
Start by choosing the exact page, route, API, or deployment surface you want to improve. A narrow target makes the implementation measurable and easier to verify.
- Write down the current behavior and the user-facing problem it creates.
- Pick one measurable success signal such as bundle size, latency, error rate, security coverage, or UI responsiveness.
- Identify the files, routes, providers, and environment variables involved.
- Create a rollback note before changing production-sensitive configuration.
2
Set up the required tools
Install or configure only the tools needed for this implementation. Keep config close to the feature so future developers can find the moving parts quickly.
Implementation snippet
npm run preview
# DevTools > Network > Preserve log > Disable cache.Checklist
- Dependencies are added to the correct workspace package.
- Environment variables are documented in `.env.example` when needed.
- Local development still starts without production-only secrets.
- The change is small enough to review in one pull request.
3
Implement the core pattern
- Record a page load and sort requests by start time.
- Mark requests that truly depend on previous responses.
- Move independent requests into parallel loading.
- Combine small chatty endpoints when one screen always needs them together.
- Cache stable responses and remove unnecessary blocking requests.
Implementation snippet
const [profile, projects, notifications] = await Promise.all([
api.getProfile(),
api.getProjects(),
api.getNotifications(),
]);4
Handle edge cases
Checklist
- Independent requests start in parallel.
- Critical HTML, CSS, fonts, and LCP media are not delayed by low-value calls.
- Server endpoints avoid N+1 database behavior.
- Slow third-party calls do not block primary content.
5
Verify before production
- Run the app locally and test the normal success path.
- Test one failure path, one empty state, and one slow-network or retry path.
- Run the project build and any related unit or integration tests.
- Check browser console, server logs, and network responses for hidden warnings.
- Document the final behavior, commands used, and any follow-up work.