ssr-ssg

# SSR / SSG / Hybrid Rendering (Deep Workflow) Rendering is an **architecture decision**, not a framework toggle. Guide users to map **freshness**, **personalization**, **cost**, and **complexity** per route—avoid “SSR everything” or “static everything” by default. ## When to Offer This Workflow **Trigger conditions:** - Choosing rendering strategy for marketing vs app shell vs dashboards - SEO + auth + dynamic data conflicts - Slow TTFB, stale content, or expensive server work per request - Hydration bugs, double data fetch, or client/server environment mismatch **Initial offer:** Use **six stages**: (1) route & data classification, (2) choose rendering mode(s), (3) data loading & cache layers, (4) streaming & partial SSR, (5) hydration & client boundaries, (6) validate (SEO, perf, ops). Confirm **framework** and **hosting** (Node server, serverless, edge). --- ## Stage 1: Route & Data Classification **Goal:** Each **route** has clear **freshness**, **auth**, and **personalization** needs. ### Dimensions - **Public vs authenticated**: can HTML be shared or per-user? - **Update frequency**: static marketing, hourly blog, real-time inventory - **Source of truth**: CMS, DB, API with rate limits, edge KV ### Output A **matrix**: route pattern → public/private → max staleness acceptable → personalization level. **Exit condition:** No ambiguous “dynamic page” without stating **what changes** and **how often**. --- ## Stage 2: Choose Rendering Mode(s) **Goal:** Pick **SSG**, **SSR**, **ISR/ondemand revalidate**, **CSR with SSR shell**, or **edge**—per route. ### Heuristics - **SSG / prerender**: stable content, best TTFB/CDN cache, great SEO—watch **rebuild/revalidate** story - **SSR**: must reflect **request-time** data (A/B, geo, auth gating) or **strict freshness** - **Client-heavy**: acceptable for **post-auth** app surfaces if SEO not needed - **Hybrid**: static shell + client islands; or **static generation** with **server components** for parts (framework-specific) ### Trade-offs - SSR **cost** and **latency** vs SSG **staleness** - **Edge** rendering: geography and limits (CPU, Node APIs) **Exit condition:** Documented **per-route** strategy with **rationale**. --- ## Stage 3: Data Loading & Cache Layers **Goal:** **One coherent story** for where data is fetched and how it is cached (CDN, full-page, data cache, edge). ### Practices - **Cache-Control** / surrogate keys / tag-based invalidation—align with framework primitives (e.g., `revalidate`, `fetch` cache) - **Deduplicate** requests between server and client where frameworks allow - **Avoid** accidental **private data in shared cache**—vary by cookie/auth correctly or disable cache ### Stale-While-Revalidate - Great for **mostly fresh**—document **user-visible staleness** acceptance **Exit condition:** Data flow diagram: origin → edge → browser; **invalidation** owner identified. --- ## Stage 4: Streaming & Partial SSR **Goal:** Improve **perceived performance** with **suspense/streaming** where supported. ### Guidance - Defer **slow** fragments; show **skeletons** with accessible semantics - **Ordering**: ensure critical **LCP** resources not blocked by deferred junk - **Headers**: understand **chunked** response implications for intermediaries **Exit condition:** Slow dependencies **isolated**; UX fallbacks defined. --- ## Stage 5: Hydration & Client Boundaries **Goal:** **Correct** interactive UI without **double work** or **mismatches**. ### Checklist - **Server/client** component or module boundaries (framework-specific) - **useEffect** vs server fetch duplication—**waterfalls** - **Environment**: no `window` on server; no **secret** APIs in client bundles - **Hydration mismatch**: locale, random IDs, time—**suppress** or **serialize state** **Exit condition:** Known **interactive islands** listed; mismatch risks mitigated. --- ## Stage 6: Validate (SEO, Performance, Ops) **Goal:** Rendering choices **show up** correctly in search, metrics, and logs. ### SEO - **View source** / rendered HTML for critical content; **meta** and **canonical** per mode - **Auth**: soft paywalls—decide what crawlers see ethically and technically ### Performance - **TTFB** vs **FCP/LCP**; **server time** vs **edge cache hit** - **RUM** segmented by route and cache hit ### Ops - **Cold starts** on serverless SSR; **concurrency** limits; **regional** failover --- ## Final Review Checklist - [ ] Per-route rendering choice documented with freshness/personalization - [ ] Caching and invalidation story is explicit and safe for auth - [ ] Streaming/skeletons don’t harm LCP or a11y - [ ] Hydration and env boundaries verified - [ ] SEO and RUM validation for top templates ## Tips for Effective Guidance - Name **staleness** in seconds/minutes—“real-time” is rarely real-time. - When user uses **Next.js**, tie advice to **App Router** vs **Pages** semantics explicitly if known. - Warn: **edge** ≠ full Node—**API surface** differs. ## Handling Deviations - **SPA-only**: focus on **meta** for landing routes and **prerender** for marketing if added later. - **No server**: SSG + client or **external** prerender service—be honest about limits.