Many thanks for the detailed question and example, @Maja_Overgard!
I’m the product lead supporting the performance team at Coda, so I’ll share a few overall thoughts and recommendations to keep in mind:
- 2 key things we spend resources on from hitting “go” in your browser to when you see your doc fully loaded and interactive:
-
- Downloading the data → This is all the data in your doc, which we need to download to show. The more of this you have, the longer it’ll take to see your doc.
- Showing (rendering) the data → Turning that data like a list of names into a Table or list of projects into a Kanban board.
- Docs are loaded in a progressive manner that optimizes for the page you’re looking at and then loads everything else in the background. While progressively loading, the doc is partially interactive. Once everything is loaded, including background content, the doc becomes fully interactive e.g., all buttons working and so on.
- All media e.g., videos, images and so on, do not impact doc load as they’re stored outside a doc and loaded on demand.
- Sync pages only load the source doc content when selected and don’t affect doc load. In general, you can think of their impact as similar to that of having another tab with the doc loaded — read details here.
- You had mentioned the doc being “rather big” and are considering rebuilding. I see you have an “Orders” table in your example and one general pattern we recommend is archiving data, since I imagine this orders table will grow over time and will impact performance as it would in any other system. You can keep any aggregate values e.g., total sales or number of orders in the main doc, and move the individual orders out using things like like automations and order date for example, while still benefiting from the aggregate information — read details here.
Now on your specific questions with the high-level thoughts applied:
1 How much of Table 1 does Coda load - only the two columns (Name and Rel_Table 2: Company) visible or also the hidden columns?
1.1 If only the visible columns, does it in any way affect performance to have 10 hidden columns vs. 1000 hidden columns?
1.2 Does it impact performance whether there is a lot of heavy images/files in the hidden columns?
How much is loaded from Table 2: Company, given there is a relation column visible to this table?
2.1 Does it load only the related row from Table 3?
2.2 Does it load only the visible columns from Table 3 or also the invisible?
For Questions #1 and #2
Coda will load all the data Table 1, 2 and 3. It will do so in a progressive manner and optimize to show you content for the page you’re looking at first, and then load everything else in the background for the other pages. When it comes time to show the data, it will only spend time to show Table 1. It wont spend any time on Table 2 and 3, since those are not visible. Similarly, for hidden columns the data is there, whether or not they’re shown.
As far as all media or file attachments are concerned, these don’t impact doc load. The content is stored outside the doc and is served via a cacheable CDN, which allows images in docs to load from memory or local disk instead of loading over the web every time. This means opening/loading a doc, switching pages, opening rows, etc., should all be faster whenever images are involved.
Does Coda spend ressources to load “Table 3 Orders”? Even though it is not shown on “My view page” and it is not used as a relation column in Table 1
For Question #3
Covered in the high level thoughts, response for #1 and #2 above. Resources will be spent to download the data for Table 3 in the background and no resources spent to show the table, since the page isn’t selected.
It seems the pre-selected value in the Select Control gets loaded AFTER the table filters. Is there any way to set this up differently?
4.1 In my example, I have the Select Control on the “My view Page” that filters “View of Table 1”. In my bigger Docs, I can see that Coda initially loads the ENTIRE table and then loads the value into the Select Control, which then filters the view. This - I assume - slows down performance of the Doc as it first needs to load e.g. 2000 rows to then filter down to 1 run afterwards when it loads the value of the Select control.
4.2 Does it matter for performance whether the Select control is on the same page (as in my example) or e.g. on a different, hidden page?
For Question #4
Typically one approach we’d recommend here is what we call the inverting. Instead of a default where you show everything, then filter, you show nothing and then include things based on the filter. It’s quicker for us to render a table with no rows, and then add the specific rows that match the filter.
Moving the select control to another page won’t help as we would calculate on load. That said, changing it from personal to collaborative would help, since we’d cache the result on our servers, since the control will be in sync across all docs. The trade off is that anytime anyone changes it, it’ll affect everyone else.
The other thought, a bit more on the doc design is consider using “People” type for the “Name” column in the “People” table. To build on that, you could enable the filter bar, so you can easily select a person or use the “only show me” filters — read more here.
Does it impact performance whether locking is set up?
For Question #5
Locking should have no impact on performance. It’s helps with reducing the probability of accidental edits by anyone and for a more focused or cleaner viewing experience — more here.
Let’s say I created a new doc where I use the Sync Page function, to sync “My view Page”. Does the answers to everything above still work the same? Or does a Sync Doc e.g. load less or more tables/pages etc.?
Back to our high level thoughts of sync pages being similar to having another tab with that doc loaded, leveraging a sync page of “My View Page” in this example will load the whole source doc, so should load most of the data and then render only the pages you’ve synced in.
Happy to answer any follow on questions and feel free to read these other posts for some of the context about the details I recapped above.