Skip to content
Notes - 2mbWeek - 2mb
Managing your document’s data volume is key to ensuring long-term performance and maintaining fast, reliable workflows. We recommend a strategic approach to data retention focused on your largest and most active tables.Key Tables to Monitor:DB Hour Logs is nearing 10,000 rows and may soon impact performance.DB Contracts contains a canvas column with extensive text and multiple formulas, both of which increase document size and complexity.Archive Historical DataDB Hour Logs: Periodically move older data to a dedicated Coda document (for analysis/charting) or to Google Sheets (for historical reference only). This will keep the main document lean and responsive.Optimize Table StructuresDB Contracts: If contracts are finalized, consider deleting old entries or converting text-heavy canvas columns to simpler, editable fields. Alternatively, use a button to re-import contract data only when needed, which reduces active rows and formulas.Document Retention PolicyEstablish clear rules for when and how to archive or delete data, especially as tables approach 10,000 rows.Regularly review table sizes and set automated reminders or workflows to trigger archiving at set thresholds.
ii
Make it pretty: This is important! We don’t want to downplay the value of a document that looks good - especially when your team works in it every dayFlag items for notice: Think about tasks being red when they are overdue, or rows having colors based on priority. Colors help draw our eyes to things that matter and quickly identify the “type” of something.Additional columns increase over the table size, which increases the document size. Formulaic columns must calculate 1 time per row. If you have a 10,000-row table, one conditional format on a table is akin to running 10,000 individual formulas.
Comprehensive Report
Flagging Legend
How to read and understand this report
Throughout this report, we will note whole sections and individual items against a flag-type defined below. Use this legend to help you gauge the importance of focusing on different areas for improvement.
Red
This must be addressed. Addressing this issue will increase doc performance or have other critical and positive business implications
Orange
Our team believes this is an issue that needs to be discussed. If this is not mission critical, we should think creatively how to address
Yellow
Something your team should be aware of but doesnt necessarily need to be immediately addressed
Green
Something worth noting - but all good here! Your team has used this in a great way and is following best practices
Document Details
High level details on your documents rows, pages, views, and more. This gives the 30,000 foot view of your documents performance and potential causes of slowdown
Flag
Metric
Info
Total row count
rows across all your tables
Total base tables
total base tables in your document
178
Total tables + views
total tables and views. views
Biggest table by size
Your biggest table by size is DB Hour Logs with 24 mb worth of data. Its biggest columns are:
These large columns will be focuses for improvement as they cause outsized difference to total doc-size.
Table with maximum views
The table with the most views is DB Invoices with 24 views. Each additional view added to a document has an equivalent effect of an additional column added to that table. More views of a table is adversely affects performance in relation to that base-tables size.
Total pages
total pages, including hidden
Formulas
3250 formulas in the document
Media
462.1 mb of media
Buttons and Controls
345 buttons and controls
Total document size
100mb. A healthy document size is under 100mb. Although, some documents run just fine at >200mb. Whether or not your documents size is a concern depends on your goals and the workflows that the document supports.
Word-Count
22,890
AI Usage
47,863 Credits
There are no rows in this table
Data Size and Retention Policies
Business rules around what data can be deleted or archived and on what cadence
Data volume (the number of rows) in your documents has the most direct relationship to document performance. Data size alone can cause a doc with no other issues to slow down and data volume exacerbates all other issues in your document.
Total Row Size
The total number of rows across your entire document
Tables over 5000
A list of the tables over 5,000 rows. These are tables that are not problematic yet. But you should be aware of them!
None
Tables over 8,500
A list of all the tables over 8,500. These tables are close to the 10,000 mark, and without a clear data retention policy you will soon hit 10,000
None
Tables over 10,000
Tables over 10,000 are not necessarily an issue in and of themselves. But tables over 10,000 rows will not sync in their entirety through cross-doc and are not available to any API queries
None
There are no rows in this table
Based on your current doc-size and your communicated through-put, we believe the amount of data in your document will become an issue in about 6 months time. Especially your DB Hour Logs table. It is moving close to the 10,000 row range
Data Retention Policy
Recommendations:
Calculations
Calculations are the #1 culprit for creating a slow and clunky doc. Here is a full breakdown of the calculations in your document and those that are causing the greatest issues
93seconds slowdown
93
Avg Calc time added to doc per average action identified
5
5
calculations identified
2
2
calculation issues outstanding
3
3
calculation issues resolved
seconds saved
42.00
Problem Calculations
Flag
Table
Column or formula name
What operations
Average Time
Flag Rating
Resolved
Average time after resolution
There are no rows in this table
Calculations By Impact
This chart breaks down the different columns or calculations broken down by
Num of seconds per priority level
This chart shows you on average how many seconds different problem calculations are taking up, split by priority level
API Considerations
This section breaks down how your doc currently interacts with API limits. API limits effect your ability to get data into our out of a document. For many teams, API access to a doc is a critical feature and can cripple a documents value
Your documents total size
Your documents' total size is 60mb. You are.
under the api size limit
This is great! It means your document should continue to be open to API calls in all manners for some time to come
Table sizes and table concerns
While your entire document should stay open to the API for a long time, the DB Hour Logs table will soon not be able to be read by the API as it crosses the 10,000 mark. We can restructure this information in CSV format to be read by an API as needed, or utilize a larger archiving strategy as part of your implemented data retention policy
Quick Wins
Here is a breakdown of all the quick-wins that our team implemented. These are actual changes we’ve made to your doc that do not affect functionality but will cause measurable improvements in doc speed and loading time
Search
Formula Borrowing
In your DB Hour Logs table, you had 4 columns that utilized a filter like the following
[DB Contracts].filter(currentValue=thisRow and [Do not bill]=false).Hours.Sum()
We were able to store the following formula in a new column called All Contracts
[DB Contracts].filter(currentValue=thisRow and [Do not bill]=false)
Each column that previously used this filter now uses something like the following:
[All Contracts].hours.sum()
[All Contracts].person.unique().count()
This has no impact on your doc other than a positive impact to speed
Orphaned Objects
Your document had 18 orphaned objects. These are objects that exist in your doc but, take up doc space, but are effectively invisible and connected to nothing.
We deleted them all safely.
Deleted Pages
We found 18 different pages that were hidden with no content and no invisible content on the pages. We deleted all those pages
Formula Borrowing
In your DB Hour Logs table, you had 4 columns that utilized a filter like the following
[DB Contracts].filter(currentValue=thisRow and [Do not bill]=false).Hours.Sum()
We were able to store the following formula in a new column called All Contracts
[DB Contracts].filter(currentValue=thisRow and [Do not bill]=false)
Each column that previously used this filter now uses something like the following:
[All Contracts].hours.sum()
[All Contracts].person.unique().count()
This has no impact on your doc other than a positive impact to speed
Conditional Formats
Conditional formats can be huge perfomance concerns. Here is some quick data on what we found about your conditional format usage
Context on Conditional Formats
Yes, conditional formats look pretty and are keys to flagging certain elements in your tables, but in large documents, conditional formats can be hidden performance drags and should be carefully applied.
We operate under the assumption that conditional formats perform a couple of key functionalities in your document:
In the background, a conditional format is acting like an additional formulaic column added to a table. On large documents this is a concern for two major reasons:
Lets dive into what we found about conditional formats in your document 👇
Issues
Here is a list of the different concerns our team found in your document concerning conditional formats.
Image
Concern
Table
Table row count
You use a Red format to color overdue tasks. You have re-written this multiple times across 8 views. Instead of re-writing that format on individual views, we should place it on the base table and allow those 8 views to inherit that format
DB Tasks [Cross]
In your DB Contracts table, the complex formula you use to color the "Status" column is currently written twice: once in the formatting rule and again in a column of the table.
To improve efficiency and performance, avoid re-writing the same formula in multiple places. Instead, write the formula in the column once, and set your conditional format to reference the result from that column. This way, you maintain consistency and reduce redundant calculations across your document.
DB Contracts
We noticed on your Opportunities page there were 8 different colors across different columns. Visually it is a bit chaotic. I’d recommend deleting these unles ss you can argue that
DB Opportunities
There are no rows in this table
Concurrent Usage
How many people, on average, use and edit a doc simultaneously
Multiple people using your document at the same time can cause significant lags in performance. Lets be clear, this is an internet thing generally — Not just a Coda issue. Lets dive into why this is an issue
What are concurrent users:
Concurrent users are users that are currently logged in, with an open-active tab on their browser. This is not simply a number of how many users the document has been shared with.
Why is this an issue
Coda allows real-time collaboration. Meaning that the edits that happen on one person’s computer in Illinois are instantly synced and available to any other person in the document whether they are in the cubicle next door or in an office in New Zealand.
The more people logged in at the same time, the more physical computers Coda is trying to instantly synchronzie in the background in real time.
Other platforms like Figma or Google Docs actually place a hard-cap on number of concurrent users to help with the slow-downs that happen in trying to sync so many devices together.
Our Findings
We found that on general, you have about 20 concurrent users at maximum in a 7 day period. Right now this is not a concern
Page Analysis
Information on the pages and their use across your document
Pages by themselves, unless filled with a massive amount of text content, don’t affect doc-performance in an outsized way. One of the major reasons we look at pages is from the User Experience (UX) angle. Documents that get used for a long time often undergo “page-bloat”.
Page-bloat is when a page is created with good intentions (or bad!) and then not used. Page-bloat can lead to a confusing and chaotic experience for both your doc-makers and doc users. Page-bloat is easy to identify by the intersection of the % of hidden pages and pages with little to no view time in the past 30 days.
Don’t delete pages unless you are working with an experienced Coda-developer. Pages, even if un-used, can contain vital base-tables or variables that allow the document to work. Before we delete any pages as a part of a broader cleaning effort we will comb through those pages connections in the rest of the document.
178
178
Total Pages
108
108
Hidden Pages ()
60.7%
Your large number of pages is an indication of some page-bloat. Especially with 60% of your pages being hidden, theres a likelhood we can delete many of those pages.
Page Breakdown
Icon
Name
Browser link
Sessions (last 30 days)
Views (last 30 days)
Average View Time (last 30 days)
There are no rows in this table
Ready to dive right in? Our team can only complete 2 doc-audits a month, save your spot using the form below:
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.