If you handle offline up front - you mostly get bad connection speed wins by default.
It also helps that our app really isn't intended for casual use - ex: we have very few users who just load a page or two and then leave. Mostly they'll be interacting with the page for a duration of between 30 minutes and 2 hours (sometimes as often as once a second).
So yes - very much not a "blog" or "news" or "social media" site, and I think the value proposition for most companies might be harder to sell.
But I personally find it very, very nifty that we can do this at all in a browser. 10 years ago it would have required an installed application, or a port to each mobile platform. Which is sadly still a hard sell in some of the particularly poor school districts we worked with (mostly computers from the early 2000s, if you're lucky a really cheap tablet - like a kindle - floating around)
But yes - I explicitly handle offline-only use cases, and god-damned terrible connections (think <1kb/s). In these situations, users are going to wait a long time for the first load either way.
They call in excited as all get out when they realize they only have to wait once with my application, and not once every page load. It's the difference between having a chance to grab a coffee at the start of the day, vs pulling your fucking hair out all day long.