Placeholder flicker during a fast flick hurts readability
Aliases: blank rows · recycle flash · skeleton flicker
What it is
Rows outside the window are often unready in the frames when they scroll in: the node was just created, the image has not arrived, the text is still empty. On a fast flick the viewport flashes empty blocks, grey bars, or a leftover wrong row from the previous window. Placeholder flicker makes the row you are trying to read unreadable at the moment it is needed. It is not jank as such. It is the window’s fill strategy showing through at high scroll speed.
Why it happens
Virtualisation defers create work until a row nears the viewport. On a slow scroll, buffered rows are already built and the viewport stays full. On a fast flick, the window moves faster than create and data bind, and the viewport is briefly made of placeholders. Blank placeholders interrupt the scan. Recycled nodes that have not yet swapped data show a few frames of the wrong row, which is worse than blank, because the wrong content is read as real. Images and avatars are slower than text, so flicker is louder on pictures. Recycled nodes that keep an old selection or height also jump the layout for a frame. The readability failure happens during the scroll; at rest the list may already look fine — so a still-state check is not enough.
Studying it
Drive a programmatic fast flick through a long list and count, frame by frame, blank, wrong-row, and stale-selection frames in the viewport. Independent variables: buffer rows, whether text binds synchronously, delayed images, whether recycle resets state. Dependent variables: share of unreadable frames, times wrong rows are reported as real content. A human task: stop mid-flick and immediately name the current row, scored against placeholder or wrong-row speech.
Where it stops holding
Very slow, precise scrolling barely flickers. On a low-end device or a busy main thread, even a buffer will flicker; shrink the window or degrade images. “Loading the next page” at the bottom of infinite load is not placeholder flicker — the data are not there yet. Window flicker is data present, view not ready. Print and screenshots that hit uncreated rows go blank on the export channel, which is the same unreadiness.
Applying it
- Size the buffer for the fastest expected flick. Fill text before a row enters the viewport; do not wait for images.
- On recycle, clear old text, images, selection, and height.
- Placeholders should be stable pale blocks, not the previous row’s words.
- How to check: on a real device, flick hard and stop; read the current row at once. Blank, or someone else’s name, means grow the buffer and inspect recycle reset.
Related
- Within the group: E4.18.1 Virtualized lists render only what is on screen so long lists stay usable · E4.18.2 In-page find can fail under virtualisation · E4.18.3 The scrollbar’s position must map honestly to the real amount of data
- Adjacent: E6.07 Skeleton screens · E4.02 List items
- Search terms:
placeholder flicker·view recycling·scroll jank