Rendering strategies
Static, dynamic, cached, and streamed are not competing application types. They are tools you can combine at the boundary that needs them.
Static work is a good fit for stable public content
Documentation, portfolio pages, public articles, and stable marketing content are good candidates for reusable output. If the result does not depend on each request, repeating the work for every visitor is wasteful.
Static rendering is about when output can be produced and reused. It does not automatically mean the browser will keep the HTML forever.
Dynamic work exists because the request matters
Account state, request-specific headers, permissions, and genuinely real-time information can require work at request time. That is not a failure to optimise; sometimes freshness and identity are part of the feature.
Keep the dynamic boundary as narrow as the product allows.
Most interesting pages are mixed
A product page may have reusable product copy, cached reviews, and a request-specific cart indicator. Treating the entire route as one freshness unit throws away useful flexibility.
Cache Components are designed around this idea: stable work can be reused while runtime work remains dynamic.
Choose by dependency, not fashion
Can you explain “Rendering strategies” without reaching for the API reference?
Describe the main trade-off, one failure mode, and the decision you would make in a real project.