[smacktoward]

> A lot of SPAs/"rich" web applications are not slow because of inherent performance disadvantage to that model, they're slow because they're poorly written.

I feel there is a wrinkle here, though. SPAs aren't inherently slow, but they are built around models that will ineluctably tend towards slowness unless the developer works hard to avoid that.

SPA frameworks are all about breaking your site down into small, self-contained interface elements that can then easily be composed into a larger whole. When each interface element is acting independently, though, you end up with lots of network requests getting fired as each one builds up its state independently of the others. Network requests are slowwwwww, and it only takes one of them stalling out to make the whole page feel sluggish or broken.

There are ways to architect around this problem, but they require understanding that it actually is a problem, and they take away some of the "shared nothing" developer independence that made the SPA approach so appealing in the first place. So it's not surprising that so many SPAs either don't take advantage of them or do so incompletely.

[barbecue_sauce]

To build on this, I think it may be an issue with the REST model specifically as opposed to SPAs themselves (which you may have been alluding to). It inherently encourages several small network requests. I'm not a huge GraphQL fanboy and I haven't worked with it closely, but it's a lot more conducive to batching data fetches into only a few requests. You can get around this by violating some REST assumptions like making heavy endpoints that return all of the data you know you'll need at the initial loading of an application, but then you open yourself up to criticism from pedants.