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.
”Be cautious with nested modules: It is possible to nest one module inside of another module. This does not have performance impacts, but it can make the module difficult to debug.”
I’m curious to know what happening with updated modules and if there will be a migration path from the older modules.
Our apps are all built as modules which has been super handy - for example aggregating seperate apps into multi-page apps was super easy as we could just drop the relevant module onto each page.
Lastly, it there a way to have some sort of loading gif on a page - 10s can be an eternity when there’s nothing on the screen.
Great find on the docs! That is true that it shouldn't affect performance. App bloat of components, queries and the total amount of data being loaded by an app are likely to play a much bigger role in app performance.
Version 2.0 of modules is still a ways away so you won't need to worry about that. But I believe we should announce how we are going to support moving from the older modules to newer modules when that time comes
Yes I agree a loading gif would be super useful, I know we have a ticket currently for our engineers to add that. I can add your +1 to that as well.
I know some users have gotten creative with having a modal pop up if table1.data is falsy and still loading. And in the modal they have an image saying the components are loading.
Our issue is more the time it takes to load what I guess are the components & queries (around 10s) - after that the app loads the data and comes to life pretty quickly and is responsive enough.
Hi @BenCook I work on the perf team and happy to share we have recently deployed a change to render a loading indicator when navigating between apps. This is specifically when clicking a component that has a Go To App event handler. This should be live on Retool Cloud and will be in the next stable (Q1 26) release.
We are continuing to work on improvements for other methods of loading apps as well. Please continue sharing your pain points so we can prioritize them.
Yes have been through that and have implemented those where we can. But the issue isn’t so much after the page has loaded, but the length of time the app sits on a white screen prior to that.
I’m suspecting having a couple of modules in the app header (so modals can be launched whichever page the user is on) is adding to this wait time.
Also we use quite a few transformers - I’m not sure if these slow the loading of the app as well.
App load time is largely a function of the number of widgets and queries in an app. All of the widgets and queries in every instance of modules should be added up for this calculation (you can check the Debug Tools > Performance tab in Editor mode for an App Size number). Each widget and query adds about 5ms of load time. Keep in mind this 5ms constant depends on the CPU model since Javascript performance in browsers are mostly single-core CPU bound. There are other factors but when an app is huge, the number of widgets and queries (collectively called “plugins”) will likely be the dominating factor.
When using a multipage app, any widgets+queries on inactive pages should not noticeably impact load time. So this makes the multipage feature is a great way to scale apps. However the tradeoff is that changing pages incurs a slight load time (again about 5ms per plugin on the switched-to page). We are working on ways to keep improving these sources of page load and page switch latency!
If you are able to share a JSON export of your app I can check it out with our eng team to see where your apps performance compares to others of similar size.
that will definitely improve performance.