⚡️ Performance improvement: minimize Layout, Update Layout Tree, Recalculate Style

[codingedgar]

First of all, fantastic library ✨

Second, this is not a bug. I guess more of a performance improvement, fully available to contribute tho 👍.

Describe the bug
Currently, mounting Virtuoso causes a lot of layout/reflow (for more information here is a list of what forces layout/reflow)

I used contain to minimize the Layout / Reflow effect, to realize the event listeners resize/scroll are added to the window and not to a ref inside the Virtuoso tree, rendering contain useless.

There's also the use of both ResizeObserver and resize event listeners. It would be an improvement to figure out how to use only ResizeObserver if possible (I assume there's a pretty good reason to use both).

I also happen to have multiple Virtuoso instances, so sharing the ResizeObserver could be another good improvement, being by providing one externally or using a third-party library to use the same instance indirectly like @react-hook/resize-observer

Reproduction
Any environment with Virtuoso would do. (But I can make an example if required)

To Reproduce
Steps to reproduce the behaviour:

1. Go to any env with Virtuoso
2. Take a snapshot with the Performance inspector in the Chrome Dev Tools
3. See all the Layout / Reflow

Expected behavior

• use only ResizeObserver.
• use only one ResizeObserver for an instance of Virtuoso.
• use only one ResizeObserver for all instances of Virtuoso.
• add events listeners to children of Virtuoso.

Screenshots
I will add them ASAP

Desktop (please complete the following information):

• OS: All
• Browser: chrome

Additional context
I have a pretty crowded UI, with a side pane that mounts Virtuoso in the middle of an animation, where any Layout / Reflow degrades the performance of the animation tremendously, dropping FPS to 7.

Maybe this is a bit extreme, but in my wildest dreams, I aim to mount a Virtuoso component the closest to read-only mode causing 0 Layout / Reflow and enabling its full capabilities later.

[petyosi]

I'm more than happy to accept a performance-improvement PR on the matter. Few notes that might help:

Measuring element dimensions and tracking scroll location is how the dynamic heights work - and this triggers a reflow. I am not seeing a possibility for a radical improvement here, but I would be delighted to be wrong.

• The library does not deal with window unless you're in window scrolling mode.
• Listening to resize is, again, specific to window scrolling mode.

Reducing the resize observer instances: In its regular setup, a component instance creates two: one for the viewport and one for tracking the item sizes. You can get additional ones if you have a Header or a Footer. Unless you have dozens of virtual lists resizing at the same time, chasing that optimization might not be worth it. Here's some interesting comment on the matter.

Some additional context: throughout the years, the Virtuoso list has found its niche for use cases like chat lists and feed lists, where people deal with the complexity of inverted scrolling, dynamic heights, items resizing, etc. Those scenarios usually don't involve more than one, maybe two, active scrollable containers at any given moment. I am very hesitant to restructure the size measuring setup (one of the most complex parts of the code) unless it brings significant performance improvements even for a single instance.

[codingedgar]

Thank you for replying so quickly 🔥

I'm more than happy to accept a performance-improvement PR on the matter. Few notes that might help:

Thanks, I'll do my best.

At a glance, I spotted one main performance issue, not sure how fixable it is or how wrong I'm; I'll start to get familiar with the code and make tests to check:

Several places make Layout calculations on useEffect or plain code instead of useLayoutEffect, useIsomorphicEffect or requestAnimationFrame.

These are a good read: https://blog.jakuba.net/request-animation-frame-and-use-effect-vs-use-layout-effect/, https://github.com/alexreardon/raf-schd and https://stackoverflow.com/a/44779316/9130688.

Again, I might be wrong on the impact of the performance gain or actual implementation requirements that need to make calculations outside an animation frame.

I assume SSR might be an issue, considering the use of useIsomorphicEffect and initialItemCount. On the other hand, if there are rendering/measurement issues, does the code always runs on the client? tbh, not familiar with today's SSR, so idk what I should consider.

---

Some additional context: throughout the years, the Virtuoso list has found its niche for use cases like chat lists and feed lists, where people deal with the complexity of inverted scrolling, dynamic heights, items resizing, etc. Those scenarios usually don't involve more than one, maybe two, active scrollable containers at any given moment.

I don't have dozens, just about 4, and the impact of adding each is significant, with 1 I see no issues, with 2 animations become flaky, 3-4 is a notable pause mounting.

I am very hesitant to restructure the size measuring setup (one of the most complex parts of the code) unless it brings significant performance improvements even for a single instance.

Hopefully, the when can bring enough improvement to not re-think the how, but I guess measurements like window. innerHeight inevitable will force Layout / Reflow on the whole window and not just the Virtuoso tree, making crowded UI's suffer, and impairing the contain optimization.

[codingedgar]

*Aso, I know the use of urx is to prevent the issues I mentioned, I just want to verify no measurement is out of place, and how to reduce measurement impact on mount, because they happen multiple times when mounting not just once, I want to know why and if it can be reduced by getting familiar with the code.

[petyosi]

Feel free to reach out if anything perplexes you. The contact with the DOM is in the hooks. You might not have to touch the reactive systems at all.

I have toyed with rAFs in reporting scroll positions and item sizes and ultimately removed them (check the git history). The UI became very sluggish and the list was turning blank when scrolling.

[petyosi]

@codingedgar let me know if you need any help with that or if there are any insights you already got.

[codingedgar]

Sorry for being idle, so far what I've found is Virtuoso measures at different instances on mount, which causes Layout / Reflow multiple times on mount.

I tried to implement the requestLayoutEffect in various parts including client code but honestly found no right place.

In userland what I did was trying to display 1 Virtuoso at a time. It does not matter the heaviness of the content, mounting multiple Virtuoso at the same time freezes the page for a few ms (noticeable specially in animations).

I think urx is doing it's job right, I wonder if there's anyway to force calculating the first render all in one sit. And how to conditionally add the window scroll listener only on full screen mode as that's a feature.