-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Excessive hydration markers on Svelte 5 #15200
Comments
👋 Thanks for making a reproduction. Have you tried comparing the size of the gzipped output between having the hydration markers and not having them? From my testing, gzip removes >90% of the extra size that hydration markers add. So while unsightly, it does not lead to increased payload size over the network. |
The unfortunate limitation we're dealing with, is not the size over the wire — it's that our Android and iOS native applications have limited quotas for the final payload. We inline the HTML bodies of our interactive within a native webview context, which has some strict legacy inline size limitations. Linked resources and network size don't matter, in this case. For what it's worth, I think what we're hoping to understand is how and why hydration markers are generated; it seems that something about the way that we author our components and application structure is creating more than would be typical. |
We can definetly shrink this down I think. In your case you're getting a lot of markers from the if-else-if block chains, I'm currently investigating shrinking this down to two nodes per if block, regardless of how many else-if branches it has. |
I also wonder if we could collapse repeated comments, like instead of this... <!---->
<!---->
<!--]-->
<!--]-->
<!--]-->
<!--]-->
<!--]-->
<!--]-->
<!--]-->
<!--]-->
<!--]-->
<!--[!-->
<!--[!-->
<!--[!-->
<!--[!-->
<!--[!-->
<!--[!-->
<!--[!-->
<!--[!-->
<!--[!-->
<!--[!-->
<!--[-->
<!--[-->
<!--[!--> ...maybe we could do this: <!--2-->
<!--9]-->
<!--10[!-->
<!--2[-->
<!--[!--> Need to be mindful of whitespace, of course. |
are the comments only viable option? I was thinking of data-attributes on nodes..that would be a bit "cleaner" |
there might not be an element since a component could be text only for example...but also that would not solve the size problem since |
You can improve dev experience by disabling HTML comments in the Chrome browser. I am not sure if Firefox has that option |
It seems like the issue has been identifed , but to just add that we are getting a TON too. And it must be from this and a few other things. If you needed another example for test cases. <DefaultLayout>
{#if banner}
<slot name="banner">
<Banner {banner} />
</slot>
{/if}
{#if header}
<slot name="header">
<Header />
</slot>
{/if}
<main class="{cls}">
{#key $page.url}
<slot name="hero">
<PageHero />
</slot>
{/key}
<slot />
</main>
{#if sidebar}
<slot name="aside">
<aside>
<Sidebar />
</aside>
</slot>
{/if}
<slot name="shin">
</slot>
{#if footer}
<slot name="footer">
<Footer />
</slot>
{/if}
</DefaultLayout> |
Describe the bug
After updating our template to Svelte 5 we are seeing an excessive amount of hydration markers, way more than in a default SvelteKit project. Our CMS has a hard limit on the size of the HTML strings — before gzip — and with so many markers it is easy to surpass it and be blocked from publishing. With adapter-static, a minimal Svelte 4 HTML payload is 5.7kb. With the same code, a Svelte 5 payload is 6.8kb, an increase of 18%. This change also makes debugging on the browser inspector very difficult.
We observe roughly 25 hydration markers between each node. In a baseline SvelteKit project (https://stackblitz.com/edit/sveltejs-kit-template-default-9a5meubq?description=The%20default%20SvelteKit%20template,%20generated%20with%20create-svelte&file=README.md&title=SvelteKit%20Default%20Template) we only see one marker between each component.
We understand that the hydration markers are part of the built output, as described in #14004 and #14099, but we believe there is something in how we’re rendering our components that is increasing the number of markers to a zany level, and we would be grateful if you could provide any suggestions or guidance on how to mitigate the issue.
At the moment, given the nature of our downstream consumers (iOS and Android applications), this is a blocker for us for moving to Svelte 5 at The New York Times. We’d be open to any suggestions on how best to approach!
Reproduction
Our current approach
Our template works with a body loop. The data comes from an external source and when the type matches a component, it renders. We also have a special component that imports and renders a component declared on a prop (saves you from importing it manually and adding it to the body loop), and it's imported using a +page.js file.
It looks roughly like this:
Here's a sample REPL with a small test case where you can see the proliferation of markers. Our template is far more complex and has lots of components (and components inside components), but this illustrates the basic problem:
https://stackblitz.com/edit/sveltejs-kit-template-default-py8cc6sm?file=src%2Froutes%2F%2Bpage.svelte
Dynamic body loop
We also tried switching to a "dynamic" body loop that uses
<svelte:component>
to render every element based on an object. We thought this would reduce the markers since there are only two pairs of ifs in the loop. After testing, it does reduce the markers but it is still problematic. We are seeing ~10 markers between each node, which unfortunately it's not really usable either.https://stackblitz.com/edit/sveltejs-kit-template-default-py8cc6sm?file=src%2Flib%2FNav%2Findex.svelte,src%2Froutes%2F%2Bpage.svelte,src%2Froutes%2Fdynamic%2F%2Bpage.svelte
The data that renders this looks like this:
Logs
System Info
Severity
blocking an upgrade
The text was updated successfully, but these errors were encountered: