Chunk order should follow importance

What it is

Painting what is ready is not the same as painting whoever’s callback fired first. Network completion order is an engineering fact; presentation order is a product decision. Ordering by importance means: the chunk that contributes most to the task in progress belongs at the front of the presentation queue, even if it is not the fastest endpoint. Decoration, analytics and related recommendations can arrive later. If chunked loading paints “whoever returns”, bandwidth and the first glance both go to whichever secondary module happened to win the race.

Why it happens

The first glance is triage: is this the article I wanted, is the price right, is the primary action here. The information triage uses is almost always main column, title, key figure, primary button — rarely a footer subscribe box or a rail ad. If the rail arrives and paints first, working memory at first glance fills with secondary objects, and the main column has to be triaged again when it lands. Importance turns “ready” from a time predicate into a weighted one: ready and important earns the right to occupy early attention.

Importance is not simply visual weight. For reading, body beats a cover video; for purchase, price and stock beat brand story; for search, the result list beats “you might also look for”. The same chunk can flip weight across tasks, so order binds to the route’s task, not to a component library’s default z-order. Bandwidth is finite: pull important chunks first and make secondary ones yield, or “present first” will present the wrong thing.

Where it stops holding

Assistive reading order and keyboard focus order must not be broken into jumps onto nodes that do not exist yet because they were “visually unimportant”. Legal and safety information (fees, irreversible consequences) can outweigh the hero image for the decision even when it looks like a footnote — being drawn lower is not being secondary. When importance is unknown (first visit to a user-built home), follow a stable task default rather than a personalisation guess; a wrong guess spends the first glance on the wrong object. When media is huge and body is small, painting body first may leave the first screen looking empty; empty still fits this principle better than leading with a video no one can decide from.

Applying it

• For each major route, list what the first glance must contain (title, main column, primary action, key figure). Request and paint those chunks first.
• Put recommendations, comments, analytics scripts and below-fold images after that list. Even if their endpoints return faster, do not paint them into the first glance.
• Tie importance to the task. Detail and checkout each get their own list; do not share a “rail is always second”.
• How to check: open the page on a slow network and watch what appears in the first second. If the first glance is an ad or a recommendation while title and primary action are still missing, order followed arrival, not importance.

Related

• Same group: I2.03.1 Presenting what is already ready beats waiting for the whole · I2.03.2 Later content must not shove what is already on screen
• Nearby: I2.11 Progressive rendering · I2.05 Lazy loading · I2.04 Prefetch and preload
• Search terms: importance-based loading · priority of chunks · above-the-fold task