Post page: rendered article is duplicated in the RSC payload (11 KB) — inherent to dangerouslySetInnerHTML, not the NSFW wrapper

[feruzm]

Every post page serializes the rendered article HTML into the RSC flight payload in addition to painting it in the SSR HTML. Measured on a live 4 KB post: the rendered body is a hoisted flight text row ($4f, 11,044 B) referenced from a dangerouslySetInnerHTML.__html prop. Nothing on the client reads it — EntryPageBodyViewer only enhances the SSR-painted #post-body.

Why it crosses the boundary

EntryPageStaticBody is a server component, but entry-page-content-ssr.tsx renders it inside EntryPageNsfwBodyWrapper, which is "use client":

<EntryPageNsfwBodyWrapper entry={entry}>          // "use client"
  ...
  <EntryPageStaticBody entry={entry} />            // server, dangerouslySetInnerHTML

Server subtrees passed as children through a client boundary get their element props serialized to the client. __html is an element prop, so the whole rendered article ships. Confirmed in the live payload:

3f:["$","$L4d",null,{"entry":"$1e:...","children":[... {"id":"post-body", "dangerouslySetInnerHTML":{"__html":"$4f"}} ...

Why the wrapper is a client component at all

It gates the body behind an NSFW warning, and the reveal is a real click (setShowIfNsfw(true)), so the gate must stay client-side for NSFW posts. But its predicate is only

Array.isArray(entry.json_metadata?.tags) && entry.json_metadata.tags.includes("nsfw")

For the ~99% of posts that are not tagged nsfw, the wrapper does nothing except force the article through a client boundary.

Proposal

Evaluate that same predicate on the server, and only wrap in the client gate when it is true. Non-NSFW posts render the static body directly in the server tree, so __html never enters the flight payload. NSFW posts keep exactly today's behaviour.

Two things this deliberately does not do:

• It does not switch to isNsfwEntry(). That helper is broader (NSFW communities, title stems) than the wrapper's literal-tag check. Using it would start gating DPorn-community posts that carry no nsfw tag — a behaviour change worth considering, but a separate decision, not one to smuggle into a byte optimisation.
• It does not touch the raw-markdown copy in the dehydrated entry ($32, 4.3 KB). That has six real client consumers including the reply/edit editor (comment/index.tsx does setText(entry.body)), so it needs an on-demand fetch pattern and its own PR.

Size

~11 KB per post page for the rendered article, plus the wrapper's own client-boundary overhead. This is the second of the page-weight items from #1533; the crawl-budget theory there is still a correlate, not a proven cause, but this is a free byte reduction with no feature cost either way.

[feruzm]

Correction to this issue's premise, from measuring the real Flight payload (details on #1539).

The article HTML is in the RSC payload not because it passes through the NSFW client wrapper. A copy rendered as a plain server <div> at the page root — outside HydrationBoundary, outside every client boundary — still landed in Flight as an identical 11,044 B row. In the App Router the RSC payload is the serialized server element tree, so a dangerouslySetInnerHTML prop ships in it by construction.

So the ~11 KB is inherent to rendering the body via dangerouslySetInnerHTML inside React's tree, and boundary restructuring cannot remove it. The real options are:

1. Accept it as the cost of SSR-with-hydration for a body React must be able to reconcile.
2. Render the article outside React's tree — e.g. emit it as raw HTML in the stream and have the client enhancer attach to it by id — so it is never a React element prop. That is a substantial change to how #post-body is produced and hydrated, and it interacts with everything that currently enhances that element client-side.

Neither is a wrapper move. Re-titling this to reflect what was actually learned; the NSFW-gate change on #1539 stands on its own as tree hygiene only.