10 tips to improve speed and performance in Retool

Hi all - @sophie and I have just recently published a new performance guide to the Bold Tech Blog :tada:

Sometimes performance improvements are not super intuitive in Retool, so in this article we combined a list of our 10 best tips for improving load speed in your apps. This has just got even easier with the addition of the performance review feature in the Retool debug tool.

Our tips break down into three main categories: overall infrastructure improvements, optimizing components and altering queries to reduce data load. Some of our top tips:

  • Break large apps down into smaller ones that function like multi-page apps. We write more about this in our multipage app guide
  • Limit charts and complex arithmetic, making sure such complex queries only run when needed (or even use pre-loaded JS)
  • Use only the data you need - paginate large datasets, minimize queries running simultaneously and segment data that isn’t always used into separate queries

These definitely aren’t hard-and-fast rules (they sparked much internal Bold Tech debate), and exact results will vary according to each individual app and situation, but hopefully these can act as a guide to help you optimize your app load time!

10 tips to increase speed and improve performance in Retool

4 Likes

From your article can you elaborate more on

"But, unfortunately, Retool’s modules do have some runtime issues and are generally not yet performant enough to be truly useful in all cases. That’s why generally, we would avoid using modules where possible."

Also, when jumping between apps in a multi setup what are your thoughts about the initial rendering of each app (side, top, and body), doesnt this break the ux flow for users?

"But, unfortunately, Retool’s modules do have some runtime issues and are generally not yet performant enough to be truly useful in all cases. That’s why generally, we would avoid using modules where possible."

Modules are hotly debated topic - use of them is sometimes necessary, especially in enterprise deployments and they do "the job" but come at a cost of performance, dev time and amount of tweaking required.

There is no native way of controlling rendering, tweaking modules but more of passing variables to enable/disable loading per certain criteria. Many users tend to skip this step so performance degrades with heavy use of modules.

Overall if you know what you're doing they should suffice, but there are nuances with adding/deprecating inputs/outputs that get complicated over time or stay within code causing bloat.

Also, when jumping between apps in a multi setup what are your thoughts about the initial rendering of each app (side, top, and body), doesnt this break the ux flow for users?

Regarding switching between apps there is a open bug report which is a recent change as it shouldn't be the native behavior.

These performance improvements should give you general direction and will change on the situation, need of the organization.

1 Like