Skip to content
The “Calculating…” indicator appearing in the upper right corner for extended periods (more than 5 seconds)Initial time for a document to load when openedSlow or laggy responses to dropdown selections and button clicksGray loading indicators appearing when scrolling through tablesDialogs, menus, and panels taking a long time to open
What actually makes a document slow?How to speed up your document based on those factors
Total number of viewsDocument size in MBFormulas and Impact of calculationsRow CountColumn count and typeConditional formattingThe device you useConcurrent usage
Base tablesViewsExpand to learn more about views and base tables
125 MB: Above this size, the Coda API becomes inaccessible. It should be noted that the Coda API is different from Pax. Above this size if you have Pax integrated in your document, those should still run and sync but you would no longer be able to access the Coda API for this document specifically.325mb: This is the formula calculation limit: Once exceeded, formulas and automations are disabled until the document is reduced in size. This is very bad. You don’t want to get here. If you’re already here or near, Get rid of rows: This is a complicated topic. I wouldn't recommend just randomly deleting rows as rows can contain business-critical information. Rather set up a data retention policy with your team about what types of data can be archived and/or deleted at what cadence and under what circumstances Get rid or large text columns: Quick contributors to large mb worth of data are often times large bodies of text. Look and then use the doc map to identify columns and tables that are taking up more than two megabytes' worth of space. Start with these larger columns first to see what you can decrease
Formula Segmentation: Makes the writing of complex formulas both easier and more performant Easier to writeEasier to debugActually faster for your docs and tables!
Broken formulas: Fix them or delete them!Avoid problem formulas: Now() being the kingCache your formulas: Run them with a button or automation instead of an actual formulasFilter: Look at every single Filter() formula. Trust me, just do it.
Delete what you don’t need. Old test data, duplicate rows, records from three years ago that no one references—if it’s not serving a purpose, it’s costing you performance.Archive to a separate doc. For historical data you want to keep but rarely access, move it to an archive document. You can always pull it back if needed.For sync tables, filter at the source. If you’re syncing data from another tool, use the sync criteria settings to limit what gets pulled in. Filtering 50,000 rows down to 5,000 after they’ve synced is far less efficient than only syncing the 5,000 you actually need.
Swap Compose for Format(). If you’re just combining text and values, Format() gets the job done at a fraction of the cost. some rich documentation on the Format() formula: Reconsider your text column types. If your Canvas column only ever holds a sentence or two, switch it to a standard text column.Audit your button columns. If they’re not actively used, comment them out or delete them. You might be surprised what you get back. You can also combine multiple button columns into a single button using a larger RunActions() formula. Heres some documentation on that 👇Look for repeated data. If you’ve got the same value copy-pasted across thousands of rows, that’s a sign you should move it to a small reference table and link to it via a relation. Store it once, reference it everywhere.
Be intentional. Before adding conditional formatting, ask yourself: what decision does this help someone make? If the answer is vague, skip it.Set it on the base table. Let your views inherit formatting instead of duplicating rules across every view.Audit what’s already there. If a visible column (like a status dropdown with colored options) already provides the visual cue, you don’t need conditional formatting doing the same job.Simplify Formulas: Sometimes the formulas that are powering your conditional formats are unnecessarily complex. Feel free to audit them and make them more simple using other tips from this blog.
Large docs on mobile are painful. Phones just don’t have the processing power to handle complex documents. If your doc barely loads on your phone or doesnt load at all, that’s not a bug. Your experience might differ from your teammates: If you’re on a newer MacBook Pro and your colleague is on a five-year-old Chromebook, you might have completely different opinions about whether a document is “slow.” You’re both right. You’re just working with different hardware.Browser choice and tabs matter too. Running Coda alongside 47 other Chrome tabs? Your browser is splitting resources. Sometimes closing a few tabs or switching browsers makes a noticeable difference.
Want some more technical jargon 👇Close duplicate tabs. If you have the same document open in three browser tabs, your machine is running those calculations three times. One tab is plenty.Stagger heavy editing sessions. If you know ten people need to make updates to a document, consider whether they all need to do it at the exact same moment.Use view-only access where appropriate. Not everyone needs edit permissions. Restricting access isn’t just about security. It’s about performance too.Be aware of demo situations. If you’re presenting a document to a large group, expect some slowdown. It might be worth preparing a static export or limiting who’s actually in the doc during the presentation.
Reduce views — Consolidate multiple views into one with filter bars or currentUser formulasAvoid view bloat — Don't create separate pages/views for each team memberTarget < 150 MB — Stay under 125 MB if you need API accessHard limit: 325 MB — Above this, formulas and automations get disabledDelete old rows — Set up data retention policiesTrim large text columns — Rich text and canvas columns are heavySegment complex formulas — Break into smaller helper columns (faster + easier to debug)Fix or delete broken formulas — Error formulas still consume resourcesAvoid Now() — It recalculates constantly; use button timestamps insteadCache heavy formulas — Run via button/automation and write result to table instead of live formulaNever put calculations inside Filter() — e.g., avoid Filter(Table, Animal.Lower().Trim() = "dog")Create helper columns first — Pre-compute values, then filter on those columnsFilters should compare values to values — Not run calculationsPrefer Format() over Compose() — Much lighterAudit button columns — Buttons can be surprisingly heavy (one case: 70% of table size!)Use text columns instead of canvas — Unless you truly need rich formattingCombine multiple buttons — Use RunActions() to merge button columns< 5,000 rows = comfortable for any complexity5,000–10,000 rows = OK with simple schemas> 10,000 rows = Investigate if doc feels slowArchive old data — Move to separate doc if rarely accessedFor sync tables — Filter at the source, not after syncSet on base table — Views inherit it automatically (don't duplicate rules!)Be intentional — Only add if it helps decision-makingSimplify format formulas — Complex conditions add overheadClose duplicate tabs — Same doc in 3 tabs = 3× the calculationsUse view-only permissions — Viewers put less load than editorsBetter hardware helps — Coda runs locally in your browserStagger heavy editing — Don't have 10 people editing simultaneouslyDoc Map — Sort tables by size to find bloat"Calculating…" indicator — Click to open Performance AnalyzerStatistics panel — Check row counts, formula limits, media size
Share
Explore
Coda Document Performance Optimization Guide
A Comprehensive Resource for Identifying and Resolving Slow Document Issues
Introduction
Coda documents can slow down as they grow. This guide covers the main reasons for performance issues and offers practical solutions based on real experience with large Coda documents and setups.
Understanding Coda Document Performance
When you open a Coda document, your browser downloads the whole document so you can work offline. As the document gets bigger and more complex, your browser has to do more work to load and run it. Common performance problems include:
The dreaded "calculating!"
In the resource we are going to tackle a couple of key things:
* Not interested in reading all this and just need some quick and professional help getting your document up to speed? Get in contact with us here →
What slows down your document and how to speed it up
Unfortunately, while this may seem like a straightforward question, the answer is more complex. Coda document performance depends on multiple factors, each of which may contribute to slowdowns. We are going to outline many of those common factors below
* Feel free to start reading all the way through, or use the outline on the side to skip to the parts that matter to you
1. View bloat: Decrease the number of views in your documents
Coda tables come in two types:
When you make a new table in Coda, it’s called the base table. Any table you create from that base is called a view. Views are a powerful feature in Coda, but having too many of them can slow down your document.
Views are magical in Coda. They allow you to take one set of data (and view it in many different ways and in many different spaces, all while having your data in constant sync!). Look at the tables below and see how we have one base table with 1 view.
Base table of invoices
This is the base table of all invoices, change one of the Status values to Overdue and watch it instantly show up in the view below
Company Name
Invoice Amount
Requested Date
Status
Company A
$500.00
Sun, Jan 15
Paid
Company B
$750.00
Mon, Feb 20
Pending
Company C
$300.00
Fri, Mar 10
Overdue
Company D
$1,200.00
Wed, Apr 5
Paid
Company E
$600.00
Fri, May 12
Pending
There are no rows in this table
View of invoices
This is just a view of the table above, only showing overdue invoices
Company Name
Invoice Amount
Requested Date
Status
Company C
$300.00
Fri, Mar 10
Overdue
No results from filter
How can I know if I have view-bloat
If you navigate to the Doc Map in your Coda document and click on any table, you can then see all the views connected to base table.
Observed Impact: In one client optimization project, reducing 28 views on a large table to fewer filtered views produced dramatic performance improvements.
Suppose a team uses Coda to track tasks, with each task assigned to someone. There are several ways to set this up. Some methods work better for performance than others.
The wrong way
Making a separate page and view for each person causes view bloat, adds clutter to the sidebar, and means you have to update pages by hand when team members change.
Notice the left hand side bar in this image. Cluttered with 100's of pages and therefore 100's of views of this `tasks` table
The better way
Instead, create a single page of Tasks and either use a currentUser formula (learn more
) or filter-bars to filter down your information by relevant criteria.
Notice how we use just a few things like formulas and filter-bars to make this page still relevant to the user. Tricks like this can drastically increase performance and visual clutter across the document
2. Document Size (MB)
The size of your document affects how well it works and which features are available. Lets answer a couple of key questions:
How do I find my document size?
You can find the total document size by following this click path:
... in upper right hand corner > Doc Settings > Statistics
Once you find the document size you should see the total doc size along with number of rows, pages, controls, cells and more!
One important thing to know is that attachments don’t contribute the the total document size itself. You can see that although i have 1.1mb of attachments in this document, my total doc size is still 0b
So, whats a good document size
Theres no quick answer to this, but generally try to follow these limits and keep an eye out for these thresholds
Small documents:
0-50mb
Medium documents:
50-100mb
Big documents:
100-175mb
Massive documents:
>175mb
Those are generally good guardrails, here are some hard targets you should keep in mind
Remedy:
If your document is within the big or massive buckets, heres some quick tips you can take:
3. Formulas and Document Complexity
Document size in megabytes doesn't tell the whole story. Even a small doc can feel sluggish if it's packed with complex formulas. The snappiness you experience—how quickly you can navigate between pages, press buttons, open row details, run automations—is directly tied to how much calculation is happening under the hood.
Coda's formula language is incredibly powerful, and as Spiderman once said, “with great power comes great responsibility”. But every formula you add is another calculation the document has to perform. The more formulas, the more work Coda does on every change—and at some point, you'll feel it.
For example, take a formula like this:
//Find all sent invoices that are greater than $1,000
Invoices.Filter(Status = "Sent" and Amount>=1000)
That formula is attempting to find all invoices inside a Coda table of invoices that are sent and are greater than $1,000. A filter like that must run across the entire dataset so if you have 5 rows in your invoices table, the formula runs 5 times to evaluate each invoice to see if it matches that criteria. But if you have a table of 20,000 invoices, that same calculation must run 20,000 times.
Tips and best practices for formulas
It’s very common for formulas in your tables to become quite long. Or, you might find yourself needing to write a particularly complex formula that you struggle to make work.
Segmenting your formulas across columns has the following benefits:
Segmenting your formulas is where you write formulas in small chunks in separate columns, rather than writing one large formula in a single column
Take for example the table below.
A non-segmented formula
The formula that is written in the gray column is a longer and harder to understand and de-bug formula that pulls all the vowels out of the first half of a persons email.
A segmented formula
The blue columns demonstrate how to segment this same formula across multiple columns. Segmenting in this way makes the formula easier to understand, write, de-bug, and makes your doc faster in the long run
People
Name
Age
Icon
Email
All vowels in first half of an email address
Email Half Point (1)
First Half (2)
Email Split (3)
Vowels (4)
Ronnie Gross
3
rgross@live.com
o
7
rgross@
rgross@
o
Bryan Johnson
11
bjohnson@optonline.net
ooo
11
bjohnson@op
bjohnson@op
ooo
Angela Hill
37
ahill@comcast.net
aio
8
ahill@co
ahill@co
aio
Matthew Smith
77
msmith@outlook.com
iou
9
msmith@ou
msmith@ou
iou
Megan Smith
30
msmith@gmail.com
i
8
msmith@g
msmith@g
i
Daniel Ayers
18
dayers@icloud.com
aei
8
dayers@i
dayers@i
aei
Bradley Alexander
66
balexander@hotmail.com
aeae
11
balexander@
balexander@
aeae
Robert Serrano
29
rserrano@outlook.com
eaoo
10
rserrano@o
rserrano@o
eaoo
Lisa Saunders
30
lsaunders@mac.com
aue
8
lsaunder
lsaunder
aue
Robin Pugh
7
rpugh@comcast.net
uo
8
rpugh@co
rpugh@co
uo
There are no rows in this table
A formula showing an error indicator isn't sitting idle. Coda repeatedly tries to resolve it as the document changes, burning cycles in the background. Clean up errors by correcting them, prefixing the formula with // to disable it, or simply delete it.
We have already talked about how your Coda documents slow down whenever a certain formula is forced to recalculate. Now() is the king of recalculation because it can calculate up to every second or more. Try to avoid using Now whenever possible or use it only in time stamps with buttons .
At Simpladocs, we often use a technique we call formula caching for larger documents. Instead of leaving a live formula in a cell—where it recalculates on every document change—we use a button or automation to run the formula once and write the resulting value directly into the table. The formula executes, outputs its result, and then it's done. No ongoing recalculation.
This lets you control exactly when heavy calculations happen. Maybe it's triggered by a user clicking a button when they're ready to refresh the data, or maybe it's an automation that runs overnight when no one's working in the doc. Either way, you're trading real-time updates for a significant performance boost—which, for large datasets, is often the right call.
If there's one place where performance problems show up most often, it's inside Filter(). Filters are essential—they power nearly every dynamic view and workflow in Coda—but they're also easy to write in ways that quietly tank your document's speed.
The mistake we see constantly is embedding calculations directly inside the filter. Something like:
This looks reasonable, but here's the problem: Coda has to run Lower() and Trim() on every single row, every time the filter executes. If your table has a thousand rows, that's a thousand trim-and-lowercase operations—repeated whenever the document recalculates.
The fix is simple. Segment your formulas (learn more
). Create a column called something like AnimalCleaned with the formula Lower(Trim(thisRow.Animal)). Now your filter becomes:The trimming and lowercasing happen once per row and get cached. Your filter is now just comparing stored values—which is exactly what filters are optimized to do.
The underlying principle: filters should compare values to values, not run calculations. Whenever you're tempted to put a formula inside a Filter(), ask yourself if that logic could live in a column instead. Almost always, it can—and your doc will be faster for it.
4. Row Count:
Row count matters, but not in isolation. A table with 50,000 rows and two simple text columns will outperform a table with 5,000 rows that has dozens of formula columns, lookups, and conditional formatting. It’s the combination of row count and column complexity that determines how hard your document has to work.
That said, here are some rough benchmarks based on what we’ve seen:
Row Count
What to Expect
Under 10,000 rows
Generally smooth, assuming you’re not going overboard with views, grouping, or complex filters
10,000–50,000 rows
Performance starts to vary. Simple tables hold up fine; complex ones start to drag
Over 50,00 rows
Can you shove more than 50,000 rows into a table? Sure. Should you? No. If you have this much data, it's time to start thinking about alternate solutions. This doesn't necessarily mean Coda isn't the fit for you, but it should make you start thinking about how to structure your data or use different dedicated backends to only surface the relevant data in Coda, such as Snowflake, Databricks, or Supabase.
There are no rows in this table
If you have tables pushing past 10,000 rows and your doc feels sluggish, those tables are worth investigating first.
Remedy
5. Column Count and Type
Here’s a loose formula to keep in the back of your mind:
rows × columns × content complexity = table size
It’s not an exact science, but it explains why two tables with the same row count can have wildly different performance. What you put in those columns matters just as much as how many rows you have.
Some column types are hungrier than others:
Column Type
Performance Impact
Compose columns
These are the heavyweight champions of bloat. They look nice, but they consume far more space than the equivalent logic written with Format(). At SimplaDocs, we simply don’t use Compose column types. Ever.
Long text columns (Aka canvas columns)
Great for paragraphs and documentation. Not so great when you’re using them to store two-word entries across 10,000 rows.
Button columns
Sneaky. Buttons seem harmless, but when each row generates its own materialized content, the mbs add up fast.
There are no rows in this table
How bad can it get? In one client doc, we found that two button columns—just navigation and action buttons—were responsible for roughly 70% of a table’s total size. Commenting them out dropped the table from 21MB to 7MB. Twenty-one to seven. From buttons.
Remedy
6. Conditional Formatting
Conditional formatting is one of those features that feels free. You’re not adding columns, you’re not writing formulas, you’re just making things pretty, right?
Not quite. Every conditional format rule acts like a hidden formula column running in the background. The more rules you have, the more calculations your document is quietly performing on every render. And unlike actual columns, these don’t show up in your doc map, so the bloat is invisible until you go looking for it.
Here’s the thing: Conditional formatting is genuinely useful when it serves a clear purpose. Helping give a visual cue to your users about a pattern in data that they might have missed otherwise.
Highlighting overdue tasks in red? Great. Flagging invoices over a certain amount? Helpful. Color-coding status columns so users can scan a table at a glance? Fine too.
But we’ve seen plenty of docs where conditional formatting has been applied liberally with no real rationale. Formatting for formatting’s sake. If you can’t articulate the business reason a particular format exists, it’s probably not earning its keep.
A tip that’s easy to miss: you can apply conditional formatting to a base table and have it automatically inherit across all views of that table. This is far more efficient than recreating the same formatting rules on every individual view, which we see all the time. Same visual result, fraction of the overhead.
In one optimization project, removing redundant conditional formatting freed up the equivalent processing load of six formula columns. Lets go.
Remedy
7. Physical Device
This one catches people off guard: Coda document performance is partly about your actual computer or device.
When you open a Coda doc, the entire document downloads to your browser so you can work offline. That’s a great feature, but it means your local machine is responsible for handling all the calculations, rendering, and data. Coda isn’t doing the heavy lifting on some server somewhere. Your laptop is.
This explains a few things:
Remedy: Get a better computer.
8. Concurrent Usage
Alright, concurrent usage, what is this? This is simply when a lot of people are working on the same Coda document at the same time. Lots of concurrent users = big problem.
Why you might ask? Well, you’re not actually working on the same thing. It may feel like you’re on the same Coda document, but you’re not. You’re each working on your own local copy, and a whole lot of invisible machinery is running in the background to keep those copies in perfect sync.
This is not a Coda issue, this is an internet issue and it’s how all real-time collaboration works, whether it’s Coda, Google Docs, Figma, or any other tool that lets multiple people edit at once.
Each person’s device downloads the document, handles it locally, and then constantly exchanges tiny updates with a central server. That server’s job is to take everyone’s changes and figure out how to merge them without anything getting lost or overwritten.
It’s genuinely impressive when it works. But it’s also computationally expensive. Every additional person in the document means more changes flying back and forth, more potential conflicts to resolve, and more work for everyone’s devices to stay in sync. Even tools built specifically for collaboration have limits.
Figma caps concurrent editors at 200 per file (last time I checked!). Once a file reaches 500 participants, new users only see a static, non-updating version. Google Docs has similar thresholds. This isn’t a bug or a limitation of any specific product. It’s just the reality of distributed systems.
So when performance problems seem to spike during team demos or all-hands meetings, that’s not a coincidence. More people means more sync traffic, more local processing, and more strain on the collaboration infrastructure.
One important distinction: viewers and editors aren’t equal. Someone with view-only access puts far less load on the system than someone actively making changes. If you have a large audience who just needs to see the document, making sure they have view-only permissions helps keep things snappy for the people who are actually editing.
Remedy
Want some quick help and need a Coda document faster? Get in contact with us here →
✨ A big old summary:
Views & Document Structure
Document Size
Formulas
Filter() Optimization (Critical!)
Columns
Rows
Conditional Formatting
Other Tips
Diagnostic Tools
This guide was compiled from enterprise implementation experience and official Coda documentation. For persistent performance issues, consider contacting Coda support directly or .
Want some quick help and need a Coda document faster? Get in contact with us here →
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.