A server-rendered route's document doubled in size while its visible output barely changed - how do you find and shrink what is in the payload?
answer
- the payload mirrors the load, not the render
- unrendered fields still cost bytes
- diff payload keys against the screen
- project at the boundary, then budget it
basics
~20 sThe embedded payload mirrors what the route's server-side data step returned, not what it rendered. Extract the block, compare its fields against what the page shows, and project at the boundary so only rendered or interaction-critical fields cross.
solid answer
~50 sStart from the mechanism: the serialized block carries what the route **loaded**, not what it **displayed**. So a change that adds two visible fields can add whole records, because the read behind it now returns every column, or pulls a joined relation along, or fetches a full collection that the render then slices. I would split the document into markup and payload, extract the block, and list its keys and row counts against what the page actually renders - fields present in the payload and absent from the screen are pure cost. The fix is projection at the boundary: return a shape built for the route rather than the record the data layer happened to produce, paginate collections, and drop long text fields fetched to display a title. Then keep it honest with a per-route document-size budget in the build, because this regresses quietly.
go deeper
Remember the rule of thumb: the data block carries what the route loaded, so a field nobody can see on the page can still be costing bytes for every visitor.
Explain how to separate markup from the serialized block, read the block's keys and row counts, and connect a size jump back to the read that produced it.
Show the full loop: measure uncompressed, diff payload fields against the render, project at the boundary, and land a per-route size budget so the regression is caught next time.
Decide where projection is worth its maintenance cost. Mapping layers are real overhead, so govern list and detail routes tightly and let small routes hand data over directly.
## Why the number moved at all The serialized block in a server-rendered document is not a summary of the page. It is a copy of the **data the route's server-side step handed to the render**. Nothing filters it down to what was displayed, because the client may need any of it after hydration. That single fact explains almost every surprise here: a change that adds two visible fields can add several kilobytes per row, and a change that displays *less* can leave the payload identical. ## The usual causes - **The read returns every column.** A record with a dozen audit, moderation and internal fields crosses whole so that two of them can be printed. - **A relation came along.** Adding a field from a related record often pulls the entire related record, sometimes for every row in a list. - **The collection is not bounded.** The route loads everything and the render shows the first twenty; the other rows still cross. - **Long text rides free.** A body, description or serialized document fetched so that a title or a word count can be shown. - **The same object crosses repeatedly.** On a plain wire, a shared record referenced by many rows is duplicated once per row rather than pointed at. - **Precomputed derivations cross alongside their inputs.** Both the raw list and the aggregate it produced end up in the block. ## A diagnosis sequence 1. **Measure the whole document** for the route, before and after, uncompressed - compression will flatter repetitive data and hide the growth. 2. **Split the response** into rendered markup and the serialized block, and size each. If the markup is flat and the block grew, the data step is the suspect. 3. **Extract and parse the block**, then print its top-level keys, array lengths, and the per-row field names. 4. **Diff against the render.** List which fields appear anywhere on screen or are needed by an interactive part. The remainder is waste. 5. **Trace each surviving field back** to the read that produced it, and check whether the read or the hand-off is the thing that must change. 6. **Re-measure**, and record the number so the next regression is visible. ## Fixes, roughly by leverage | Fix | What it removes | Cost | |---|---|---| | Project into a route-shaped view model | Every unrendered field, permanently | A mapping layer to maintain | | Bound the collection - paginate or limit | Rows that were never going to be shown | Pagination in the interface | | Split heavy text out to its own request | The largest single contributor, usually | An extra round trip when it is actually opened | | Defer a heavy region behind a streamed boundary | Moves bytes off the first flush | Arrives later, needs a placeholder | | Send an identifier instead of an embedded record | Duplicated shared records | Client must resolve the reference | Projection is the one that lasts, because it changes what the route is *allowed* to load rather than trimming one instance. ## Why these bytes are not like bundle bytes A code chunk is shared across users and routes, cached for a long time, and roughly fixed in size. A payload block is **per render, often per user**, so it is far less cacheable; it scales with **rows times fields** rather than with features; and it is parsed on the main thread before the page becomes interactive. That is why a payload regression shows up in interactivity metrics on slow devices even when the network looks fine - the transfer was survivable and the parse was not. ## Framework variation, stated honestly How much of this you can control differs. Some frameworks serialize the whole route's data as one block; others serialize only what the interactive parts received, so an unrendered field that never reached one of them does not cross. Some support deferring part of the data so it streams after the shell. The diagnosis sequence above is the same in all of them, but the size of the win from projection depends on which model you are on - it is worth confirming rather than assuming. ## Keeping it fixed One cleanup does not hold. A document-size or payload-size budget per route, checked in the build and failing on regression, is what converts this from a recurring investigation into a caught mistake. Pair it with a review habit: when a read changes, ask what it now sends to the browser.
- Compression makes the payload small on the wire. Why still cut it?Repetitive data compresses well, so transfer understates the problem. The cost that survives compression is main-thread parse time and the retained memory of the decoded structure, both paid before the page is interactive and both worst on low-end devices. Measure uncompressed size to see what actually has to be parsed.
- Does deferring a heavy region behind a streamed boundary actually reduce the payload?It reduces what is on the first flush, not the total. The bytes still arrive and still get parsed, just after the shell, so first paint and early interactivity improve while total transfer does not. It is a scheduling fix, useful when the data is genuinely needed and genuinely secondary.
saying these in an interview costs you the question
- Assumes only rendered fields end up in the payload.
- Blames the markup for growth without splitting the document.
- Measures compressed size only and concludes there is no problem.
- Reaches for pagination when the real cost is a long text column.
- Treats one cleanup as the fix and adds no budget or check.