This article is relevant to issues with Memory Performance. If you are unsure what the cause of Performance issues in your doc is, please refer to the article on Improving Performance.
Memory performance issues show up when your document is too big to be loaded on your device. We typically observe this when docs approach the API size limit of 125MB (or 10,000 rows with typical use). The most common symptom of memory performance issues is when your doc no longer opens on Mobile. When you try to load your doc, you might see an error like this:
This error can show up for a variety of reasons and there is only a small likelihood that it is caused by memory performance issues. If your doc does not have thousands of rows or large image files in it, the issue in your doc is almost certainly caused by something else. However, if you are seeing an error like the one above, please get in touch with us over Intercom anyway and we can help to address it.
If your doc has gotten so big that it has memory issues, there is unfortunately not much you can do to fix it other than reducing the amount of data in it. Here are some tips on the ways you can go about doing it:
Switch from images to image URL: If you have lots of large images in your doc or an image column in your tables, it might help to switch to using Image URL instead.
Split up your doc: You may have a doc that contains a lot of data but that data isn't necessarily dependent on each other. It is a great idea in those cases to split up your doc into smaller docs focused on each individual use case.
Delete old rows: Often, it is not possible to split up your doc by use case since it comprises of one or more big tables that are linked to each other. However, sometimes a lot of the rows of data in your big tables contain old data that is no longer needed. Deleting these old rows will free up memory.
Use Automations: Rather than deleting rows manually, you can use an Automation to delete old rows. Perhaps you can set up an Automation that runs once every night and deletes all rows older than 6 months.
Archive old rows: In many cases, you do not want to delete old data altogether. However, sometimes you are not actively using old data and just need to store it as a historical record. If that is the case for you, it might help to create one or more "Archive" docs. You can cut your old rows of data from your big doc and paste them into smaller archive docs. This way, the doc you actively use can still be smooth but your old data is still accessible when you need it.
Use the Coda API/Zapier: At times, you may need to also reference the old data in your doc so having it in archive docs may not be good enough. However, in those cases, you could make use of the Coda API or Zapier to share relevant data between related Coda docs, rather than having everything in one doc.
Avoid buttons in tables: Buttons and conditional formatting are perfect for small utility-oriented tables, however it takes up a large amount of data compared the other doc elements. When button columns are added to tables with 1000+ rows, we've observed doc size rise and overall performance drop. If you need to do button operations on a large table, try pulling the button out above the table and replacing the button column with a checkbox column. Then, use the button to run formulas on the checked rows.
Reduce grouping if possible, especially multiple nested groups: They don't take up as much space as buttons in tables, but this adds up if used excessively.
We'll continue to make improvements to memory performance, so your should see your docs become more and more resilient over time as they grow.
If you're seeing an "Out of Memory" error, check out this article.