Are you using our SaaS platform (Baserow.io) or self-hosting Baserow?
Self-hosted
If you are self-hosting, what version of Baserow are you running?
Baserow 1.34.2
If you are self-hosting, which installation method do you use to run Baserow?
Linux Docker
What are the exact steps to reproduce this issue?
Hi team,
Some of my published Application pages are quite slow to load. I’m sure it’s my fault. Either I have too many data sources on a page, or maybe too many lookups or filters or something. The issue is, I’m not sure what the culprit is. It’s not unbearable - like the initial load of a page might take 6 - 8 seconds. After the initial load, subsequent loads are much faster.
What steps should I take to track down what is causing the slowness? Would indexing lookup fields help (or the source of the lookup field?). I read about how indexing could improve speed but I’m not sure if this is my issue - Baserow itself is super fast. It’s just some application pages.
I’ve made sure it’s not something like large images. I’ve run Chrome Dev Tools performance tab, and it’s more or less Latin to me, but it seems to indicate that “Scripting (children)” is the slowest element. Can you suggest ways for me to work out what is slowing it down so I can fix it.
The downside with rich applications is that usually the first page load is slower.
FYI the very first load of an application (per user role) creates the cache for this application so subsequent loads are faster as you noticed and it’s for all users not just for you. So if you don’t publish the application again you won’t have this warming up delay and other users will have a fast website.
However, as you guessed, when an application is slow it’s usually because it has a lot of data sources, so the fewer data sources you have the better.
Pro tips
For data sources used only in collection elements like tables and repeats, you can set the default returned row count to 0 to prevent an unnecessary dispatch.
Depending on the data sources you have, some of them could be shared for the whole website (like the user profile for instance). A shared data source is loaded only once so it won’t slow down other pages.
The data source loading time is highly related to the complexity of the related table (lookups, related rows, …). So it may be worth creating synced intermediate replicas or adding the right indexes to make it faster. You can define indexes in the field configuration. Indexes on filtered values make sense and can greatly help sometimes.
As an alternative, when you create a data source, if you select a view instead of defining manually a filter, it could help as indexes are created automatically for view filters.
