@Ilqar Here are just some of my personal suggestions for “Where to start” looking for the slowdowns. (Aka what not to do)
Meaning there might be many, or there might just be one.
- Lots of files or images (large assets in general) loaded directly into your app instead of being stored in a Data table and pulled when needed for each form. This is one I have not experienced but see it many times as a culprit.
- Many
import
statements for large and slow loading python libraries in any of your server modules (they all import every single time you call the server under the free and lowest 2 tiered plans)
To see if #2 is affecting your performance, you may try experimenting with this lazy loading decorator I built. (You could use it for productions but its mainly for experimentation before you might go around changing all your code):
- Doing absolutely every server call to gather data in the
__init__
of the form.
If some of the components need data to be rendered on the screen and others do not, you may think about structuring your app differently to have the base form show, and have those components load empty, and have the show event of those components separately load their own data.
Doing this gives the user the experience of the form “loading” fast, even if what they need to see isn’t yet available. (It stops looking “broken”, and looks more like data loading in which makes people more patient) - Not reading absolutely everything @stefano.menci, @jshaffstall, and @p.colbert suggest frequently about loading as much possible data for each form within one single trip. Going back to #2, every single trip to the server with a server call loads an entirely new python instance, and every round trip to the server or data tables incurs +1 extra non-zero amount of times worth of network IO latency.