Full Route Cache는 전체 경로(Route)를 렌더링하고 캐싱하기 위한 캐시입니다. 각 Route에 대해 요청을 할 때마다 서버에서 렌더링을 하는 대신 캐싱된 Route를 제공함으로써 페이지 로드를 빠르게 하기 위한 캐시라고 이해하면 됩니다. Full Route Cache가 어떻게 작동하는지 이해하기 위해서는, 먼저 React가 렌더링을 처리하는 방식과 Next.js가 그 결과를 어떻게 캐싱하는지를 이해해야 합니다.

NOTE. 관련 용어
빌드 시점에 애플리케이션의 경로를 렌더링하고 캐싱하는 과정을 지칭할 때 아래 용어들이 상호 교환적으로 사용됨

• 자동 정적 최적화 (Automatic Static Optimization)
• 정적 사이트 생성 (Static Site Generation, SSG)
• 정적 렌더링 (Static Rendering)
• 점진적 정적 재생성 (Incremental Static Regeneration, ISR)

10.3.1 React 렌더링 처리 방식과 Next.js 캐싱 과정

1. React Rendering on the Server

먼저 Next.js는 서버에서 React의 API를 사용해 렌더링을 진행합니다. 렌더링 작업은 개별 Route segment와 Suspense 경계를 기준으로 하여 여러 개의 청크(chunk)로 나눠지고, 각 청크는 아래 두 단계를 통해 렌더링됩니다.

1. React는 서버 컴포넌트를 RSC Payload(React Server Component Payload)라고 부르는 스트리밍에 최적화된 특수 데이터 형식으로 렌더링합니다.
2. Next.js는 RSC Payload와 클라이언트 컴포넌트 JavaScript 명령어를 사용해 서버에서 HTML을 렌더링합니다.

이렇게 하면 모든 청크가 렌더링될 때까지 기다릴 필요 없이, 작업이 완료되는 대로 캐싱하거나 응답을 스트리밍할 수 있습니다.

2. Next.js Caching on the Server (Full Route Cache)

다음으로는 Next.js에서 Full Route Cache를 사용해서 Route의 렌더링 된 결과(RSC Payload와 HTML)를 서버에 캐싱합니다. Route Cache라는 이름의 의미 그대로 Route의 렌더링 결과인 RSC Payload와 HTML을 캐싱한다고 이해하면 됩니다. 참고로 Full Route Cache는 Next.js의 기본 동작이며, 빌드 시점에 정적으로 렌더링 된 Route나 재검증(Revalidation) 중에 적용됩니다.

3. React Hydration and Reconciliation on the Client

요청 시 클라이언트에서는 아래와 같은 작업이 수행됩니다.

• HTML은 클라이언트 및 서버 컴포넌트의 초기 미리보기(non-interactive initial preview)를 즉시 빠르게 보여주는 데 사용됩니다.
• RSC Payload는 클라이언트와 렌더링된 서버 컴포넌트 트리를 조정하고, DOM을 업데이트하는 데 사용됩니다.
• JavaScript 명령어는 클라이언트 컴포넌트를 hydration 하여, 애플리케이션을 인터랙티브하게 만드는 데 사용됩니다.

4. Next.js Caching on the Client (Router Cache)

RSC Payload는 클라이언트 측 Router Cache에 저장됩니다. 이 Router Cache는 개별 Route segment로 나눠지는 별도의 인메모리 캐시로, 이전에 방문한 경로를 저장하고 미래 경로를 미리 가져와 탐색 경험을 향상시키는 데 사용됩니다. 클라이언트 측 Router Cache에 대한 자세한 내용은 바로 뒤에 나오는 절에서 다룰 예정입니다.

5. Subsequent Navigations

