Speed matters, especially when it comes to the docs, tools, and apps you use daily. You trust us with your single-source-of-truth, and it’s important that you can get to what you need quickly and easily.
That’s why we’ve prioritized improving your doc’s load time behind the scenes over the past few months. Today, I’m excited to share some details about a few updates that have improved the median load time for docs by 25%
Certain large docs can now load progressively . Previously, you would see your doc’s name and icon to know you’re in the right doc to load. Now, in larger docs, you can see all your doc’s pages and move to load the correct page first. It’s one of many first steps to improving how docs progressively load.
All docs now download content from a location closer to you so opening and loading a doc, switching pages, opening rows, and uploading images should be faster. All makers ー especially those based outside the US ー can now experience a faster Coda.
As a reminder, we also have some best practices for troubleshooting performance issues with your docs:
Performance is a top priority for us. Over the next few weeks, you can expect continued improvements to progressive loading as well as backend improvements to your select lists, people columns, and lookup columns to improve doc load. And we know that performance is more than a load time so we’re also working to bring you even bigger improvements and responsiveness. We’re looking forward to showing you what’s up next!
Great! In addition to this, the biggest performance and scalability issue for us is the file size limits on the cross-doc API. Increasing that file size limit would help us immensely.
We’re on it – we’re working on some upcoming size optimizations that will reduce the number of docs that hit API limits, and also further decrease load times.
Please consider also something about the app version loading speed. For growing docs and database I am using where the form entry is key for me and are really convenient on phone the app quite often crashes or takes many seconds to load and calculate. If you want you can check my doc
Thanks for updating us on this. I can see that you are working really hard on improving performance. I am really grateful to your team for this.
I want to understand whether we will ever get to the stage of having multiple tables of 50,000 rows in one document. I have a use case scenario that requires a fair amount of reference data. For example, my product database alone is around 35,000 products. If you are working towards this kind of scenario then I can start with one of my use cases otherwise I may have to look elsewhere.
First you need to partecipate in the beta of coda’s Forms, see this post for information :
They basically allow a “fast input” of data without the need of loading all the doc, and for mobile uses those are perfect!
The only temporary problem of forms as now is that you can use them only in new docs, it’s a little bit limiting but completely understandable as seen as they are a super-new feature
My personal suggest is to get familiar with them and in some times they will be available on all docs
I’m planning to use them exactly as a “fast input of data in big docs”, and an incredible addon to forms could be the possibility to edit inputs after sending them, this will really allow makers to build custom light version of docs
Shaheed, thanks for the question. Performance is a top priority for our team, and we will continue to be investing in improvements that expand what kinds of docs Coda can scale with. As Nathan mentioned we are actively working on a number of improvements to store the data in your doc more efficiently. This will definitely help with some of these larger doc scenarios. As you can imagine, there are a lot of factors that go into the performance of a doc including how it is structured. At this moment in time we are not explicitly focusing on docs of that scale, but we will get there. Happy to discuss the specifics of your use case more if you would like to DM me.
hi Mario, I created such a logic using a combination of Paperform, Zapier, Coda and MailJet. The set-up is not complicated, but takes a bit of time for you need to align all the fields and set the triggers right (new rows).
What I did not solve 100% is filtering out a table with only unique and last updated rows. That is a side project in progress for it requires quite a bit of reflection. But aside this, users love to update their data in a single click (I provide the URL in the email I sent out via Mailjet)
I’ve checked the services you are using and i didn’t know Paperform and Mailjet, the first one have such a cool UX in designing forms, coda teams should definitely copy something from it (the possibility to customize H1, H2 ecc with font and color is way better than current integration in my opinion! and could be a first move towards custom layouts!) Then Mailjet looks like a robust integrations of personalized emails, i’m sure that your setup act and looks super cool
I think that my use case is a little bit different, i’ll tell in you just 2 rows, also because we have gone a little bit off topic here (sorry @adamginzberg64 )
My doc is the app i’m “selling” to users, it is a nutritional manager for pets and to work on it and to use the App one have to interact with that docs (or published doc to be precise), but for daily routine input (a perfect example is “insert your pet weight daily to keep track of it”) it’s a non-sense to load also a 6000+ rows with 150+ column of the nutritional database, that took about 1.30 minutes…they would probably prefer to annotate it on paper (on desktop, on mobile this would be around 5/6 minutes, before this update was 2.20 minutes btw, so thanks )
Here using Forms from coda would be a game changer, and i personally prefer to not integrate too much external services because of 2 reason, the first one is that they have some limitations in rate and they add pricing to the service, and second if something change you could have to “re-grab” the concept and make it work again! And depending on how many users and how much they use the forms daily one could really get into limitations!
In any case your setup looks super creative and i’m honestly curious to dig into the “post-filtering” of data in coda, what do you think of creating a new post in the community to work with everyone who wants on some ideas to make it work as you want?
In the meantime, thanks for sharing your setup and inspiring me
Good idea, I’ll set it up later in the day. I guess we all need once in a while tables that filter out outdated rows, while meanwhile the user can update ‘their row’. Also to avoid that tables become to large to handle.
Hehe.
:
(sorry 
)