Slow entry-publish-form performance due to container-folder list #12009
Description
Bug description
We've encountered massive performance problems with the entry-publish-form component in our current project. We've got a slightly more complex blueprint, but nothing overly crazy. The most remarkable field (in this context) is a content_elements replicator with several sets, that each have something between 3 and 10 fields. Some of the sets have nested replicators (the usual accordion component etc.) or a bard field with some little extra sets. With a low amount of sets in content_elements, we didn't have much of a problem. However, as soon as it gets to about 10 or more, the performance seems to plummet, to the extend of waiting for 30sec+ to load the entry page (with 10-15% of that being server load, rest vue component) or sometimes not loading at all any more.
We eventually could track the most glaring problem down: when the meta data for the entry-publish-form is json_encoded and handed over to the vue component, this data also contains the actions for asset fields. Part of this is the moveAsset action, which – as part of its class – stores a full list of all possible folders in the respective container that I could move an asset to. Our relevant container has more than 10k folders, some deeply nested, with more expected to be added in the future. As this list is encoded and transmitted for every asset field of the entry, this sums up to a sizeable amount of characters. When trying to view the source code of an entry with ~25 content_elements, the browser just stops working because of too much code.
When disabling the loading of the folder list (by rebinding the moveAsset class with an extended custom class that simply returns an empty array for the list), even the most problematic pages immediately became usable again (4-6secs load time). We then realised that when opening the asset-editor through an assets field, the required data is loaded async again (but only once, thankfully :D). Therefore, to temporarily fix the problem, we're only loading the list when not in an entry-edit-view by checking the request path for {cp_route}/collections/{collection_handle}/entries. A bit hacky, but it works.
So, we would love to dump our hacky code and have a slightly more stable solution.
How to reproduce
Probably the easiest way is to create a fresh Statamic page, add a replicator to the default page blueprint with a set that has preferably 2-3 (or more) assets fields. Then modify Statamic\Actions\MoveAsset::fieldItems() by filling the $options array there with 10k random strings (each something between 20 and 60 chars). Then create a new page entry, add a set and upload some images and duplicate that set 1-2 dozen times. Hit refresh, performance should plummet.
Logs
Environment
Environment
Application Name: "My App"
Laravel Version: 11.45.1
PHP Version: 8.3.19
Composer Version: 2.8.5
Environment: local
Debug Mode: ENABLED
URL: localhost:8001
Maintenance Mode: OFF
Timezone: UTC
Locale: de
Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED
Drivers
Broadcasting: log
Cache: file
Database: pgsql
Logs: daily
Mail: log
Queue: database
Session: file
Statamic
Addons: 2
Sites: 1
Stache Watcher: Disabled
Static Caching: Disabled
Version: 5.61.0 PRO
Statamic Addons
statamic-rad-pack/typesense: 2.3.1
statamic/eloquent-driver: 4.30.0
Statamic Eloquent Driver
Asset Containers: eloquent
Assets: eloquent
Blueprints: file
Collection Trees: eloquent
Collections: file
Entries: eloquent
Fieldsets: file
Form Submissions: eloquent
Forms: file
Global Sets: file
Global Variables: file
Navigation Trees: eloquent
Navigations: file
Revisions: eloquent
Sites: file
Taxonomies: file
Terms: eloquent
Tokens: eloquentInstallation
Fresh statamic/statamic site via CLI
Additional details
No response