Rendering issues can be identified in a few ways. For instance, you may be experiencing slow speeds when you scroll through a lengthy page or switch from one page another. Or you may see gray loading indicators instead of rows when scrolling tables, and it takes a while for the row details to show up. If this is happening to you, it’s likely related to rendering performance issues. This article will share some tips on how to improve and resolve these issues.

❓ If you are unsure about the cause of a performance issues in your doc, please take a look at this overview article on improving doc performance.

Rendering basics

Rendering refers to the process of your browser converting the HTML, CSS, and JavaScript code of a webpage into the visual representation that a user sees on their screen and interacts with.

Rendering issues occur when Coda has loaded the doc in your browser, but the lag is actually affecting the data being displayed on your screen. The more data and styling a page needs to display, the longer it will take to actually be rendered after it’s loaded.

In general, the best way to resolve rendering issues is to limit the data displayed to only what’s needed, making both the page and the amount of data your brain has to parse lighter.

Improve rendering issues

To improve rendering performance, navigate to the pages that are rendering slowly. If you're unsure of which pages are the issue, try switching to different pages and scrolling through them to identify which ones are the slowest. Once you’ve identified them, try one of the following tactics:

Reduce column count

Sometimes you have a table view with lots of columns, but you typically only need to see the data for a few of those columns. 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). Additionally, consider deleting any columns that are no longer being used.

When choosing columns to hide or delete, it’s most beneficial to hide columns with extremely large cells, such as canvas columns with lots of data, or image columns holding GIFs.

Reduce row count

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. One easy way to do this is to utilize the filter bar and set default values for those filters.
Use an inverted filter setup: Another approach worth considering is what we call inverting. Instead of a default where you show all rows, then filter, you start with no rows showing. Then rows are included based on the filter criteria you add. It’s quicker to render a table with no rows, and then add the specific rows that match the filter.
- The simplest way to set this up is to use filter bar for the table, and set the default values for the filters to be blank. Learn more about filters bars and setting default values here.
- For a more involved but dynamic approach, check out this discussion on our community.
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. Forms are an easy way to achieve this. Or you could create a filtered view of a table.

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:

thisRow.Created()=Today() AND thisRow.CreatedBy()=User()

Try other view types

Grid Layout: Selecting the perfect table layout really depends on your data, but the classic Grid layout (the default table display) can support more rows than a Cards layout or Timeline layout can.
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.

Reduce grouping

If you are using multiple levels of table grouping, or you have tables with a large number of groups that contain only a few rows in each, try to remove grouping rules that don’t feel crucial to keeping your data organized.

Simplify canvas content

Consider removing content on the canvas that is no longer necessary. If your doc has some pages that are particularly long, you can also use collapsing. Breaking your lengthy content into sections with collapsible headers will not only make your page look more clean and organized, it will also speed things up when loading and displaying the page.

💡 For more tips, explore Ben Lee’s doc on good doc building habits or our Coda at scale guide.