Description
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.