Client rendering doesn't have to be so bad... I actually did do it as an optimization back in the dialup days. React is pretty nice, and if you really want to reduce payload, you can build against inferno or preact for similar results at a smaller payload, but since React packaged JS is usually less than a single moderately sized image, it's really less of an issue.

Although that doesn't mean to go ahead and throw in lodash + underscore + ramda + jquery + jquery extensions all on top of react/redux. Just because you're using a modern framework, doesn't mean it needs to be huge. You can build a basic app with preact and min+gz hitting a total size around 20-30kb.

Yes, that's more than server-rendered simple AMP-style html... on the flip side, you don't have to round trip for every screen either. It's also a LOT smaller than some of the behemoths out there, and even then, a lot of the time Images are the biggest hit in bandwidth.

I find it really fortunate. SPAs can use much much less data for the same content, which is a big plus when you're on a data-limited connection, as most users in the developing world are. If you spend much time on a site they also demand less CPU and thus less battery life (vdom updates are less intense than new page renders), which helps when you're on a mobile connection, and they feel much more responsive when you're on a high-latency connection, which you are again if you're in the developing world or on mobile. Server-side rendering feels like getting a faster and lighter initial load in exchange for heavier, slower, more battery-draining usage overall.