Render Strategy Boundary

빌드 때 만들어 둔 HTML을 CDN이 그대로 준다. 첫 화면이 가장 빠르지만, 내용이 바뀌면 다시 빌드해야 한다.

요청마다 서버가 페이지 전체를 렌더한다. 항상 최신이지만 서버 작업이 끝나야 첫 바이트가 나간다.

서버는 정적 파일만 준다. 첫 HTML이 서버에서 오는 것은 맞지만 내용이 없는 껍데기라, JS가 실행되고 데이터를 받아온 뒤에야 화면이 생긴다.

정적/동적을 라우트가 아니라 컴포넌트 단위로 나눈다. use cache가 붙은 부분은 정적 셸에 들어가 CDN에서 즉시 나가고, <Suspense> 뒤의 동적 부분만 요청 시 렌더되어 이어서 스트리밍된다. 이것이 PPR이며 cacheComponents의 기본 동작이다.

Next 16 문서는 라우트 단위로 정적/동적을 고르는 방식을 "다른 프레임워크의 트레이드오프"로 분류한다. Next.js는 한 페이지 안에서 정적 셸과 동적 구역이 공존하는 스펙트럼 모델을 쓴다.

Next 16에서 experimental.ppr 플래그와 세그먼트 옵션 experimental_ppr은 제거됐다. 이제 next.config의 cacheComponents: true가 PPR을 켜며, 그것이 기본 렌더링 동작이 된다.

정적 셸은 초기 로드용 HTML과 클라이언트 내비게이션용 RSC Payload 두 형태로 생성되어 CDN에서 직접 서빙된다. 그래서 주소로 바로 들어와도, 다른 페이지에서 이동해 와도 즉시 내용이 보인다.

첫 로드에서는 Client Component도 서버에서 HTML로 프리렌더된다. 브라우저는 그 HTML로 비대화형 화면을 먼저 띄우고, RSC Payload로 트리를 맞춘 뒤 JS로 수화한다.

① 이후 내비게이션 — 서버 HTML 없이 클라이언트에서만 렌더된다. ② next/dynamic(..., { ssr: false }) — Client Component 안에서만 쓸 수 있다. 이 둘이 아니면 서버가 HTML을 한 번 만든다.

전통적 SPA도 서버(또는 CDN)가 첫 HTML을 준다. 다만 그것은 <div id="root"></div> 한 줄짜리 껍데기이고, 스트리밍이 아니라 정적 파일 한 장이다. 내용은 JS가 실행된 뒤에야 생긴다.