Combobox causes sluggish UI with large number of items

[fiadliel]

Current Behavior

If the combobox is initialized with a large number of items (e.g. 10000), it causes very laggy page responsiveness, due to a large number of buttons in the DOM.

Since the filtering and rendering is done in skeleton rather than Zag, this seems to be an issue to be handled in skeleton.

Expected Behavior

By default (and maybe it can be customizable), set a reasonable maximum number of nodes to be rendered. The options array can be just sliced to this length before looping through items to render the menu. I'm using 50 here, but I suspect in most cases, more than that isn't very useful.

An alternative is to have the ability to pass a custom filter, e.g. #3328 - but a fix for this issue doesn't necessarily have to go so far.

Steps To Reproduce

1. Using the combobox from https://www.skeleton.dev/docs/integrations/popover/svelte#combobox
2. Create a combobox with a large number of items (10000+)
3. See that the page is laggy when rendered, until the items are filtered down to a smaller subset

Link to Reproduction / Stackblitz

https://stackblitz.com/edit/sluggish-ui-combobox

Environment Information

System:
OS: macOS 15.5
CPU: (16) arm64 Apple M4 Max
Memory: 538.75 MB / 48.00 GB
Shell: 4.0.2 - /opt/homebrew/bin/fish
Binaries:
Node: 23.10.0 - ~/.local/share/mise/installs/node/23.10.0/bin/node
npm: 10.9.2 - ~/.local/share/mise/installs/node/23.10.0/bin/npm
pnpm: 10.11.1 - ~/.local/share/mise/installs/pnpm/10.11.1/pnpm
bun: 1.2.15 - ~/.local/share/mise/installs/bun/1.2.15/bin/bun
Watchman: 2025.05.26.00 - /opt/homebrew/bin/watchman
Browsers:
Chrome: 137.0.7151.69
Safari: 18.5
npmPackages:
@skeletonlabs/skeleton: ^3.1.3 => 3.1.3
@skeletonlabs/skeleton-svelte: ^1.2.2 => 1.2.3

More Information

No response

[endigo9740]

Just wanted to correct a couple things here:

If the combobox is initialized with a large number of items (e.g. 10000), it causes very laggy page responsiveness, due to a large number of buttons in the DOM.

This is not surprising at all, as this is well beyond the number of items we would reasonably expect to be fed to this type of component. As such, this is not unexpected behavior (a bug) but rather a feature you wish for this component to support (a feature request) so I've updated the status accordingly.

Since the filtering and rendering is done in skeleton rather than Zag, this seems to be an issue to be handled in skeleton.

Correct. Filtering occurs within the component, but it follows the foundation established by Zag:

• Zag: https://zagjs.com/components/svelte/combobox#usage
• Skeleton: https://github.com/skeletonlabs/skeleton/blob/main/packages/skeleton-svelte/src/components/Combobox/Combobox.svelte#L68

Our status quo is to follow Zag as closely as possible to help prevent new issues being introduced inadvertently. The biggest concern always being accessibility.

An alternative is to have the ability to pass a custom filter, e.g. #3328 - but a fix for this issue doesn't necessarily have to go so far.

We understand there will be scenarios where folks wish to search through excessive amounts of items, even if that has UX implications (this will likely overload many users). But the custom filtering is a part of the solution to enable this behavior. I would still personally recommend you evaluate your interface to determine if there's a better way to solve this.

Also note we don't intend to support this component indefinitely. Only until Floating UI Svelte is available, which will provide more primitives for popovers. As such perhaps this might be one of features you should divest away from Skeleton asap. Build a custom component with performance for handling large numbers of items. You may also even be able to address UX concerns in conjunction with this.

[fiadliel]

Thanks for the comprehensive reply. I've already copied and slightly modified the component for now, so I'm not blocked in any way on this. And will consider other options in the future.

So if you consider this request to be out of scope, feel free to close it now.

[endigo9740]

All good, just wanted to set expectations here. You're not the first to request support for handling large amounts of items, and of course we always want to optimize for performance where we can, so I think we'll keep this.

But please do consider if users are able to reasonably manage that many items. At least from what I can imagine it seems very overwhelming.