Caching and Revalidation
Next.js의 캐싱 매커니즘
1. Request Memoization (요청 메모이제이션)
- 경로를 렌더링하는 동안 특정 요청의 처음 호출시에는 해당 결과는 메모리에 저장되지 않고 캐시에 저장되고, 그 결과가 메모리에 저장됩니다.
- 동일한 렌더링 경로에서 해당 함수 호출은 캐시가 되고, 함수를 실행하지 않고도 메모리에서 데이터가 반환됩니다. 또한 렌더링 경로가 완료되면 메모리가 재설정 되고 모든 요청 메모이제이션이 지워집니다. 따라서 재검증이 필요가 없습니다.
- 아래 컴포넌트 에서는, timeStamp와 함께 메시지를 응답하는 API를 각각 세 번 호출한 후 그 응답을 화면에 렌더링하게끔 했습니다.
- 분명 각각 API를 세번 호출한 결과이지만, 동일한 요청에 대해서는 메모이제이션이 적용되어, 실제로는 한 번의 요청만 발생하게 되고, 아래 timeStamp는 동일한 것을 볼 수 있습니다.
Memoizationed Requests:
- hello! 현재 timeStamp는 1,782,746,929,445 입니다.
- hello! 현재 timeStamp는 1,782,746,929,445 입니다.
- hello! 현재 timeStamp는 1,782,746,929,445 입니다.
2. Data Cache (데이터 캐시)
- Next.js에서 데이터 fetching 결과를 유지하는 매커니즘 입니다.
- Next.js가 네이티브 fetch API를 확장하여 서버의 각 요청이 자체적인 영구 캐싱 시맨틱을 설정할 수 있도록 허용하기 때문에 가능합니다.
- 아래는 DataCache 매커니즘의 시간기반 캐싱과 태그기반 캐싱을 구현한 내용입니다.
- 이번에도 타임스탬프를 포함하므로, 호출이 캐싱되는지 여부를 쉽게 확인할 수 있습니다.
아래에는 같은 api의 응답값을 렌더링 하지만, 새로 고침 버튼을 눌러도 각각의 캐싱시간이 지나기 전까지는 동일한 응답값이 렌더링 되는 것을 확인할 수 있습니다.
10 seconds cached
- hello! 현재 timeStamp는 1,782,746,929,445 입니다.
20 seconds cached
- hello! 현재 timeStamp는 1,782,746,929,445 입니다.
태그로 캐싱된 데이터는 revalidateTag 함수로 캐시를 무효화 시킬 수 있는데요. 아래 버튼을 누르면 revalidateTag()가 동작하게끔 구현되어있습니다.
cached Data by Tag
- hello! 현재 timeStamp는 1,782,746,929,445 입니다.
3. Full Route Cache (전체 라우트 캐시)
- Next.js는 빌드 시 경로를 자동으로 렌더링하고 캐시합니다.
- 캐시된 경로를 제공할 수 있도록 하는 최적화 기능으로, 페이지 로드 속도가 향상되는 결과를 가져옵니다.
4. Router Cache (라우터 캐시)
- Next.js에는 레이아웃, 로딩 상태 및 페이지로 분할된 경로 세그먼트의 RSC 페이로드를 저장하는 메모리 내 클라이언트 측 라우터 캐시가 있습니다.
- 사용자가 경로 사이를 이동할 때 방문한 경로 세그먼트를 캐시하고 사용자가 이동할 가능성이 높은 경로를 미리 가져옵니다. 이를 통해 즉각적인 뒤로/앞으로 이동이 가능합니다.
- 라우터 캐시를 사용하면 레이아웃은 캐시되어 탐색 시 재사용되고,페이지는 기본적으로 캐시되지 않지만, 브라우저의 앞뒤 탐색 중에 재사용됩니다.
- 서버컴포넌트인 page.tsx 파일에서,
Date객체를 이용해 라우터 캐시가 적용된 시점의 스탬프를 해당 클라이언트 컴포넌트에서 props로 받은뒤 console.log로 해당 props를 출력하는걸 보실수 있습니다 또한 아래에서도 확인해 보실 수 있습니다. - routeCachedTime: 6/29/2026, 03:28:49 PM
- 아래 버튼으로 잠시 랜딩페이지로 이동 하신후, 다시브라우져의 뒤로가기 버튼 으로 돌아오시면, 해당 스탬프가 변하지 않은것을 보실 수 있습니다. 이는 Route Cache가 작동하여 이전의 RSC페이로드를 재사용했기 때문입니다.
- 그러나 새로고침 시에는 타임스탬프가 갱신되는 것을 확인할 수 있습니다. 이는 새로고침 시에는 Route Cache가 무시되고 페이지가 다시 렌더링되기 때문입니다.
캐싱 매커니즘이 서로에게 미치는 영향
- 사실 이 글에서 다루고 싶었던 내용은 바로 이 부분입니다. App Router에는 캐시가 한 겹이 아닙니다. 매커니즘이 서로에게 영향을 미칠 수 있습니다.
- 따라서 위에 나온 각 매커니즘에 대한 설명은 최대한 간추리고 싶었기에, 생략된 부분이 있을 수 있습니다. 자세한 내용은 공식문서를 참고하시면 좋을 것 같습니다.
- 각 매커니즘의 상호작용은 아래 투어가이드로 설명을 이어 나가겠습니다.