Large collection display in CP delayed by debugbar

[efc]

Bug description

When migrating a site from v5 to v6 I found that all collection lists were displaying more slowly in v6.3.1 Control Panel than they did in v5. But the delay is much more noticeable in my largest collection. For example, my collection of 14 pages has a roughly 3 second delay when loading. But my 790 item posts collection has a 30 second delay when loading. The delay is much more apparent in some browsers (Arc/Chromium) than in others (Safari, where the delay is only about 8 seconds for the larger collection).

I've found that if I turn off the debugbar with DEBUGBAR_ENABLED=false in the .env file, then the large delay disappears.

How to reproduce

I timed these delays by making sure each collection was in the simple list view (not ordered) with the search field visible. Then I would reload the collection list and immediately type the letter "h" to filter the list to only entries with "h" in them. Then I timed how long it took for the list to reflect the search filter. In Statamic v5 this is almost instantaneous, even with debugbar enabled. In Statamic v6.3.1 I could count seconds to tens of seconds for the list to update properly.

Logs

I do see the following errors in the log when loading collection lists, but these do not seem to be related and persist even when the debugbar is disabled.

[Error] Failed to load resource: the server responded with a status of 500 () (js, line 0)
[Error] Unhandled Promise Rejection: AxiosError: Request failed with status code 500
	(anonymous function) (index-BO_-65kq.js:61:1294)

Environment

Environment
Application Name: Statamic
Laravel Version: 12.51.0
PHP Version: 8.3.30
Composer Version: 2.9.5
Environment: local
Debug Mode: ENABLED
URL: /
Maintenance Mode: OFF
Timezone: UTC
Locale: en

Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED

Drivers
Broadcasting: log
Cache: file
Database: sqlite
Logs: stack / single
Mail: log
Queue: sync
Session: file

Storage
public/storage: NOT LINKED

Statamic
Addons: 1
Sites: 1
Stache Watcher: Enabled (auto)
Static Caching: Disabled
Version: 6.3.1 Solo

Statamic Addons
statamic/ssg: 4.0.0

Installation

Other (please explain)

This work was done on a site that was upgraded from v5 to v6, but all addons have been stripped out except SSG.

Additional details

This may be related to #13385 which notes a similar issue with replicators. That discussion points to an upstream issue (unovue/reka-ui#1974) which may be impacting Vue components. Whatever it is, it makes some collections unusably slow to display in the Statamic CP when the debugbar is present Some browsers are impacted more heavily than others.

[jackmcdade]

One important thing to note: the Debugbar is inherently expensive. Its whole purpose is to collect detailed runtime information, which means it adds measurable overhead to every request. It’s designed to be enabled temporarily while debugging — not left on during normal usage.

In v6 especially, there are significantly more nested JavaScript components compared to v5. The Debugbar injects hooks and instrumentation into those components, so the overhead can compound quickly. That alone can account for noticeable slowdowns.

If performance improves when the Debugbar is disabled, that strongly suggests the bottleneck is instrumentation rather than the core runtime. That said, if it’s exposing something we can meaningfully optimize, we’re absolutely going to investigate further.