클라이언트 라우터 캐시는 브라우저 측에 저장되는 캐시로, Next.js에서 페이지 이동을 보다 효율적으로 처리하기 위해 일부 데이터를 보관하는 기술이다. 이 캐시는 한 번 접속한 페이지의 공통 레이아웃 컴포넌트를 브라우저에 저장하여, 페이지 이동 시 동일한 레이아웃 데이터를 다시 서버로부터 요청하지 않도록 최적화한다.
예를 들어, 브라우저에서 index 페이지에 접속한 후 search 페이지로 이동한다고 가정해 보자.
브라우저는 Next.js 서버로부터 정적으로 생성된 HTML, 클라이언트 컴포넌트 번들, 그리고 서버 컴포넌트 데이터를 포함하는 RSC Payload를 받는다.
이 데이터에는 루트 레이아웃과 서치바 레이아웃이 포함되어 있다.
search 페이지는 dynamic 페이지로, 실시간 데이터를 생성한다.
이 과정에서도 동일한 루트 레이아웃과 서치바 레이아웃 데이터가 다시 포함된 RSC Payload를 서버로부터 전달받는다.
결과적으로 브라우저는 중복된 레이아웃 데이터를 두 번 요청하게 되어 비효율이 발생한다.
이를 해결하기 위해, Next.js는 브라우저에 클라이언트 라우터 캐시를 추가로 생성한다.
RSC Payload 중 루트 레이아웃과 같은 공통 레이아웃 데이터를 따로 추출하여 클라이언트 라우터 캐시에 저장한다.
이후 페이지 이동 시, 캐시에 저장된 레이아웃 데이터를 재활용하고, 변경된 서버 컴포넌트 데이터만 서버로부터 요청한다.
서버 요청 감소: 동일한 레이아웃 데이터를 중복 요청하지 않아 성능 최적화.
페이지 이동 속도 증가: 브라우저가 저장된 데이터를 즉시 사용.
npm run dev로 Next.js 앱의 개발 모드를 실행한다.
공통 레이아웃 컴포넌트 수정: (with-searchbar) 폴더의 layout.tsx 파일에서 searchbar 레이아웃 컴포넌트를 수정한다.
return (
<div>
{/* 렌더링 시간을 출력 */}
{new Date().toLocaleString()}
{children}
</div>
);
index 페이지 접속
searchbar 레이아웃 컴포넌트에 렌더링된 시간이 출력된다.
search 페이지 이동
searchbar의 렌더링 시간이 변경되지 않는다.이유
searchbar 레이아웃 컴포넌트는 클라이언트 라우터 캐시에 저장되어 동일한 데이터를 재활용하기 때문이다.search 페이지에서 새로고침을 하면 searchbar의 렌더링 시간이 변경된다.

이유
브라우저에서 새로고침하거나 탭을 닫았다가 다시 열 경우, 클라이언트 라우터 캐시는 초기화된다.
서버로부터 데이터를 다시 요청하므로 새로고침 이후에는 캐싱 효과가 없다.
클라이언트 라우터 캐시는 각 페이지에서 서버로부터 전달받은 RSC Payload 전체를 저장한다.
이 데이터에는 공통 레이아웃뿐 아니라, 해당 페이지를 구성하는 다른 서버 컴포넌트 데이터도 포함된다.
공통 데이터: 클라이언트 라우터 캐시에 저장된 데이터를 그대로 사용한다. (예: 공통 레이아웃, 공유된 컴포넌트 등)
새로운 데이터: 캐시에 없는 데이터만 추가로 서버에 요청한다.
서버 요청을 최소화하여 네트워크 부하 감소.
페이지 이동 시 공통된 데이터를 반복적으로 가져오는 비효율 제거.
브라우저에서 가능한 많은 데이터를 재활용하여 사용자 경험 개선.
클라이언트 라우터 캐시는 브라우저 측에서 공통 레이아웃 데이터를 저장함으로써 서버 요청을 줄이고 페이지 이동 속도를 최적화하는 기술이다.
효율적인 페이지 이동: 공통 레이아웃 데이터를 재활용.
Next.js 앱 기본 내장: 추가 설정 없이 자동 적용.
제한적 한계: 새로고침 및 탭 간 데이터 공유 불가.
클라이언트 라우터 캐시는 공통 레이아웃 데이터뿐만 아니라, 특정 페이지에 필요한 서버 컴포넌트 데이터(RSC Payload) 전체를 저장한다.
즉, 페이지 이동 시 중복되지 않은 데이터는 추가 요청하고, 이미 캐시에 저장된 데이터는 재활용하여 성능을 최적화한다. 하지만 공통된 레이아웃 데이터가 페이지 이동 간 중복되는 경우가 많으므로, 클라이언트 라우터 캐시의 주요 이점은 공통 레이아웃 데이터를 재활용하는 데에서 특히 두드러진다.