I’m in a similar situation and have been trying to find better ways to make things more efficient and faster. I have a large-ish table with a handful of relations linking to other tables along with some several computations…and relations in those other tables linking back to the large table.
One thing I’ve learned is that any relations that rely on computed columns, such as templates, will take longer to build initially. In my case, I did have one particular column that was built from a vlookup in my google sheet and used for relations. I found a way to reproduce the value using glide computed columns, but it actually made my app quite a bit slower because it first had to run all of the calculations to build the values that could then be used to build the relations. I ended up reverting back to using formulas in the google sheet for this particular case, since glide only sees it as static value instead of a value that needs to first be computed. That helped bring the speed back to where it was.
I also think any other computed columns in a large table can also cause slowness, even if they aren’t used to build the relation. I think the first time that table is accessed, all of the computed columns need to be processed before any data in that table can be shown. Especially if you have over 31k rows, that becomes a lot of data to process. I also think that whenever you have relations, all computations in those related tables need to be processed before the table data is shown.
Overall, I don’t think migrating your data from a google sheet to a glide table is going to make a whole lot of difference, especially if it’s static data. All you are doing is eliminating the extra travel time between glide servers and the google sheet. Glide already has a copy of that data on their server and the app is directly communicating with the glide server. If the data is static and isn’t changing via the google sheet or the app, then there is nothing to sync, so it’s not really going to speed anything up.
Hard to say what you can do to make it better. Wish I could be of more help. Sounds like you are working with a lot of data. For me your app loads quickly. Clicking on the main topics is quick, but the sub-topics take a while to load initially. The controversial topics seem to load slowly too, so I’m not sure if those are set up differently than the main topics on the front screen.
Mainly it becomes a lot of trial and error to eliminate as many computed columns as possible on any large tables, and reduce or simplify any relations.
One thing that might also help is if you can maybe split the Verses table into separate books? Just so the entire verses table isn’t trying to load all at once. Separating it might stagger the loading or computations, so it would appear to run faster.
I could probably offer other ideas, like setting a user specific value when you click on a topic, which would then be used to build a relation to the sub-topics or verses. So you are only creating one active relation at a time. But I don’t know if that would actually improve anything, and the added complexity could actually slow things down.
Short of trying to implement an API, I don’t have any good proven ideas to help you out, but maybe I’ve given you a few things to think about and try.