Grist is getting slower and slower for us each month. We have the old plan and were told that 100,000 rows would not affect us. However, as time goes on Grist is becoming slower and slower. I have made some changes, because we were told that the access rules is what is causing Grist to slow down a bit. But this is getting concerning, because we cannot even work in it.
We constantly see “still working” for up to 10 minutes somedays and other days several minutes. Today is really bad. We cannot work in it at all. I have reloaded the database several times.
Can you please tell my why Grist is getting slower other than the access rules, which I am working on.
On the Pro Legacy plan, there is a soft limit of 100,000 rows. The real limit is on data size. Grist works best up to around 20MB. Past that point, documents will begin to load more slowly. Your document is currently at 93MB.
I also ran the Formula Timer to see if anything there was taking too long. The References column in the Invoices table is taking 25s to calculate. I know this calculation is needed to generate the Invoice so we can’t remove it and it’s as efficient as it can be. It’s taking so long because there is so much data. I would recommend creating a historical copy of the document and then clearing out old invoices from the current working version. For example, I’ll often tell users to split data up by year. Create a copy of the document to be all 2022 invoices (deleting all other invoices from this copy), create another copy to be all 2023 invoices (again, deleting all other invoices), and so on. You could split it in whatever time frame makes the most sense to you. Splitting the document up and removing historical data from the current, working copy would shrink the data size and also shrink the calculation times you are seeing. Be sure to also remove records from the Items View table that are not associated with the Invoices noted in that copy (so delete 2022 invoice items from the 2023 copy).
References column in the Invoices table is taking the longest to calculate by far (25s). The C_Num column in the Matters table is second longest at 6s but this is a dot notation formula and as efficient as it can be so no changes recommended there. The next formula, taking 4s to calculate is the Check_ column in the summary table Items View (grouped by Invoice). It looks like the Check_ column no longer exists in the Items View table so this formula is giving an error. I would recommend deleting this formula and that would save 4s of calculation.
You can check other formulas if you’d like. The Formula Timer page is linked below. After running the timer, sort the Total Time (s) column Z>A so formulas that take the most time are listed first. It’s worth looking at any formula that takes longer than 1s to calculate but since your document has so much data, I think anything about 3s is worth reviewing to see if it can be made more efficient.
It seems the size limit is related to the entire account, not individual document. I also have the old plan and experience similar slow down. Whenever a page is inactive for a while, getting back to it usually takes a good 10-30 seconds to show the page again. I have replicated the database’s structure and started fresh with only 155 rows of records and it acts the same way. But I have several documents and some are pretty big. When I deleted some of the bigger documents, the smaller ones starts faster again.
The size limit only applies to individual documents. Performance shouldn’t be impacted by other documents on your account unless you’re self-hosting Grist, in which case having multiple documents open by users on your self-managed instance may impact performance across all documents.
Have you tried using the formula timer’s reload option on the replicated document to see if there are any slow formulas?
There is a slow formula, but it’s not overly complicated. That table only has 4 records and it takes 0.6s total to load (according to the timer, not the actual time I experience).
Sure, I’ve shared 2 documents. I just deleted a whole bunch of documents and the smaller one (155 records) seems faster although the timer still shows 0.6s+. The bigger one is still sluggish. It has 9K+ records, 9MB data, and 1.3G attachment. It’s not too bad for me in North America, but is quite slow for my team working in Asia.
I did notice the larger document was quite slow to load. The issue with this one is the attachments. Data + Attachments in a single document are limited to 1GB but yours is at 1.3GB total. You can read about limits in Grist here: Limits - Grist Help Center
I see two attachment columns in your document. One is located in the tasks_daily table but only has two total image uploads, not causing any issues at this point. If you think this column will eventually contain many more images, I would recommend storing the image on some storage site like Google Photos or Imgur. You could include the image URL in a column and preview it easily using our Image Viewer custom widget.
The second attachment column is in the studies table and about 1500 rows have a PDF uploaded. I would recommend storing these PDFs elsewhere like Google Drive or Dropbox then include a link to the document in this column. We do have a Dropbox Embedder custom widget that may work nicely for this: Custom - Grist Help Center
The second document, Styles loaded quickly for me but I did see how a formula was taking 0.6 seconds. When you fix this, another one pops up. All of these had errors in the formulas which was causing the increase in calculation time. So there are a few different issues below to be resolved.
Fix the references in the to column of the Internal table that are giving errors. There are three. You can easily filter to these three records by filtering the column to only those with #Invalid Ref errors;
In the SEO table, the impact column contains conditional formatting that gives errors when there is no value in the impact column. Update these to begin with $impact and so these conditions will be false if there is no value.
I’ve fixed all the issues, removed all the attachments and fixed the errors. Although the timer now shows much shorter time, it feels even slower than before when refreshing or activating after being away for a while. Any idea why?
I’ve tried opening your document on multiple occasions and it has loaded quickly every time for me. I wonder if local factors like internet speed could be playing a role. Do you notice slowness in other websites?
Next time you load the document and notice slowness, could you give me the time stamp when it occurs (with time zone)? I can have our dev team check the logs.
