It's not just web apps; TCP itself behaves badly under high-latency conditions. If you have no other choice but to use high-latency links, you are better off with a protocol like QUIC that includes forward error correction. If you need to send a lot of data over a high-latency link you need to start looking at less common approaches; for example, this:
When the link is unreliable -- as it is in most wireless systems -- TCP also tends to behave suboptimally as it assumes lost packets are due to congestion. Again, if you need to deal with unreliable links, forward error correction is your friend.
Have a look at Google's BBR congestion control algorithm [1]. This is perhaps a solved problem now (although it's still not supported on all platforms, but only the side sending the bulk of the data needs to have it).
No, BBR does deliver significant performance improvements in high packet loss links. It is designed as a general purpose algorithm (not just for high bandwidth links) - they are using it on the YouTube (and other) content servers as well as between their datacenters. I believe trying to optimise delivery of content to high loss, high latency mobile users was one of the use cases they designed for.
https://en.wikipedia.org/wiki/Fountain_code
When the link is unreliable -- as it is in most wireless systems -- TCP also tends to behave suboptimally as it assumes lost packets are due to congestion. Again, if you need to deal with unreliable links, forward error correction is your friend.