Tables should be caching

It’s very bad to work with a lot of rows when the tables never cache anything. If we scroll back and forth it keeps reloading every 30 rows or something. It’s kinda sad because the databases are the central part of Coda experience.


Even the app and selectable lists are cashing correctly. Am I missing something?

Hi @Guilherme_Salles,
what do you actually mean by caching?

Docs already hold all the data locally (i.e. in the client browser) within the json docs.
If you have some delays, it might be for some hard computations (or formatting) in the rows.

Have you tried to debug you doc through “debug calculations” (

Do let me know if this helps.

I wanted to jump here as I have similar “troubles” (on Chrome actually. Didn’t test this on Firefox or Safari) :confused: .

When working and scrolling through a section of one of my doc, the whole page goes “blank” and the tables have to reload themselves (but I can’t say if it happens every times or just once in a while), looking like Chrome is not “caching” anything.

There’s not a lot of datas (yet) in that section. There are only 2 tables. A “big” one (45 fields but only 19 rows so far) and a small one.

I admit that there’s a lot of LookUp going on there and some (not-that-heavy) pictures.

As for the Debug Calculations, I tried more than once but for some reasons, it stays stuck at this state.

Only when I click on “Clear” something shows up (but it doesn’t say anything about where the problem might come).

Look at the @Pch example. This is exactly the problem I have. I tested in other browsers (including Safari) and it happens everywhere. Even with simple tables. I was reluctant to migrate from Notion to Coda mostly because of this. You see, I can’t simply use CTRL + F to search content on the table because it can’t retain the information outside the screen. Coda is incredibly smart on formulas and formatting, but navigation is such a big problem. Just for clarifying, it’s not a personal computer performance problem. My devices are a pc with 32gb of RAM, octacore and a Macbook Pro 16”. Also 120Mbps internet connection. At least I know now that I am not the only one with this problem.

I checked in with our engineers and can pass along the summary of why Coda works this way currently.

Coda is complex, especially with our grids. It takes a good bit to make everything work the way that it does in a doc and rendering too much at one time can cause the browser to run really slow. So we put off rendering to keep all other actions running faster. That’s why you see things re-render as you scroll up and down quickly.

Another thing that was happening when we had tried consistently rendering rows as you scrolled was it would stutter and you would lose smooth scrolling.

Something else that is difficult to tackle with large tables and scrolling is bookkeeping when scrolling fast where rows 1-10 and 200-210 might be rendered, but those in the middle were skipped over. So how do we render what’s on screen first to serve it quickest while letting other stuff in the middle catch up.

This isn’t necessarily something that Coda will be dealing with for good, it can be improved. But the work to improve it is time consuming and a big undertaking. Figuring out the best time to do this work is tough, but something that we’re aware of and keeping an eye on.

I’ve used various table search strategies when I need a replacement for “Cmd f”. I know these aren’t as quick as a keyboard shortcut, but they have worked really well for me here as we continue to grow the product.


Thanks a lot for the clarification! Just one more question that remains. Why the mobile app can handle it the way it should? In the mobile app and mobile browser it loads 30, than more 30 and so on and it keeps everything in memory and this reloading thing doesn’t happen.

Bookmarking this :grin: ! It might be useful at some point :grin: !

And thank you for these technical enlightenments !

Any idea though about the Debug Calculations tool being stuck like that :thinking: ?

@Guilherme_Salles, the mobile view is “paginated” so it’s loading 30 at a time and isn’t really free scrolling. This works on mobile mostly because you’re likely running through a few hundred rows at best and not thousands. We do have room for improvement here and it’ll come in due time. There are some other updates on the way first though as we continue building out the product and feature set.

@Pch, the debug tools are a helper and not necessarily a fully fleshed out feature, so there are some things that need to happen in the right order for them to work. If the debug starts after a process is already running, I’m not sure it’ll pick it up.

1 Like

Thanks for that clarifying precision about the Debug tool :grin: :+1: !