We are seeking some advice and best practices for troubleshooting a significant performance issue one of our users is experiencing. Our Retool solution is quite large and has been modularized into several separate Retool applications. The primary issue is a long loading time, sometimes up to 10 seconds, when navigating from one app to another.
The Problem
When a user clicks a component (e.g., a button) configured with the "Open another Retool page" event handler, they experience a loading time of approximately 7-10 seconds before the destination app becomes interactive.
We've used Chrome DevTools to investigate, and for the affected user, we are seeing a Largest Contentful Paint (LCP) of around 7.7 seconds when loading a page that is essentially a large table view.
What We've Investigated So Far
We have compared the experience of two users, one user (who has the slow performance) and another (who has much better performance), to try and isolate the variable.
1. Hardware & OS: The hardware is nearly identical and should not be a bottleneck. Both users are on modern, high-performance laptops.
Processor: 12th Gen Intel(R) Core(TM) i7-1255U
RAM: 16.0 GB
Graphics: Intel(R) Iris(R) Xe Graphics
OS: Windows 11
2. Browser & Local Environment:
The issue persists for both users in both Google Chrome and Microsoft Edge.
Our Questions for the Community:
When navigating between two separate Retool apps, what exactly is happening under the hood? Does the entire Retool editor/framework, user authentication state, and all libraries have to be re-initialized from scratch, or is there a more optimized hand-off?
How sensitive is Retool's app-loading performance to network latency vs. bandwidth? Are there specific network metrics we should be measuring (e.g., Time to First Byte, ping)?
Are there established best practices for optimizing performance in a multi-app Retool architecture? For example, are there ways to "preload" parts of the next app or reduce the initial query load?
Beyond the standard Performance tab in Chrome DevTools, are there any Retool-specific debugging tools or techniques we can use to pinpoint exactly what is taking up the most time during this app-to-app transition?
I’m at 14.6 s to LCP in our core published app, so you’re doing well!
In all seriousness, I just wanted to chime in that this isn’t a “you” problem. Our experience with Retool’s backend is the same as yours, even after completely rearchitecting the app to break out pages and reduce dependence on transformers. It’s pretty demoralizing, to be honest.
I’ll just start by saying I love almost everything about retool and the trajectory it’s on. Game changing for internal platform development.
The only thing that would stop me from giving it a perfect rating would be the app load times (and also switching from page to another in the multipage apps).
Our LCPs range from about 6 seconds to 13 seconds and also depend on which page of the app we’re loading into.
We do use a lot of modules (and modules nested within modules) which is great for developing, but loading time seems to be proportional to the number of modules included in a page.
Would be great if this is something that can be looked at.
Thank you for the feedback! I can relay this to our performance team. The best advice I would say is optimizing queries that run on page load, and the second largest variable in page load time is the number of components per page.
If you have a JSON export if you app, I can pass that long to the performance engineers to inspect to see if they can get more insight into why the LCP is so high.
I can also look to get answers to your questions as well!
@BenCook I would highly recommend using as few modules as possible and not nesting them that will definitely improve performance.
Modules are very old and are being prepped for a major face list to improve and modernize them. I always recommend keeping them as simple as possible when the use case makes sense for duplicating components/logic.
Just heard back from the performance engineer team.
First order of business, if you can share your app UUIDs @M_Mulder@jericsinger@BenCook, we can check on the performance logs via one of our internal dashboards to see if these load times are anomalous.
Secondly, we have some more information on Martin's questions.
Page load time is comprised of multiple phases:
Download and eval HTML/JS/CSS
Download app template json / lookupPage api
Start runtime, download and eval runtime JS code
Build app depgraph and app model (5ms per component)
Run initial queries
Process query data and render components
When you navigate between Retool apps you don’t have to do #1 again but have to do everything else again, which is a lot of work. This is why we built Multipage.Navigating between Multipage pages also skips #2 and #3.
Unfortunately there are not any ways to preload parts of another app, the closest thing would be for query's under their 'Advanced settings you can cache the query results for populating components with data.
Retool does have a debugger panel in the bottom right that is very helpful for testing, troubleshooting and viewing the timeline of events that occur in an app to see how long different things take.
that will definitely improve performance.