The one-request rule: screens that load once

The dashboard felt instant in demos and sluggish in the office. The API was not the problem. The shape of the requests was: session, then team, then stats, then feed. Four round trips, each one waiting for the previous to resolve before it could even start.

On a warm connection that reads as 184 ms at p95. On a train, it reads as a spinner. The browser was doing exactly what we asked: coordinate.

01The waterfall tax#

It is tempting to blame the slowest endpoint. In our trace, no single endpoint took more than 48 ms. The damage came from addition: four reads of roughly 40 ms produced a 184 ms path because none of them could overlap.

We called it the waterfall tax. It compounds quietly, because every new piece of context — a team switcher, a feature flag, an avatar — arrives as another hook that depends on the value before it. The fix is architectural, not a faster cache.

02What we measured#

We instrumented four surfaces for two weeks before touching the architecture. The table shows median and p95 time-to-readable on a throttled 4G profile with a cold cache. Requests count every blocking read before the primary content is readable.

All values in milliseconds. Lower is better. Measured July 2026.

The billing page barely moved. That was useful: it told us the win came from removing sequential dependencies, not from a faster server. Billing already fetched its data in parallel.

03Collapse the requests#

Two changes did most of the work. First, the shell became a server component that reads the session cookie directly. Second, independent reads moved into a single Promise.all, so the slowest read sets the budget instead of the sum of every read.

1"use client";23export function Dashboard() {4  const session = useSession();5  const team = useTeam(session?.teamId);6  const stats = useStats(team?.id);7  const feed = useFeed(team?.id);89  // four round trips before first paint10  return <Frame session={session} team={team} stats={stats} feed={feed} />;11}

The after version still has four dependencies; it just does not serialize them. The server can read the session and start the other reads at the same time, because scoping happens inside the data layer rather than in the browser.

04Ship the shell first#

A fast dashboard is mostly a promise about what can wait. We split the page into three priorities, and gave each one a budget instead of a wish.

The frame0 ms

Navigation, title and layout skeleton are static. They stream on the first flush, before any data resolves.

The numbers~40 ms

Aggregate counts are scoped server-side and cached at the edge for thirty seconds. No personal data, no waterfall.

The feed~90 ms

The only personalized region arrives behind Suspense. It has the only skeleton, and it never blocks the shell.

The feed is the only part that may arrive late, and it is also the only part with a skeleton. The shell never waits for it. That single decision removed the layout shift that used to make the whole page feel broken on a slow connection.

05The trade-offs#

None of this is free. Server components make the boundary between data and presentation more explicit, and that boundary takes discipline. We also lost some client-side cache tricks: optimistic updates now need an explicit mutation path.

The team accepted the trade because the failure mode changed from a blank screen to a stale row. A stale row can be fixed on the next poll. A spinner at the top of the page cannot be fixed by anything except the network.

06A short checklist#

This is the list we run before merging anything that touches a data-fetching route. It is short on purpose. If a change cannot pass it, the design is not finished yet.