Hey @marpas
Thanks for the detailed performance analysis — that’s useful feedback which I have already been aware of.
The plugin does load bundle.js on all pages and pdf.min.js on pages where the ClaudeAI element is present. These resources are loaded asynchronously, which means they do not block HTML parsing or the initial render in the same way synchronous scripts do. The UI can paint while these files download, so the user can already see and interact with the page.
This significantly mitigates the impact on perceived user experience. In addition, once these files are cached on the user’s device, subsequent page loads incur minimal overhead because the browser retrieves them directly from cache rather than over the network.
That said, asynchronous loading does not eliminate their cost entirely. The scripts still add network transfer time on first load, and once downloaded, their parsing and execution occur on the main thread, which is why they appear in load-time measurements.
Regarding the loading strategy, I did explore an on-demand approach during development with the intention of loading these libraries only when the element was visible or actively used. In practice, this led to several issues.
These libraries expose global symbols that the plugin depends on, and when they were loaded dynamically, there was no reliable guarantee—within Bubble’s plugin environment—that these globals would be available by the time the plugin code needed them. This resulted in race conditions and unpredictable behavior, especially on pages with multiple element instances or quick visibility changes. Furthermore, Bubble does not provide the level of script-loading control needed to coordinate deferred loading in a fully reliable way.
Because these issues produced inconsistent behavior across devices, browsers, and loading scenarios, I chose the current approach. Loading the libraries up front ensures stable, predictable availability for all element instances, avoids timing issues, and benefits from caching after the first load.
This change isn’t planned in the short term, but I may revisit again the loading strategy in a future refactoring.
For now, the most practical mitigation is to include the element(s) only on pages where the functionality is actually needed.
by wise:able
Step 1: Set App Data Retrieval on the element
That’s it! Claude will now pull real-time data from your app whenever needed—making responses smarter, faster, and more accurate.
Remember: Set up your privacy rules to keep everything secure!
Search