[BUG] Very large model lists cause >60 second UI freeze during startup

Author: EntSec01Created Sep 9, 2026Updated Sep 9, 2026
Labels🐛 Bug

Environment

Windows

System

Windows 11 Pro, Opera Chromium-based browser, Ryzen 5 7600X, 32 GB RAM

Version

1.18.0

Desktop Information

  • Node.js version 26.7.0
  • Generation API Featherless
  • Branch release
  • Model All

Describe the problem

When SillyTavern starts with Featherless selected as the API provider, the browser UI becomes completely unresponsive for over one minute after the backend has finished loading. Featherless currently supplies a very large model list. After startup, #model_custom_select contains 21,929

  • querySelectorAll: 43,926 ms self time (69.8% of the recording)
  • Approximately 35,183 ms (55.9%) follows the core SillyTavern call chain: MutationObserver → handleNodeChange() → initializeInteractables() → getAllInteractables() → querySelectorAll()
  • applyA11yRules() in a11y.js accounts for a further ~8.7 seconds. keyboard.js observes document.body for child additions and class changes. handleNodeChange() calls initializeInteractables(node), which calls getAllInteractables(node). getAllInteractables() then executes querySelectorAll() separately for each entry in interactableSelectors. With the very large Featherless model list, this appears to result in repeated expensive DOM scans while the UI is being constructed. As a control, I switched the connection to z.ai without disabling or changing any SillyTavern extensions. SillyTavern then loaded and became responsive in approximately one second. Steps to reproduce:
  1. Configure a Featherless connection with its full model list.
  2. Start/reload SillyTavern.
  3. Observe that the backend completes quickly but the browser UI remains unresponsive for over one minute.
  4. Profile startup in Chrome DevTools Performance.
  5. Switch to a provider with a much smaller model list (in my case z.ai) and reload; startup takes approximately one second. Expected result: A large provider model list should not cause the UI to remain unresponsive for over a minute. Actual result: The browser main thread is occupied primarily by repeated querySelectorAll() calls originating from the core keyboard.js MutationObserver handling.

Additional info

I have attached the exported Chrome Performance profile with resource content and script source maps included. I can provide screenshots of the Bottom-up profile and relevant DOM counts if useful.

Trace-20260909T122050.json.gz

Please tick the boxes

  • I have explained the issue clearly, and I included all relevant info
  • I have checked that this issue hasn't already been raised
  • I have checked the docs important
  • I confirm that my issue is not related to third-party content, unofficial extension or patch. If in doubt, check with a new user account and with extensions disabled