I had a similar experience using my own web app over a satellite link (750ms+ latency) many years ago. What took minutes at the office literally took hours over the air, which I found really surprising. I knew it would take longer but it was much more than 10x longer.
This was when I first realised that UI delays have a non linear effect on productivity. The productivity loss from 10x latency increase is more than 10x. I don’t know how to explain it other than by example, but if you have multiple 1000ms delays you’re more likely to be distracted - to check your email or get a cup of tea or answer a slack message - than if you’re just ploughing through the work. That was my experience anyway.
A few years later I saw the problem in a different context (ETL), so I drew up an informal scale from small to long delays using this kind of human centred thought process, and I realised that, for example, a 1 hour delay to process ETL data is effectively identical to a 6-12 hour delay, because the user will set the process off and go do something else productive for the rest of the work day, which had a huge impact on project delivery (of course).
Once I had seen this in action, I couldn’t unsee it, and I spent the next few years getting rid of a pile of bottlenecks to make the UI performance and feedback loops as fast as possible, for example by refactoring complex operations. My proudest moment was reducing a very complex, 8 hour process down to a 5 minute (perceived) process by doing most of the work in advance, so the data was almost entirely ready before the user needed it. Our users thought the system had broken because it finished so quickly!
I’m sure there are formal studies about this phenomenon, but it was so obvious once I’d experienced it, and our focus on UI latency made a huge difference to both the quantity and quality of the work we and our customers could get work done in a given time period.