Glide apps builder very slow in browser

Ask for Help
1

Good morning, I’ve been using glide for some time now, and I’ve noticed that as the app grows, it becomes slower to edit. I’m already on the second app, and being able to edit labels, and perform other actions, has been taking more and more time.
Currently I open the glide app builder in Google Chrome.
What could I do to have a more fluid app editing/building?

I found this topic in the community with similar problem, but it was not resolved either.

2

There have been a lot of good explanations by Jeff about app performance. I wish I had bookmarked some of his posts.

A few ideas.

Data Editor: send only needed data to the user’s device and if possible keep things in Glide

  • If possible, use Glide Tables over any other 3rd-party data source (Google Sheets, Excel, Airtable, etc.)
  • Avoid Airtable. The amount if troubleshooting and questions in the forum are a good indicator that Airtable is to be avoided. This is my personal view only.
  • When appropriate, use Row Owners. Less data will be downloaded to user devices, pages should load more quickly.
  • (Relation vs Query. When you set up a Query column, Glide will let you know when using a Relation instead would enhance performance. I wouldn’t worry about this too much, but it’s worth noting that Glide itself has a warning message at times.)
  • (Single Self Relations seem best avoided.)

Layout Editor: don’t load too much on a single tab

  • Avoid duplicating collections on the same tab yet displaying different information via visibility conditions or sorting.
  • Avoid having too many images load on a single tab.
  • Performance in the builder and in production on a device can be different: test outside of the builder.
1 Like
3

Sorry but what would be an example of a “Single Self Relation” use?

4

An example is a relation that links a column in a table to the same column in the same table (self relation). You are relating a row to itself.

When creating the relation, do not check the ‘Multiple’ checkbox. With the checkbox unchecked, it’s a single relation instead of a multiple relation.

1 Like
5

Hello @nathanaelb, can you elaborate on this a little more? Did you mean that we should avoid duplicate collections (which have different information via visibility conditions/sorting) on the same tab, or that we should avoid duplicate collections, and instead have a single collection which will display different information via visibility conditions/sorting options?

What would the alternative be if I need to have different filters of the same collection for different roles? I could think of two solutions:

  • Solution 1 would be to have different pages altogether, each with the required filters. The different user types would see the different pages via visibility conditions.

  • Solution 2 (the solution I am using now) is having an IF-ELSE column which acts as a filter on the collection, and the contents of that IF-ELSE column would change depending on the type of user. This way, I can keep 1 page and one collection, but the contents of that collection would change depending on who’s using the app.

6

You could make the source of a collection a relation/query removing the need for front end filters.

1 Like
7

Could you elaborate on that, or point me to any articles/videos? I’m not sure how to do what you said.