[Feature Request] Improve persisted client side rendering

[isBatak]

When restoring persisted panel layouts, there is currently a client-side layout shift between the server-rendered and hydrated states. This occurs because panel sizes are restored only after the client JS runs, rather than before the initial paint.

Proposal

If flexGrow were moved to a CSS variable, panel sizes could be restored before hydration.

Specifically:

• A small blocking inline script could read persisted panel sizes (from localStorage).
• The script would then set the CSS variable on the root element (e.g., --panel-flex-grow).
• The PanelGroup would render with the correct flex values immediately, preventing visual jumps.

This approach is somewhat similar to how react-wrap-balancer precomputes text balance client-side before hydration to avoid layout shifts.

@bvaughn What's your opinion on this approach?

[bvaughn]

That’s an interesting suggestion! Would you be willing to post a PR with a proof of concept implementations? I wonder if using a CSS var for this could enable avoiding re-renders in some cases too…

…

On Fri, Oct 17, 2025 at 9:33 AM Ivica Batinić ***@***.***> wrote: *isBatak* created an issue (bvaughn/react-resizable-panels#520) <#520> When restoring persisted panel layouts, there is currently a *client-side layout shift* between the server-rendered and hydrated states. This occurs because panel sizes are restored only after the client JS runs, rather than before the initial paint. *Proposal* If flexGrow <https://github.com/bvaughn/react-resizable-panels/blob/main/packages/react-resizable-panels/src/utils/computePanelFlexBoxStyle.ts#L39> were moved to a *CSS variable*, panel sizes could be restored *before hydration*. Specifically: - A small *blocking inline script* could read persisted panel sizes (from localStorage). - The script would then set the CSS variable on the root element (e.g., --panel-flex-grow). - The PanelGroup would render with the correct flex values *immediately*, preventing visual jumps. This approach is somewhat similar to how react-wrap-balancer <https://github.com/shuding/react-wrap-balancer/blob/68cb7e7615f7d7606d6423ba9e17176e3e58d0d4/src/index.tsx#L96C7-L96C26> precomputes text balance client-side before hydration to avoid layout shifts. @bvaughn <https://github.com/bvaughn> What's your opinion on this approach? — Reply to this email directly, view it on GitHub <#520>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAHHHOZYG2EASFUMUGVQOL3YDVZJAVCNFSM6AAAAACJPKRYJ6VHI2DSMVQWIX3LMV43ASLTON2WKOZTGUZDMMRQGUYTCOI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[isBatak]

Here is the PoC PR #521

I wonder if using a CSS var for this could enable avoiding re-renders in
some cases too…

Could you clarify which re-renders you’re referring to?

[bvaughn]

Currently, sizes are stored in React state, within the PanelGroup component– so changes in sizes requires re-rendering the PanelGroup. If sizing were in CSS, it might be interesting to consider if we could avoid that re-render (at least while a drag is active). This might turn out to cause bugs, or it might turn out not to even matter (since users often attach change handlers which themselves update state and trigger re-renders). Was just an idea.

[bvaughn]

Closing as completed in #528. 4.0 release should happen this week.

[bvaughn]

You might find this interesting! #572 (comment)

tl;dr the switch to use CSS variables for panel sizing caused a significant performance regression, so it has been backed out and replaced with inline styles as with version 3. Server-rendering/server components should still continue to work as before, without any layout shift. (I even added some e2e tests to guard against this regressing in #596).

[isBatak]

You might find this interesting! #572 (comment)

tl;dr the switch to use CSS variables for panel sizing caused a significant performance regression, so it has been backed out and replaced with inline styles as with version 3. Server-rendering/server components should still continue to work as before, without any layout shift. (I even added some e2e tests to guard against this regressing in #596).

Oh, I see. It’s kind of counter-intuitive that CSS variables have worse performance than inline styles 🫤
I went through the whole conversation, and I wonder how you profiled this issue.
I tried to make isolated examples of both implementations here:
https://stackblitz.com/edit/vitejs-vite-fgvgshwp?file=src%2FApp.tsx
and tried to profile them to determine the bottleneck.
Do you have any ideas on how to prove that CSS variables are the culprit?

[bvaughn]

Profiling was a nightmare. When I finally got access to a repro of sorts, Chrome’s Performance tab crashed 2 out of 3 times I tried profiling. Really it just came down to trying a bunch of things until eventually one seemed to work, then some Googling to confirm that the fix actually seemed plausible and wasn’t just a false positive. Definitely not the type of bug I enjoy hunting down 😂

…

On Mon, Jan 12, 2026 at 5:08 AM Ivica Batinić ***@***.***> wrote: *isBatak* left a comment (bvaughn/react-resizable-panels#520) <#520 (comment)> You might find this interesting! #572 (comment) <#572 (comment)> tl;dr the switch to use CSS variables for panel sizing caused a significant performance regression, so it has been backed out and replaced with inline styles as with version 3. Server-rendering/server components should still continue to work as before, without any layout shift. (I even added some e2e tests to guard against this regressing in #596 <#596>). Oh, I see. It’s kind of counter-intuitive that CSS variables have worse performance than inline styles 🫤 I went through the whole conversation, and I wonder how you profiled this issue. I tried to make isolated examples of both implementations here: https://stackblitz.com/edit/vitejs-vite-fgvgshwp?file=src%2FApp.tsx and tried to profile them to determine the bottleneck. Do you have any ideas on how to prove that CSS variables are the culprit? — Reply to this email directly, view it on GitHub <#520 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAHHHLSHFAJUJDLFYGP5XT4GNXB5AVCNFSM6AAAAACJPKRYJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMZXG43DQNBWGY> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>