A news site has article pages read by millions, a homepage updated constantly, and a subscriber account section. Should it pick one rendering strategy?

Why one strategy is the wrong question

The site contains three genuinely different problems. Forcing one answer means over-engineering the simple case or under-serving the hard one.

• Article pages: content is fixed once published, read enormously, and identical for everyone. Static generation with edge caching is close to free to serve and fastest to deliver.
• The homepage: updated continuously, near-identical for all readers. Server rendering with a short cache time, or static generation with rapid revalidation.
• Account and subscription pages: fully personalised, low traffic, interaction-heavy. Client rendering behind authentication costs nothing at this volume and keeps the personalised path off the cache entirely.

The two variables that decide it

How often does the content change, and how much does it vary per user? Content that is stable and impersonal should be computed once and cached everywhere. Content that is personal cannot be shared, so rendering location is decided by latency and interactivity instead.

The trap in between

Personalisation applied to an otherwise cacheable page destroys the caching for everyone. A single "recommended for you" strip on an article page makes the whole response uncacheable unless it is fetched separately on the client or composed at the edge.

The resolution is to keep the cacheable shell cacheable and fetch the personalised fragment separately — which is a deliberate architecture, not a default, and it is the decision that most affects both cost and speed.