Remove grouping: If you are using multiple levels of grouping or tables with a large number of groups with only a few rows each, try to remove the grouping on that view.

Use detail layout: If you need to have a view with a lot of rows or columns, it's effective for rendering (and potentially from a design perspective) 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. In comparison, 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.

Hide columns: Sometimes, you have a table view with lots of columns, but you typically only need to see the data for a few. An easy tip is to hide the columns you don’t need to read the majority of the time, but you can still make all the columns visible when you expand the row (see this video for more details).

Filter out rows: Frequently, you will have tables with lots of rows that don’t need to be visible - you only want to look through segments of the data. If you filter out a large number of those rows, that particular view could render and scroll more quickly. Even if you filter out all or most of the rows from your base table, you'll still be able to see those rows in the relevant views and reference them in formulas.

Filter using controls: Sometimes, you only need to look at data matching a certain criteria and looking row by row can also be time consuming. In Coda, you can create controls that filter your view whenever you change their value. These controls can also be set for personal or collaborative use, so each person filtering doesn’t affect the view for others. 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 and show only the data you actually need to review.

Create more views or pages/subpages: If your doc is rendering slowly, think about adding a few views or pages. You can potentially split a large page with a lot of data into separate pages or subpages to reduce the number of rows in each one. This can help the tables scroll faster, and also make it easier for your team to navigate to the data that’s most important. 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.

Card view: If your table view is displaying a high number of cards, think about applying one of the above filter options or converting the card view into a table grid.

Create data entry views: If your workflow requires you or your team to enter or update data, it's a best practice (from a performance and design perspective) to create a separate view for data entry. For example, if you have a bug tracker, rather than having teammates go into the big overview 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: