Hydration markers cause increase in document size

[khromov]

Describe the problem

The new hydration markers in Svelte 5 increases output size and causes messy HTML output. This leads to increased bandwidth and processing costs for the payloads.

Repro:
https://github.com/khromov/hydration-markers-sveltekit-repro

Run npm run build && npm preview

Increase in document size

We compare the HTML output of a short text formatted using the Stylizr library:

With gzip disabled, the document is 2.8KB

With gzip enabled, the document is 1.9KB.

We can compare it with a baseline where we removed the formatting, in this case gzip disabled is 2.3KB and gzip enabled is 1.8KB. It seems like gzip does remove the brunt of the additional size, but the size of the uncompressed payload is markedly increased by the hydration markers.

Messy HTML

Every time a formatting is applied a new component (technically Snippet) is added to the output. The result lead to very messy HTML output with hydration markers:

Describe the proposed solution

The components/snippets in the repro don't have any reactive props, it is just static text. If this case could be detected, perhaps hydration markers could be removed?

Importance

would make my life easier

[trueadm]

Is this the module where you say everything is static? https://github.com/khromov/hydration-markers-sveltekit-repro/blob/main/src/lib/Stylizr.svelte

This is tricky as the each block isn't static, and you're rendering snippets which would need additional metadata to determine if they're really static. It's possible we could optimise the snippet case when they're local, but if they're passed as props then that optimisation would get undone.

[khromov]

You are correct, it is static in the sense that we know the props will never change, but I can imagine it's hard to generalize this due to the nesting and passing of props.

I think any edge cases that could be optimized, would be a benefit, even if this particular example can't be.

[Rich-Harris]

One reason we need boundaries around components is that if you have this...

<A/> <B/> <C/>

...and those components are just text (or start/end with text, whether static or dynamic) the text nodes get 'glued together', and the comments prevent that.

Take this example. Notice that A.svelte and C.svelte both output something like this...

export default function A($$payload) {
    $$payload.out += `<!---->one`;
}

...because they can't know if their previous sibling ends with a text node. B.svelte doesn't need to worry about that because it starts with an element:

export default function B($$payload) {
    $$payload.out += `<span>two</span>`;
}

We could pass around some metadata ("your previous sibling ended with an element or a comment, you are free to skip your own leading comment if you were planning to add one") but that has its own costs that likely outweigh the cost of the comment itself.

In App.svelte we add comments after the components, so that they have something to anchor themselves to:

export default function App($$payload) {
    A($$payload, {});
    $$payload.out += `<!----> `;
    B($$payload, {});
    $$payload.out += `<!----> `;
    C($$payload, {});
    $$payload.out += `<!---->`;
}

it seems plausible that in some cases we could just use whatever nodes we have lying around, rather than inserting a comment. But not here, because without the comment nodes we again run the risk of text nodes being glued together.

tl;dr the comments are very cheap and it's not straightforward to get rid of them

[Ocean-OS]

Isn't there be a smaller marker that could be used? An empty HTML comment is 7 characters, which could add up quickly. Perhaps there could be a more concise way to make markers, like a non-functional void element tag?

[paoloricciuti]

Isn't there be a smaller marker that could be used? An empty HTML comment is 7 characters, which could add up quickly. Perhaps there could be a more concise way to make markers, like a non-functional void element tag?

I think that would still add an element to the Dom which is probably even worse than a couple of gzippable characters...also I just checked and an empty element <> would simply be a string for the dom

[Ocean-OS]

I think that would still add an element to the Dom which is probably even worse than a couple of gzippable characters...also I just checked and an empty element <> would simply be a string for the dom

Perhaps the indices where the markers should be in the text could be saved in an array?

[trueadm]

<!> is the shortest comment you can make, and we tried that in the alpha Svelte 5. However, people complained it broke their HTML parsers so we had to revert to a standard comment. We can't use anything other than a comment either unfortunately.

[Kapsonfire]

AFAIK this is only a problem on SSR and how are there servers/clients in wildness without gzip?
IMO this isnt a big issue

[bertybot]

Thanks everyone for the great explanation of the process behind this and why it was made this way. @Rich-Harris explanation helped me better understand the why of this, But now I am just curious. Are text nodes the only reason for this or are there more situations that made this solution necessary? Was this solution made for all components with no root elements where the component barrier is less clear? or is it exclusively for situations like text where the 2 components would be stuck together making hydration impossible?

[Ocean-OS]

Are text nodes the only reason for this or are there more situations that made this solution necessary?

Another reason for this is that most of Svelte's core features, such as components and logic blocks, rely on an anchor, or a node that the rendered content will be inserted before. This anchor is sometimes comments if there's no other option (such as elements directly after the desired location). The reason these rely on anchors rather than a target (a parent node in which content is appended) is because that would always place the most recently appended content at the end of the child nodes.

[Conduitry]

Closing this in favor of #15200.