Svelte v5 poor performance related to transition

[webJose]

Hello, everyone.

I distinctly remember Rich Harris mentioning Svelte v5 needed some work around animations. I wonder: Is the work pending performance-related? Because I am currently working in a data table component for Svelte v5 and adding the slide animation to a row element is clearly hurting the performance. It is very evident that clicking immediately after the animation plays is not happening immediately. Pretty much, user interaction. Scrolling, for example, is also not responding immediately after the animation.

Should I log this as a bug? Or is this something known (and probably related to what Rich hinted in the Release Candidate announcement Youtube video)?

[webJose]

Ok, I discovered the problem is not exclusive to transitions. It seems to be a more "general" mechanism because I can make the browser "freeze" the same way (unresponsive) by clicking the checkbox that I created to show/hide extra data multiple times in quick succession.

In both cases (the use of transition or the fast clicking), stopping interaction for a couple of seconds allow the browser to "catch up" (I am thinking) and then responsiveness comes back.

This is completely reproducible in the context of the data table control I am working on. I'll post a link to the repo as soon as I upload the branch.

[webJose]

This is the repository in question. I just merged the row expansion feature which is the subject of this discussion, so refer to main.

@wjfe/dataview

[webJose]

Interesting (at least to me): The performance problem seems to disappear when the demo page is published. Demo Page. So I suppose the problem only exists while running npm run dev.

Dev mode or deployed, it is much more performant to expand a row near the end (say, row 190) than it is to expand rows near the beginning. Could it be my fault? Are there any tricks I should know about to mitigate this? I started learning Svelte v5 only recently.

[brunnerh]

You generally should avoid animations that affect layout. This is not Svelte-specific.

If you change something high up in the page, the browser has to calculate new styles and layout of every following element that is affected by that. There are certain properties, like transform, that do not have this problem since the animation can happen in compositing (thus not affecting styles/layout at all).

[webJose]

Thanks for stopping by. I understand what you're saying. I just want to point out that the problem ended up not being related to the animation. I think the animation accents the problem, though.

Generally speaking, I would like to know if there are any tricks/best practices that I could learn and follow for this particular case: The row expansion feature cannot be helped in the sense that any row in the table could be expanded. Can performance be increased? We're currently not involving any animations. It is just the appearance of extra content in a row in the table.

[brunnerh]

If you want to keep the information under the expanded row, rather than showing it in a separate section of the page, there probably is not much you can do, it will trigger layout calculations at least once. (Which is still easier than trying to do this 60+ frames per second.)

Aside from showing the information elsewhere, reducing the complexity of the table, if possible, or the number of rows (e.g. via paging) can help.

[webJose]

After some more testing, I could not conclude the problem is Svelte. It may very well be as you say: Regardless of framework, expanding the first rows triggers more layout recalculation than expanding a row near the end of the table.