Presenting what is already ready beats waiting for the whole

What it is

A page or a result almost never arrives in one millisecond. The first principle of chunked loading is: put the chunk that is already ready on screen. Do not hold the whole page for an image, a comment thread or a recommendation that has not landed. Waiting for the whole turns the slowest chunk into everyone’s wait; presenting first moves the moment reading and orientation can start up to the fastest chunk.

This leaf is only “paint what you have”. Whether later chunks shove what was painted, and which chunk is worth painting first, are the next two leaves.

Why it happens

A fetch is internally several parts that finish on their own clocks: shell, body, media, rail, footer. Human work, though, starts at “seeing a structure I can recognise” — read the title, decide if this is the page I wanted, decide whether to scroll. Holding shell and title until the last image returns parks cognitive work that was already possible at the starting line. The first meaningful paint is usually decided by the chunk that lets people find their way, not by 100% of the bytes.

Waiting for the whole is sometimes framed as “so we don’t show a half-built thing”. The risk of a half-built thing is real; the remedy is not to hide the ready parts as well, it is to make the first painted chunk make sense on its own. Hiding pays in a stretch of blank, and blank is read as slow, empty or broken. Painting first trades visible incompleteness for invisible completeness. In the loading family, visible incompleteness is usually more livable, because people can start rather than only watch wait chrome.

Where it stops holding

Results that must appear as an atom (a payment receipt, a signed legal text, a reconciliation figure) cannot paint half: the half becomes wrong data that can be screenshotted. If the first chunk is too small to say what page this is (a labelless tab bar alone), painting first has not moved cognitive work earlier — it is not a chunk yet. On a wait so short that swapping chunks itself flashes, a single arrival is cleaner. Content that is already complete locally has no “present first” problem; splitting it into chunks manufactures a fake arrival rhythm.

Applying it

• Split the page into independently finishable chunks. Paint shell and main column once they can orient; let media and secondary modules follow.
• Do not default to “wait until every API resolves”. Default to “this chunk’s data arrived, paint this chunk”.
• The first chunk must answer “where am I, is this what I wanted”. If it cannot, it is not ready to present.
• How to check: drag the slowest endpoint to five seconds. If the screen is still full-page wait chrome at five seconds while logs show title and navigation already returned, ready parts are being held hostage for unready ones.

Related

• Same group: I2.03.2 Later content must not shove what is already on screen · I2.03.3 Chunk order should follow importance
• Nearby: I2.11 Progressive rendering · I2.07 Perceived performance · I1.07 First versus steady-state response
• Search terms: chunked loading · first meaningful paint · show ready first