Progressive rendering must reserve space for chunks that have not arrived, or the layout will shift

What it is

Chunks arrive over time. If a chunk’s height in the document is still zero when it lands, words and buttons that had already settled are pushed apart: layout shift. Progressive rendering has to reserve a place for chunks that have not arrived — a known aspect ratio, a minimum height, or a skeleton slot — so later pixels fill a pit already taken, rather than digging the pit from zero to real size. “Must not shove” is the principle; reservation is how that principle is done under progressive rendering.

Why it happens

Layout computes coordinates from the tree as it is now. A block going from “absent” to “present and tall” forces every node below it to recompute; the line being read and the click target being aimed at move house with them. Reservation pulls “present” forward onto the geometry layer: a node or placeholder already participates in layout, it is just empty of content. Later bytes replace the inside of the placeholder; document-flow height does not change; recomputation need not happen, or happens only inside the slot.

Reservation needs size knowledge that predates the payload: an image’s ratio, a card’s minimum row height, a contracted ad size. Without it, reservation is inexact — too short still pushes, too tall collapses on arrival. Inexact reservation is still calmer than zero: collapse usually happens in unread bottom geometry; push happens in the middle people are already using. When ratio can be deduced from type (sixteen-by-nine video, avatar circle), reservation can be exact before data returns.

Where it stops holding

Blocks whose true height swings with content and that have no meaningful lower bound (comments of unknown length) can only reserve a minimum slot; arrival may still grow. Put those blocks below the already-read region so the shift happens in unused geometry. Height changes from the user expanding something are not progressive-render shift — the person is changing layout. If the reserved shape is nothing like the real content, fill still jumps inside the block, a cousin of a bounced skeleton; reservation only protected the neighbours. Print and export channels that must be a finished page should not treat reserved in-betweens as the final document.

Applying it

• For media and modules that will appear in the viewport over time, write an aspect ratio or minimum height from type at request time.
• Let the placeholder participate in layout. Do not insert a previously zero-space node when data arrives.
• Put unknown-height blocks after the main-task region, or in an inner scroller, so the shift is not delivered into the column being read.
• How to check: after the main column is readable, release a top image. Measure the primary button’s viewport coordinates; they should coincide before and after arrival. If they move, reservation was too small, or never happened.

Related

• Same group: I2.11.2 People may act before every chunk has arrived; those early actions have to be handled · I2.11.3 A presentation cadence that is too fast makes people think the content is complete and miss what still arrives · I2.11.4 Every step of chunked presentation should be a coherent usable state, not a half-built product
• Nearby: I2.03 Chunked loading · I2.01 Choosing skeleton versus spinner · I2.05 Lazy loading
• Search terms: layout shift · reserved slot · CLS progressive render