My pages load data in a chain: one request finishes, then the next starts, then the next. Each page takes the sum of many round trips to become usable. Find and fix my data fetching waterfalls: 1. Map the request sequence on my slowest pages: what fires on load, what waits on what. Identify chains where request B only starts after request A completes. 2. For each chain, determine whether the dependency is real: - Genuine dependency: B needs data from A (fetch the user's org, then fetch that org's projects). Fix by having the server return the combined data in one request, or by returning the needed identifier earlier (e.g. embedding the org ID in the session response). - False dependency: B doesn't actually need A's data, it just happens to be nested inside A's completion handler or rendered child component. Fix by firing both in parallel. 3. Fix render-triggered fetching: components that fetch only after their parent has fetched and rendered. Move the fetches up so they start together, or hoist them to the route level. 4. Where the server can do the joining cheaply, add endpoints that return aggregated page data instead of making the client orchestrate five calls. Don't parallelize requests where ordering actually matters (auth token refresh before authenticated calls). Don't introduce client-side caching to mask the waterfall; fix the structure. The deliverable is the request map before and after, the code changes, and the measured change in time-to-usable for the affected pages.