I’m finding the homescreen of my app now takes a few seconds to load most times. I’ve not changed anything on that screen for a while and there are no significant changes to the amount of data, but it is noticeably slower over the last month or so.
Anyone else noticing this?
Do you have a lot of images or a lot of records displaying on that screen?
There’s 2 collections. One currently shows 3 records, the other 12. The larger set includes thumbnails of logos.
The only other thing on that page is two ‘big numbers’ showing aggregate numbers.
It’s showing less than it has in the past, just because there is currently less data. It’s noticeably slower.
The page used to load almost instantly. Now it is slower, with the behaviour being slightly different on desktop be mobile app .
Desktop: top navigation loads. Body of page follows after a short delay.
Mobile: A different page initially loads, then gets replaced with the correct one.
Do you have a tab with a visibility condition that is using a computed column in your user table?
All of my tabs have a visibility condition (essentially internal/external users with different views for each). Most tabs use computed columns.
Did you mean, does the visibility depend on the computed column? If so, no it doesn’t. Visibiilty depends on a client company field which is just a text field
OK. You had mentioned that a different tab flashes on the screen momentarily. This usually means that a column value used for tab visibility hasn’t loaded yet at the time the tabs are loading, so in some cases you can see a different tab until the value used to control the visibility is loaded.
I only asked because my thought is that the app ends up initially trying to load that other tab, which may be displaying and computing much more data than the tab you want to see, and that’s why it’s slower.
Is it possible that you could move the tab you want to see first to the top of your tab list in upper left corner of the builder?
Moving the tab didn’t help much. Your explanation did made me realise something else though.
The tab that momentarily loads is one that is still in development. It is the first tab in the list that doesn’t have a visibility rule (because I haven’t finished it yet).
That does suggest I could do a horrible dirty work-around of having an extra page with no visibility rules serving as a “loading page”. It’s really wrong that it is needed, but I’m now concerned I have been flashing an in development page at users too.
I think my earlier observations about the different between mobile and desktop are a red herring. Desktop behaviour today is also flashing the unwanted page, so I htink it is just a timing thing.
You say that the tab in development doesn’t have any visibility conditions on it. If that’s the case, what is preventing a user from clicking on that tab, assuming that it is visible to everyone? The flash is one thing, but can’t a user just select the tab and still view it?
it doesn’t appear in navigation. There is nothing sensitive on it. It was previously public and I took it out of the navigation because it isn’t currently in use.
I do find the lack of release workflow (or the fact I haven’t figured one out) frustrating at times though. My usual approach is the restrict an in-development tab to only be visible to me and my test user, then lose an hour later down the line when I have forgotten that and can’t work out why the users are not using the great new feature!
The “loading tab” works surprisingly well though. Quicker would still be better, but it is workable
What do you mean by taking it out of navigation. If a user is seeing it…even for a moment…it must be part of your navigation somewhere.
just “hide from nav bar”
Ah ok. Yeah that just hides it from the nav bar, but the tab is still active, and if it happens to be the leftmost tab due to all other tabs being hidden, it is still the tab the is displayed. Try it by hiding your normal first tab from the navbar. It should still open up to that tab when that app loads even though you don’t see it in the nav bar.
The moment when the app initially loads, the user table is still loading and tab visibility conditions are still being determined for the signed in user. The new tab you are developing is the only active tab at that moment that is not controlled by any visibility conditions, so it becomes the first tab, and immediately the app begins to load and process any computed columns in any tables related to that tab. That new tab must be processing a lot more data and computed columns, and gets priority because it is the first visible tab when the app loads. That’s why it’s slower.
I guess if it were me, I would be putting a condition on a tab that is in development, so it is not accessible to others, or click the eyeball button on the tab on the upper left corner to deactivate the tab. You can still work on it, but it won’t be part of the published app.
Or you can use publishing control.
I’ll try to get in the habit of putting the controls in place first, thanks. Publishing control looks useful too. I wasn’t aware of that.