How to optimize complex svelte components for faster loading ?

[ananduremanan]

Hi Community,

I'm new to Svelte, and I built a data grid with Svelte. It handles certain complex operations, and I just realized it may have linear complexity if the data source is large (Initial Data Loading: O(n), Filtering/Searching: O(n), Pagination Calculation: O(1), and so on). I wonder if there are any ways to optimize it to render super fast, or if there are any best practices I should follow. I'm also sharing the code for more context.

Sample Code

Thanks

[brunnerh]

I don't think there is much you can do about the basic operations. Regarding the data handling, some data grids allow doing most work on the server (or by extension the DB) and only ever send the current page to the client.

One of the most common UI optimizations is virtualization. This entails only creating the elements that are currently in view; you can also potentially reuse old elements for newly visible items.

This is a fairly involved process, though, especially if items should be allowed to have variable sizes. It can also involve more direct DOM interaction which has to happen outside the regular Svelte syntax.

[ananduremanan]

How hard is to implementing virtualization? I'm dealing with items of variable sizes(data source for grid) , does it make complex? I've no idea about virtualization in svelte though.

[brunnerh]

I would say it's pretty hard, have not seen a decent implementation that handles variable sizes either.

[jnehlmeier]

I have written such a fast view once in GWT (Java -> JS compiler) and you get the best UX if the scrollbar has the correct size. To achieve this you have to know the total height of all items/rows without rendering them which is only possible if you have fixed sized items/rows.

That does not mean that all items/rows must have the same size but you need to know which type of item/row has which fixed size. E.g. a data row has always height 20px and a headline row has always a height of 30px. So you could store the fixed height on the item itself if you have many different types of items. If you have this information you can calculate the total height of the container element that holds all your items/rows which will then result in a correct scollbar. Finally you can use the item/row size information to position visible items in the container element using position: absolute; top: ....

It took a few attempts to get it right but at the end the list was very fast, even in IE 6 (which was the primary reason to write such a view back in the days).

I think it was O(n * log n) for adding n items to the list view (with only a subset being rendered right away) because the add operation also updated a sorted map that kept track of an items top position and item index. This map was then used during scroll operations to quickly retrieve the start/end item index for a given scroll position. The start/end index information has then been used to render the visible subset.

If you don't have fixed height information per item you automatically loose performance because you need to render the item first. Thats why the classic "load more" lists/tables exist or you use pagination and only load pages of data from the server (including filtering on the server).

[samal-rasmussen]

There are table components for Svelte that try to squeeze out the max possible performance. See e.g. https://svelte-headless-table.bryanmylee.com/

One of the limitations of Svelte 4 that they are addressing with Svelte 5 is the ability to do fine grained updates in #each blocks. Currently Svelte 4 has to rerun the whole loop to update a single item, but Svelte 5 should update just exactly the items that have changed. So performance with updating lists of stuff should become much better in Svelte 5.

[ananduremanan]

Svelte Headless Table looks promising, Thanks for the suggestion.

[samal-rasmussen]

I haven't used it and it looks complex to me... If I needed to do some super complex and performance sensitive table I think I would just go with vanilla js ag-grid (though I haven't used that either 😅) https://www.ag-grid.com/javascript-data-grid/getting-started/

[brunnerh]

I have integrated ag-grid into a Svelte application before, it's pretty good.

[ananduremanan]

Actually, we’re building a component library for our internal workflows and planning to set up a micro frontend architecture with Svelte and React. Our actual workflows are much more complex than this grid. For React, we’ve already built a grid on top of Syncfusion’s EJ2 Grid component, but the problem with Syncfusion’s grid is that it offers less control. Also, our proposed architecture seems more efficient with Svelte and React. I proposed this idea, so I need to make it efficient and performant. Most of the data grids out there lacks some of the features we really want and hence decided to built our own. Anyway thanks for replying though 🤓

[samal-rasmussen]

Here's another new Svelte 5 table component that looks promising: https://github.com/WJSoftware/wjfe-dataview