Repository navigation
Performance for large Replicators, Relationships and Conditional fields #13385
Description
Bug description
This has been a little issue in Statamic 5, but with my testing, it feels more obvious in Statamic 6 - maybe it is the Inertia side of things (and the progress bar at the top) that makes it more obvious.
One use case for Statamic is to have a Replicator fieldtype that is block-level page builder. Each block could have many different types of fields: Bard, Text, Select, Entry, Asset... and also have conditionals within them.
When you have many blocks (i.e. over a dozen), page loads start to crawl. The server-side request is fast - but it is the rendering in the JS side of things, specifically around:
- rendering a Bard field (if Set is expanded)
- rendering the preview of a Bard field (if Set is collapsed)
- conditional fields
If I just hit refresh on the page, and the Replicator is fully expanded (so all Sets are shown) there is a noticeable delay while the Bard field renders.
If the Replicator is fully collapsed (all Sets hidden), there is still a noticeable delay, but it is the appearance of the Preview of the Bard content in the header.
In this example there are also numerous Conditional fields in play, and IIRC this was a bit of a JS bottleneck in the past because of the level of computation.
Add in fields like Entry which call relationships, if you've got one of these per block, and 10 blocks, that's 10 relationships calls that get fired at once. Make that multiple fields that need lookups - Entry, Asset, etc - that number of calls can increase phenomenally. 10 blocks, each with an Entry and an Image, that now is 20 calls. Add more Sets in the Bard content, and even more calls are made.
And oddly, they sometimes then get called a second time during the page load - there's a load of data, load of relationships, then relationships can get called again.
What compounds it further is that each request is actually doing the same thing. With 10 blocks in your Replicator, each with an Entry fieldtype, each of the 10 relationships calls is pulling the list of options for that field to display. In this instance, each of the 10 calls returns an identical response - so 9 of those 10 calls are actually not needed at all.
I'm not sure if there is a way to hook in to these load requests, and create a bulk approach to loading relationships and data - especially on initial page load. This would have a massive impact on initial page response times and server load.
After an Entry is loaded, doing calls one-by-one (such as if you add a new Set) is totally expected and while it still hits the server, has a smaller scope of impact.
The real giveaway is that the page loads and renders its initial layout, and Inertia is finished, but the browser tab is still loading and shows that in its loading icon.
If you open Dev Tools, it amplifies the issue, and I've had it completely hang the browser (i.e. the script timeout bar on the browser appears).
I have a basic repo that demonstrates the issue... but in a full-blown site I've been building with Statamic 6, it is incredibly noticeable on some pages.
I'm not sure what makes sense here - the repo... screen recordings of issues... happy to share both the repo and even the project (private repo only) to help see configurations in a real-world setup and the impact it can have. If you need private repo access, let me know who should have it (and note it's a WIP so is being changed day by day, but I can keep a great example of a poor page load intact).
How to reproduce
Statamic 6 Alpha 19
I have a leaner repo that shows the issue (but a bit harder to see), and a project that has much more noticeable issues (private repo). Access to both can be provided if needed.
Issue is present with zero addons installed on a clean install.
Logs
Environment
Environment
Application Name: Statamic
Laravel Version: 12.43.1
PHP Version: 8.4.15
Composer Version: 2.9.2
Environment: local
Debug Mode: ENABLED
URL: s6-plain.test
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: 0
Sites: 1
Stache Watcher: Enabled (auto)
Static Caching: Disabled
Version: 6.0.0-alpha.19 PROInstallation
Fresh statamic/statamic site via CLI
Additional details
No response
duncanmccleanWe've just tagged v6.40.0 which includes a handful of other performance improvements.
A lot of our recent focus has been around Bard, but these improvements should make Replicator fields slightly snappier too! The slowest remaining part in Bard & Replicator has to do with how field conditions are evaluated. We've experimented with a few things there, but there's not much we can do without either introducing breaking changes or risking data loss. We'll look into this more in Statamic 7.
Please let us know if things feel faster after upgrading! 🚀
Activity
duncanmcclean commentedon Dec 19, 2025
We're just about to finish for the year, but if you can give us access to the repo, we can take a look in the new year! 🙂
duncanmcclean commentedon Jan 5, 2026
I've just opened a PR (#13427) which aims to improve the initial page load for Bard & Replicator fields. Feel free to test it out and let me know if it helps.
That's strange... initial relationship data should be included in the fieldtype's meta to avoid requests when you load the page. 🤔
Just tested it myself - I have two entries fields (one at the top-level, another in a Replicator set) and I don't see any
relationshiprequests when I refresh the page:CleanShot.2026-01-05.at.17.32.30.mp4
Not to say we don't have our own issues, but Reka UI (which powers a lot of our UI Components) is known to be a little laggier sometimes when Dev Tools is open: unovue/reka-ui#1974
I mentioned it in my previous comment (no worries if you missed it), but if you're able to give us access to both repos, we can take a closer look! 🙂
martyf commentedon Jan 11, 2026
Back from leave now. I've invited you to two repos.
Both have been updated to Alpha 21 and issues still persist.
For one, open up the "Perf test" entry - with dev tools open, you can see this makes 32 calls to
dataandrelationshipswhen this page loads.For the other, look at Pages > About (ID
3723db35-76eb-4945-b317-84ab2c9946b8). This has been my dev playground where I've been building blocks. You'll notice this has 38 calls todataandrelationships.duncanmcclean commentedon Jan 12, 2026
I've just opened #13514 which addresses the requests issue (38 requests down to 2). That combined with #13427 hopefully makes things slightly better for you!
martyf commentedon Jan 12, 2026
The demo site is loading really nicely now - thanks Duncan, quite an improvement.
The other site, the actual project one, is still struggling - but I think it is more to do with the Video fieldtype being used.
This is sort of related but is there a way to make embedded content - such as any Video fieldtypes - be lazily loaded? In the site config, all sets are collapsed by default - so would be great if the video is not actually ever loaded unless the set is open.
It wouldn't resolve the issue if sets are expanded, but is an idea that could be expanded across more complex fieldtypes too.
duncanmcclean commentedon Jan 12, 2026
I noticed that as well. We don't have any way of lazy loading fieldtypes in general - but I bet we can figure something out for the Video fieldtype.
martyf commentedon Jan 12, 2026
Does that also mean that Bard fields are technically being rendered even when not shown? That could be another consideration for performance without needing to initialise all of the Bard fields (of collapsed sets) on load. The same logic extends to the TinyMCE Cloud fieldtype (not that I use it any more personally). But deferring the actual load of more complex fieldtypes (Bard, Video, third party like Tiny) could help minimise impact of page loads.
If that's possible, could be incredibly valuable to be able to hook in to for custom fieldtypes too.
jasonvarga commentedon Jan 13, 2026
Fields do need to be rendered, yes. The conditional field feature relies on it. e.g. if you have a field like bard that can have child fields, their fields need to be rendered in order for them to be included in the payloads. Otherwise you risk losing data.
If we can rework how conditional fields work, maybe we can avoid that - but it'd be a big undertaking.
martyf commentedon Jan 13, 2026
I wonder if the number of conditional fields I have in one of those repos is not helping too - will need to take out the YouTube videos and see if that helps with performance.
duncanmcclean commentedon Jan 13, 2026
I don't know that it makes much of an impact (performance wise), but I've just opened a PR to only load the video iframes when the field becomes visible. #13527
jonathan-bird commentedon Jan 19, 2026
Unsure if relevant here, but I found having Debugbar enabled causes significant front-end lag when loading a collection entry with complex blueprints. Do you use that @martyf ?
martyf commentedon Jan 19, 2026
Only if I actively need to look at something @jonathan-bird - otherwise it is disabled for that very reason.
[-][6.x] Performance for large Replicators, Relationships and Conditional fields[/-][+]Performance for large Replicators, Relationships and Conditional fields[/+]23 remaining items
duncanmcclean commentedon Aug 12, 2026
We've just opened a PR (#15158) which should hopefully fix most (if not, all) of the performance issues discussed here.
It includes some huge performance gains, but it's a pretty big code change. It combines work from #15057, as well as a bunch of other concepts and things we've done research on and decided to include.
In our initial testing, opening a page with a large Bard field w/ lots of sets is pretty close to instant.
The PR is still a work-in-progress so feel free to test it locally but definitely don't push it to production just yet. We still need to rigorously test everything ourselves, and it may still have some issues — possibly around field conditions and the preloading or deferring of collapsed sets.
If you're able to test it locally and give us feedback, that'd be great! ❤️
dryven-daniel commentedon Sep 24, 2026
Hi team,
Are there any updates on this issue or a timeline for a fix?
We are currently blocked from upgrading to the latest version of Statamic because of this. Our clients are starting to get quite impatient about the delayed update, so any guidance or temporary workaround would be highly appreciated.
Thank you for your help and great work on Statamic!
duncanmcclean commentedon Sep 24, 2026
We pulled some of the fixes from #15158 out into a couple of smaller PRs, which went out in v6.29.0. A few customers have told us they made a real difference to performance. It's not perfect yet, but it's a lot better.
We do want to roll out more of the fixes from #15158 over time. However, some of them introduce breaking changes or could lead to data loss, so we need to test them carefully first.
Have you had a chance to test since v6.29.0?
dryven-daniel commentedon Oct 9, 2026
@duncanmcclean Thank you!
Yes we tried it and it's a lot better. However, we have a dynamic page builder which allows quite flexible page layouts for editors. In most pages, there are many replicator items with bards in it. These bards are loading pretty slow, especially the toolbar with the formatting options on top.
o1y commentedon Oct 15, 2026
@duncanmcclean I tried it too, it's a bit better, but the overall performance is slower than V5, and our editors are noticing it too :/ The browser also still freezes sometimes when the live preview loads and when resizing the browser window. The slow Bard loading behavior is unchanged.
duncanmcclean commentedon Oct 29, 2026
We've been digging into this a little this afternoon, and a couple of recent changes should help:
:has()CSS selectors in the Control Panel. With lots of fields on the page, those were making every style recalculation in the browser really expensive. Thanks @o1y for that one!prosemirror-viewto 1.42.8 #15752 bumpsprosemirror-view, the library behind Bard. The newer version stops every Bard editor from forcing the browser to recalculate styles whenever its content changes, even when the editor isn't focused.Together, these make a big difference on our test site. They're both in v6.39.0, so give it a go and let us know if things feel any better. It's not the end of the road, but hopefully it's another step in the right direction!
dryven-daniel commentedon Nov 3, 2026
Had a quick look and it seems to be faster now, thank you for keeping this a priority!
duncanmcclean commentedon Nov 3, 2026
Glad to hear it. We've got some more improvements coming in the next release to make things even faster. 🚀
duncanmcclean commentedon Nov 3, 2026
We've just tagged v6.40.0 which includes a handful of other performance improvements.
A lot of our recent focus has been around Bard, but these improvements should make Replicator fields slightly snappier too! The slowest remaining part in Bard & Replicator has to do with how field conditions are evaluated. We've experimented with a few things there, but there's not much we can do without either introducing breaking changes or risking data loss. We'll look into this more in Statamic 7.
Please let us know if things feel faster after upgrading! 🚀
dryven-daniel commentedon Nov 3, 2026
Now we talkin'
Loads very snappy. Congrats guys!
martyf commentedon Nov 8, 2026
The initial page load request via Inertia (or full refresh) still can be quite slow - but the CP itself is not as laggy as it was, especially on really big and complex pages.