so positive changes are likely to happen soon
Great! Happy to hear that
Can you provide a couple of example, what pages should we improve first?
/dashboard - I go there quite often in order to go between apps, and its a fairly big bottle neck. It also changes very very rarely (except for the build status) so its a prime candidate for caching. I think caching the user’s apps and showing them immediately and then show the build status as its own inline loading spinner would be allow for some fluid navigation.
Overall, the biggest problem is that loading states usually block navigation. Lets say I want to change a trigger in one of my apps. The only data I actually need to complete this task is:
a) A list of my apps
b) A list of triggers for that specific app
So I start in another one of my apps, the journey to change a trigger is as follows:
/Dashboard (loading content)
/app/:id (loading page)
/app/:id (loading content)
/workflow (loading workflow page)
/triggers (loading triggers)
There are a couple of optimizations here that would shave off some 70% of the time:
Overall - it looks like you reload the whole page from scratch when navigating around. Is that intended? Every visit to /dashboard or /apps takes ~6s for me since it has to reload all the JS.
/Dashboard - cache the list of apps so I dont have to wait for the list to load
/workflow - show the navigation tab bar in the workflow editor immediately, so the loading doesnt block navigation. I know you have to check permissions for the tabs and stuff, but maybe it can be solved some other way?
Same for the small stuff like build filters. Why not show them before the list of builds have finished? If I would want a specific filter I probably dont want the full list of builds before applying the filter.