Ask for One Response per Screen

Systems & Architecture · apis, performance, handoff

Updated 2026-08-04

Count the requests a screen makes before you call the design finished. A layout that needs profile, billing, usage, and recommendations from four separate places pays four network round trips before anything appears.
Ask for an endpoint shaped like the screen rather than like the database, which is what a backend for frontend exists to provide. One response containing exactly what this view renders is faster on a phone and simpler to put into a loading state.
Notice when the interface has become the coordinator. If the client is fetching, waiting, then fetching again based on the result, the sequence belongs on the server.
Treat this as a design conversation and not only an engineering one. The shape of a screen determines the shape of its request, so the two decisions should be made in the same room.
Design the loading state per response, not per element. Ten independent requests produce ten independent arrival times and a page that rearranges itself while someone is reading it.
Push filtering, sorting, and pagination to the server for anything that can grow. Downloading everything to sort it in the browser works until the account with 40,000 rows arrives.
Let genuinely optional content load separately. Something that can be missing without harming the screen is exactly the thing that should not block it.
Ask what a slow response does to the layout. If a late arrival shifts content that has already been read, the request boundary is in the wrong place.

The number of requests behind a screen is a design outcome, and it is decided long before anyone writes the fetch.