They really don’t have to be. Unfortunately a lot of them are just built really badly, by people with fast hardware and gigabit networks. With good code splitt

They really don’t have to be. Unfortunately a lot of them are just built really badly, by people with fast hardware and gigabit networks. With good code splitting, which is supported basically out of the box by Webpack and all the big front-end frameworks, I would argue a well-written SPA transmits less data in the long run than a fully server-rendered app. The initial payload is bigger by a few hundred KB sure, but after that: - Like server rendered pages, you still only load pages on demand, thanks to code splitting - Unlike server-rendered pages, you can cache everything except the data that changes, because it’s JavaScript not HTML. Yes you’re still making a request for fresh data on every page load, but while the code is cached you need only download the raw data itself. You’d have to be really clumsy to send a JSON payload bigger than a full HTML document containing a rendered representation of the same data. Of course, this only really applies to apps. Static or infrequently changed content, you’re better off either server rendering or just serving static files. You can also make the argument that it would be more efficient to serve mostly static HTML, with the bare minimum JavaScript required to fetch new data, but ultimately everything is a trade off :)