이후 다음 페이지를 탐색하거나 prefetching 할 때, Next.js는 RSC Payload가 클라이언트 측 Router Cache에 저장되어 있는지 확인합니다. 만약 클라이언트 측 Router Cache에 저장되어 있다면 서버에 새로운 요청을 보내는 과정을 생략합니다. 그리고 Route segment가 캐시에 저장되어 있지 않을 경우, Next.js는 서버에서 RSC Payload를 가져와 클라이언트의 Router Cache에 저장합니다.

10.3.2 Static and Dynamic Rendering

경로가 빌드 시점에 캐싱되는지 여부는 해당 Route가 정적으로 렌더링되는지 또는 동적으로 렌더링되는지에 따라 다릅니다. Static Route는 기본적으로 캐싱되지만, Dynamic Route는 요청 시점에 렌더링되며 캐싱되지 않습니다.

아래 그림은 캐싱된 데이터와 캐싱되지 않은 데이터를 사용하는 정적 및 동적 렌더링 경로의 차이를 나타낸 것입니다. 먼저 첫 번째 방문일 경우 Static Route는 이미 빌드 시점에 서버측 Full Route Cache에 캐싱이 되어 있기 때문에, 이를 통해 렌더링 결과를 받아오고 클라이언트 측 Router Cache에 저장합니다. 그리고 Dynamic Route는 Full Route Cache를 건너뛰고 실제 Data Source에 데이터를 요청하고 렌더링하여 그 결과를 클라이언트 측 Router Cache에 저장합니다.

첫 번째 방문 이후 다른 페이지를 탐색할 경우, Next.js는 먼저 클라이언트 측 Router Cache를 조회합니다. 만약 클라이언트 측 Router Cache에 캐싱 되어 있다면 서버에 새로운 요청을 보내지 않고, 캐싱되어 있지 않다면 서버로 요청을 보내게 됩니다.

지속 시간 (Duration)

Full Route Cache는 빌드 시점에 정적으로 렌더링된 Route나 Incremental Static Regeneration(ISR) 중 재검증되는 페이지에 적용됩니다. 따라서 캐싱된 데이터의 지속 시간은 ISR이 설정된 경우 revalidate 값에 따라 다르며, 정적 페이지(SSG)의 경우 기본적으로 무기한 유지됩니다.

무효화 (Invalidation)

Full Route Cache를 무효화하기 위한 방법으로는 아래와 같은 두 가지 방법이 있습니다.

• 데이터 재검증 (Revalidating Data)
  • Data Cache를 재검증하면 서버에서 컴포넌트를 다시 렌더링하고 새로운 렌더링 결과를 캐시하여 Router Cache도 무효화됩니다.
• 재배포 (Redeploying)
  • 배포 간에 지속되는 Data Cache와 달리, Full Route Cache는 새로 배포할 경우 삭제됩니다.

캐싱 제외 (Opting out)

Full Route Cache를 사용하지 않도록 설정함으로써, 들어오는 모든 요청에 대해 컴포넌트를 동적으로 렌더링하도록 할 수 있습니다. Full Route Cache를 사용하지 않도록 설정하는 방법은 아래와 같습니다.

• Dynamic Function 사용
  • Dynamic Function을 사용하면 해당 경로가 Full Route Cache에서 제외되고, 요청 시점에 동적으로 렌더링 됨
  • Data Cache는 계속 사용 됨
• dynamic = 'force-dynamic' 또는 revalidate = 0 route segment 설정 옵션 사용
  • Full Route Cache와 Data Cache가 모두 사용되지 않음
  • 서버로 들어오는 모든 요청마다 컴포넌트가 렌더링되고 데이터가 fetching 됨
  • Router Cache는 클라이언트 측 캐시이기 때문에 계속 사용 됨
• Data Cache 캐싱 제외하기
  • 캐싱되지 않는 fetch 요청이 있는 경로의 경우, 해당 경로는 Full Route Cache에서 제외됨
  • 특정 fetch 요청에 대한 데이터는 들어오는 모든 요청마다 fetching 됨
  • 캐싱을 제외하지 않은 다른 fetch 요청의 데이터는 계속해서 Data Cache에 저장됨