렌더링 전략은 HTML(HyperText Markup Language)을 언제, 어디서 만드느냐의 선택이다. 브라우저에서 만들면 CSR(Client-Side Rendering), 요청마다 서버에서 만들면 SSR(Server-Side Rendering), 빌드 때 미리 만들면 SSG(Static Site Generation), 미리 만든 것을 주기적으로 다시 만들면 ISR(Incremental Static Regeneration)이다.
| 방식 | 만드는 시점 | 장점 | 단점 |
|---|---|---|---|
| CSR | 브라우저(JS 실행 후) | 서버 부담 적음, SPA(Single-Page Application) 상호작용 | 첫 화면 늦음, 빈 HTML이라 SEO(Search Engine Optimization) 불리 → SEO |
| SSR | 매 요청 | 항상 최신, SEO | 요청마다 서버 비용, TTFB(Time to First Byte) 증가 |
| SSG | 빌드 | CDN(Content Delivery Network)에서 바로 응답, 가장 빠름 | 빌드 이후 데이터가 낡음 |
| ISR | 빌드 + 주기적 재생성 | SSG 속도 + 어느 정도 최신 | 실시간 데이터엔 부적합 |
- SSR은 넓은 용어다. 빌드 때 만들든 요청 때 만들든 서버가 HTML을 만들면 SSR이고, SSG는 그 변형이다. 어느 쪽이든 브라우저에서 하이드레이션이 필요하다
- ISR의 흐름: 재생성 주기가 지난 뒤 첫 요청에는 일단 기존 페이지를 주고, 백그라운드에서 새로 만든 뒤 다음 요청부터 새 페이지를 준다. HTTP(HyperText Transfer Protocol)의 stale-while-revalidate와 같은 전략이다(브라우저 캐시, staleTime과 gcTime)
- Pages Router는
getServerSideProps·getStaticProps처럼 페이지 단위로 골랐다
App Router 이후
서버 컴포넌트, 스트리밍, 캐시가 합쳐지면서 "이 페이지는 SSR"처럼 페이지 단위로 나누는 의미가 줄었다. 한 페이지 안에서 어떤 부분은 정적으로, 어떤 부분은 캐시로, 어떤 부분은 요청 때 스트리밍으로 보낼지 설계한다. 그 모델이 부분 사전 렌더링(PPR)이고, 캐시는 "use cache"와 Cache Components·Next.js 캐시 계층에서 다룬다. 미리 만든 HTML을 어디서 서빙하느냐는 nginx로 SPA 배포 같은 배포 쪽 문제다.