Performance issue when agreeing with ID - very slow on both web and iOS app


I have been happily using both the site and the iPhone app since last summer, and most extensively since November. I really love them.

I noticed performance of both web and ios-app is oscillating at different times of the day or week.

However, overall, it is incredibly slow to add annotations, to agree with an ID or to favorite an observations on both web and ios-app, probably worse on the phone. At times it can take 30-60 seconds for the page to refresh after making any of the changes mentioned above to an observation

Additionally, at times, the upload using the website can be also incredibly slow. But it varies with time of the day and of the week.

I was happy to see the announcement about upgrading the systems, but unfortunately it doesn’t seem to help with these performance issues.

Platform: Website on MacOS and iOS 14.4 on iPhone X

App version number: 3.1.1

Browser: tried Firefox and Chrome on the MacOS. doesn’t seem to make a difference

Description of problem:

Step 1: Go to one observation

Step 2: Agree with ID or choose “Alive” in Annotations or Favorite it

Step 3: Wait for 30-60 seconds each time…


Hi @codrin_bucur, welcome to the iNaturalist Forum! Thanks for filling out the template. I’ve noticed slow annotation loading times for over a year when adding on the website. As far as slow loading times for adding agreeing IDs, I have never experienced anything as extreme as 30 or 60 seconds. I just tried agreeing with an ID on iOS and it took 6 seconds to save. I agreed with an ID on the website from an individual observation page and it took 8 seconds for the green spinner to stop spinning.

This issue about very slow annotations has been reported in the past though, so let’s focus the discussion about that in one place:

I’m not sure this is necessarily a bug per se, but will leave this open for now. Keep in mind that iNaturalist continues to approximately double in size every year, so there are commonly issues with scaling since the number of staff and allocated resources haven’t also doubled!


Hi @bouteloua,

Thanks for the quick reply.

As I said, this behaviour fluctuates a lot. I just did another round of tests on both devices (30 minutes after the previous ones) and I had about the same performance like you (6-8 seconds)

I don’t know what is causing this but performance is different all the time.

As an IT person, I would say that it certainly looks like scalability issues with the implementation, maybe related to the DBs or storage performance. I also noticed that adding annotations seems to have some sort of asynch implementations which might allow to submit multiple changes in “parallel”, however adding 2 annotations subsequently (while the 1st is loading) results in only one annotation being added, the other is lost.

I looked at the other discussion thread but it is old, with less detail and doesn’t seem to have a resolution, hence I reported it here.

I can certainly sympathize and fully understand that if the volume is doubling every year, and the staff is small, this become a challenge. I just hope it won’t become the victim of its own success, since the idea and the site/app are wonderful.



I have noticed this too. I am pretty sure that in times past, you could just hit “agree” and move to the next ID and you didn’t need to wait for the agree to load before moving on. Having to wait, and it taking 10 seconds or so, is a big slowdown in a large batch of IDs. I don’t have anything to add, just acknowledge I’ve noticed. Thanks for posting.


You don’t need to wait for the identification to update visually, once you press the agree button or the “a” key, it will register in the system, and you can move on to the next observation.

1 Like

I noticed that occasionally, I added a ID or comment, which fail to upload (or register). Afterwards I may or may not noticed this. This is on the national University network so it is reasonably fast (for the dark continent). This has been ongoing from 2020.


I’ve had the exact same thing. I hit agree for an observation and, even after waiting 10-15 seconds in some cases, when I hit refresh that ID did not save and it was as if I never hit agree


If I have to, I would rather wait, and make sure that iNat is keeping up with me.

I have noticed if I check Performance, that the CPU shot up to 100% when I open iNat. Too data heavy for my old laptop? Perhaps we need an option in our settings for s l o w loading to be supported. (I use that for Gmail for example)

It should be like this but it doesn’t always work. If you move on and come back. Or you hit “agree” and then go to add an annotation, either the “agree” is missing or the annotation is missing. Actually the asynchronicity / parallelism doesn’t seem to work most times.


It’s an old topic, but if you add it or click agree in id mod and you see the spinning wheel, it means it’s getting added, if not – do it again and it will be added, just go further as fast as possible and better to not come back very soon, then after refreshing page you can see ids where added, I never lost a single id where system shown me it was adding, but it can dissapear if you clicked “not good enough” for the system or error message appears.

Website speed is currently a major limitation, because it slows or disrupts the central features of observing and identifying. Although it seems complex and may require investment to correct, certain areas and causes are known. It may on the one hand require some overhaul of core site elements. On the other it seems possible that at least some of the many additional features often being added are contributing. I’d suggest iNat make a time-sensitive multi pronged move to address the core speed issues (whatever it requires, which may not be easy), and potentially put the addition of more peripheral features on hold (if any do affect speed). Speed needs to be improved to do anything, including using new or peripheral features, so makes sense to prioritize.

Another example is that taxon changes slow speed. For curation, the need to add species or revise their status (deviations from external sources like Catalogue of Life) is much more common than may have been expected. Given that, it would be worthwhile for curators/users to ask sources like COL if they’d instead mostly add/update any needed taxa first, if iNat users sent them the needs and citations. That way iNat would mostly just receive the taxonomy downstream, reducing the need for so many deviations. Taxon changes are just one cause of slowness though, and other causes may be larger. In the meantime, users could potentially increase their speed somewhat if they’re willing to pay more for higher-speed wifi. Some also find that the site is faster during what the night hours are for the majority of users.

I know what you mean but am unsure this can be completely relied on. In my experience this has happened before and not ended up saving, and it may also depend on wifi speed. But I do think the concept of “if you click the ID, it will save” would be a good goal for iNat to reach in improving the site speed overall.

Maybe, generally it’s good for me, I got through the whole page, then click on review all and wait until it ends up spinning, then I hope enough time went by to get all saved, but I have to be honest in last month it shows more of “didn’t save” messages, but at least those appear.

iNat did say they are employing someone to help them scale up.

1 Like

I know what you mean. It’s difficult to test whether that truly always works, and works in all wifi speeds. I currently have “standard” wifi (US) which is somewhat slow for iNat but fairly fast for others. So, your method may work, I’m unsure either way.

1 Like

I recently confirmed I did lose some unknown number of IDs due to the spinning wheel delay, during CNC when the site speed was even slower than usual. That’s unfortunate because people can’t even know that their IDs may not all be saving.