If you are unsure what the cause of Performance issues in your doc is, please take a look at this article Improving Performance.

You'll know you're dealing with a rendering performance issues if switching to pages or scrolling in big pages takes a long time. These issues have nothing to do with calculation or memory, so you don't need to change any formulas or delete data at all.

Why is it happening

Coda has loaded the doc in your browser, but is taking a long time in actually putting the data on your screen. This most commonly happens when your page displays a large amount of data with a large number of columns (>20), and especially when using grouping. The way to fix rendering issues is to reduce the amount of data that you are showing at any given time.

How do I fix it

To fix rendering issues, go to the pages that you know render slowly. If you're unsure of the problem page, you can identify it by seeing how long it takes to switch to it or how slow it is to scroll through it. Once you find a slow page, you can try one of the following tactics: 

  1. Remove Grouping: If you are using multiple levels of grouping or tables with a large number of groups with only a few rows each, the most effective thing you can do is to remove the grouping on that view. Not to worry, we will soon release improvements to how groups are rendered that will make these issues go away. If you rely on grouping in a large table for your workflow, you can also try switching to a Detail layout and using subtables. 
  2. Use Detail Layout: If you need to have a view with a lot of rows or columns, it's effective to switch to a Detail layout rather than a Table. A Table layout will render all the visible columns of all the rows that are visible at any one time. On the other hand, a Detail layout only renders the columns for one row at a time, making it much faster. You also get the benefit of being able to search through your long list of rows by name rather than having to scroll in a table. Finally, if you have columns that are lookups to rows in another table, you can even see a subtable for each of the rows. 
  3. Hide columns: Sometimes, users have a view with lots of columns, but they don't need all the columns to be visible. A simple thing you can do is to hide the columns that you don't need to see at the top level. You can still make the columns visible in the row detail, so you can get to them with one click by expanding the row.
  4. Filter out rows: Sometimes, users have tables with lots of rows that they don't need to make visible. If you filter out a large number of those rows, that particular view will render and scroll much faster. Even if you filter out all or most of the rows from your master table, you'll still be able to see those rows in the relevant views and reference them in formulas.
  5. Filter using controls: Sometimes, you only need to look at data matching a certain criteria at a time rather than displaying them all. In Coda, you can create controls that filter your view whenever you change their value. For example, you can use a dropdown or slider or date range picker to only show rows that match your current selection. Using a control like this is a simple way to reduce the number of rows in your view at any given time without disrupting your workflow.
  6. Create more views or pages/subpages: If the issues in your doc are caused by rendering, then adding more views or pages will not impact performance. In fact, if you split your big pages or views into separate pages or subpages to reduce the number of rows in each one, they will scroll much faster. In particular, this is important if you have a large amount of text in a single page. Breaking apart long stretches of text (50k+ characters) into multiple pages will improve performance.
  7. Create data entry views: If your workflow requires you or your team to enter or update data, it's a best practice to create a separate view for data entry. For example, if you have a bug tracker, rather than having people go into the big master list of all bugs, you can create another view of that table, just for entering bugs. For example, you can filter that view as follows, to only show the rows that were created recently by a certain user:
thisRow.Created()=Today() AND thisRow.CreatedBy()=User()
Did this answer your question?