How to Optimize Retool App Performance

Open your app in edit mode and click the bug icon (bottom-left) to open the Debug Panel. Switch to the Performance tab. Retool grades your app in several categories: Queries (payload size, count), Components (total count), and Network (response times). Review each grade — anything below B is worth fixing. Note the specific issues listed under each grade: 'Query X returns 50,000 rows' or 'App has 65 components — consider splitting into pages'. Start with the F and D grades first.

The most common performance killer is fetching too much data. A query returning 10,000 rows with 20 columns generates megabytes of JSON that the browser must parse and render. Fix this by: (1) SELECT only the columns you display, (2) add a WHERE clause to filter down the result set, (3) implement LIMIT for all queries without pagination. Retool's recommended payload limit is 1.6MB per query — the Debug Panel shows each query's payload size.

1-- ❌ Before: SELECT * returns all 40 columns
2SELECT * FROM orders WHERE status = 'active';
3
4-- ✅ After: SELECT only displayed columns
5SELECT
6  id, order_number, customer_name, status,
7  total_amount, created_at
8FROM orders
9WHERE status = 'active'
10ORDER BY created_at DESC
11LIMIT 500; -- Cap at 500 rows until pagination is added

Every query with 'Run on page load' enabled fires simultaneously when the app opens. If your app has 10 queries all running on load, the page must wait for all 10 to complete. Audit each query: is it needed for the initial view, or only when the user interacts? For queries behind tabs, modals, or filter selections — disable 'Run on page load' and instead trigger them from an event handler or via 'Run when inputs change' (which only runs when their inputs have values).

Client-side pagination (the default) fetches all rows then paginates in the browser. Server-side pagination fetches only the current page's rows. Enable server-side pagination by modifying your SQL query to use LIMIT and OFFSET tied to the table's pagination properties: {{ table1.pageSize }} (default 10) and {{ table1.pageIndex * table1.pageSize }}. Also add a count query for total pages. This keeps payloads consistently small regardless of table size.

1-- Server-side paginated query
2SELECT
3  id, name, status, created_at
4FROM orders
5WHERE status = {{ statusFilter.value || 'active' }}
6ORDER BY created_at DESC
7LIMIT {{ table1.pageSize }}
8OFFSET {{ table1.pageIndex * table1.pageSize }};
9
10-- Companion count query for total pages
11SELECT COUNT(*) AS total
12FROM orders
13WHERE status = {{ statusFilter.value || 'active' }};
14
15-- In the Table Inspector:
16-- Pagination type: Manual (server-side)
17-- Total rows: {{ countQuery.data[0].total }}

Aggregate queries (COUNT, SUM, AVG, GROUP BY) are often the slowest in your app because they scan entire tables. Enable caching in the query's Advanced tab. Set a TTL appropriate for how often the underlying data changes — a daily summary query might cache for 5 minutes, a static product catalog for 1 hour. After enabling caching, use await queryName.invalidateCache() in write operation success handlers to ensure stale data doesn't persist after modifications.

Retool's Debug Panel gives a component count performance grade. Apps with 50+ components have high render overhead. The solution is converting a single large app into a multipage app: click Settings → Convert to multipage app. Create separate pages for distinct sections (Dashboard, Orders, Customers, Settings). Each page loads only its own queries and components — reducing the initial load and improving perceived performance significantly.

If a query has 'Run when inputs change' enabled and is triggered by a text input (like a search box), it fires on every keystroke. A user typing 'customer name' fires the query 13 times. Add a debounce by using a JS Query as intermediary: instead of the query directly watching the text input, watch a Temporary State variable. A 'debounce' JS Query (not on page load) sets the state variable with a 300ms delay after input changes.

1// In the text input's On change event handler:
2// Trigger JS Query 'debounceSearch'
3
4// JS Query: debounceSearch
5// Triggered by search input's On change
6let debounceTimer;
7clearTimeout(debounceTimer);
8debounceTimer = setTimeout(async () => {
9  await searchQuery.trigger();
10}, 300);
11
12// searchQuery references searchInput.value in its SQL WHERE clause