[Blazor] Avoid completely replacing the DOM when components are re-rendered after prerendering

[javiercn]

Right now, after prerendering we replace the entire contents of the prerendered component with a fresh DOM copy created from scratch. This has several bad side-effects like:

• Videos are stopped and restarted
• Animations can be retriggered
• The page can flicker if CSS is injected as part of the head contents.
• LCP score suffers because (even though there is no significant visual change in most cases) the tools detect the interactive DOM insertion as the LCP element.

Instead of replacing the contents of the DOM wholesale, we can do a best effort to reconciliate the DOM with the new rendered DOM when we are trying to apply the render batch.

In an ideal scenario, a developer should be able to produce exact prerenders, meaning that the render after prerendering is identical to the prerendered one.

In that case, the renderer would only need to "attach" event handlers to the appropriate nodes, leaving everything else the same.

The renderer does not have to be perfect and handle all possible scenarios, it can impose strict limitations and "bail out" if it can't figure out how to reconcile a given DOM subtree by replacing that node wholesale.

For example, the render can impose a strict order, suggesting that DOM children nodes in a given subtree must appear in the same order as the prerendered node (in other words, the renderer won't search for them, but iterate in order). A similar restriction might be imposed on attributes (which is not rare, since attributes are emitted in compilation order, except for splatting). Things like @key could be leveraged during prerendering too to offer a bit more flexibility in the ordering.

In general, this will likely result in a much higher node reuse and will give the developers the chance to always get this right.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[3hxx]

Yes yes yes. This is long overdue my guys 🙏😍😇

[aryehsilver]

Great to see this is finally being worked on. Let's hope it doesn't get pushed off any longer.

[fingers10]

You can refer ilovedotnet for this issue. The site is built from scratch using blazor wasm and the site also facing flicker issue when it gets loaded. The site has prerendering enabled during publish time in the pipeline. When the site loads the prerendered screen appears and when the blazor engine kicks in, there comes a flash and screen appears after that.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[kevon-vems]

Following

[oluatte]

Also interested in this. We're building a consumer facing web app & the flicker is very noticeable.

[rogihee]

This one hurts pretty badly with .NET 8 if you have SSR with any kind of interactivity somewhere

[andersme]

This one hurts pretty badly with .NET 8 if you have SSR with any kind of interactivity somewhere

Agreed. Without making this transition seamless, SSR is pretty useless right now. This is a must-have to compete with the competitors in the market.

[andersme]

This one hurts pretty badly with .NET 8 if you have SSR with any kind of interactivity somewhere

Agreed. Without making this transition seamless, SSR is pretty useless right now. This is a must-have to compete with the competitors in the market.

And now I've simply replaced the WebAssembly interactivity with HTMX. What a cobbled mess Blazor has become.