[valisystem]

Just to nuance your 1) points about server side rendering, with pro-points :

• you only need html and css loaded to show content to your user, and js loads while the user is watching content, js has some time to be ready on first interaction.

• still feels slower than showing stuff with only html+css

• for pages content that changes a lot, if you rely on cdn for html pages, you need to update content with js on page load and you either ends up with a splash wait-while-we-are-loading or a blinking christmas tree.

• if your html is small enough, the cache checking round-trip is not that faster than loading content, while a JS rendering will need cache round trip AND data loading round trip. You can eliminate some html round trip with cache expiration, but at the expense of reliable deployments.

• still, JS rendering/update can be slower than server side CPU, especially on mobile devices.

[Illniyar]

There is a very simple way to get both maximum cache (without cache round trip, I.E. the ETag or Older-then) and reliable deployments - use version identifiers on the url and no expiration cache.

The only thing that the browser should always load is your base html, and have a single linked js/css that is concatenated and compressed, whose url changes every deployment - most web frameworks already have a way of doing it (Rails, Django etc...).