NextJS : 클라이언트 라우터 캐시

클라이언트 라우터 캐시

브라우저에 저장되는 캐시로 페이지 이동을 효율적으로 진행하기 위해 페이지의 일부 데이터를 보관한다.

클라이언트 라우터 캐시 동작과정

 

먼저 이전 게시물의 풀 라우트 캐시에 의한 동작과정을 살펴보면 다음과 같다.

 

먼저 인덱스 페이지에 초기 접속 요청을 보내면, 인덱스 페이지의 경우는 정적인 페이지이기 때문에 next 서버에 있는 풀 라우트 캐시에 인덱스 페이지가 저장되어 있는지 확인하고 풀 라우트 캐시된 데이터가 있으면 그대로 반환하고

 

서치 페이지 같이 동적인 페이지에서 풀 라우트 캐시는 스킵되고 사전 렌더링 과정을 통해 렌더링된 페이지를 반환하게 된다.

 

하지만 이런 과정을 보면 사실 비효율적일 수 있는데, 그 이유는

우리가 전달 받은 페이지 데이터는 HTML, JS Bundle, RSC Payload 등의 데이터를 전달 받게 되는데, 그 중 RSC Payload를 중점으로 설명하면 RSC Payload에는 루트 레이아웃, 서치바 레이아웃, 페이지 컴포넌트를 포함한 그 외에 나머지 모든 서버 컴포넌트가 포함되어 있다.

 

인덱스 페이지를 접속 요청하고, 서치 페이지 접속 요청을 해도 반환되는 데이터 중 그림처럼 레이아웃을 공통적으로 포함하고 데이터가 있는데, 그렇게 되면 같은 요소를 반복적으로 2번이나 전달 받게 된다.

 

그래서 next 서버는 이러한 공통된 레이아웃을 사용하는 경우 중복된 데이터를 받는 비효율을 줄이기 위해 브라우저 측에 클라이언트 라우터 캐시라는 새로운 공간을 하나 추가해서 페이지를 접속하려고 할 때 여러 과정을 가챠 서버로 부터 전달받게되는  RSC Payload 값 중 이런 레이아웃에 해당하는 부분의 데이터만 따로 추출해서 클라이언트 라우터 캐시라는 이름으로 보관하도록 자동으로 설정한다.

 

그래서 다시 정리하면 인덱스 페이지에 접속 요청을 하면 서버에서 전달 받은 RSC Payload 데이터 중 레이아웃에 해당하는 데이터는 클라이언트 라우터 캐시에 저장하고,  공통된 레이아웃을 가진 서치페이지에서 요청이 들어오면 레이아웃에 해당하는 데이터는 클라이언트 라우터 캐시에 저장된 데이터를 사용하고 나머지 페이지 및 기타 등 서버 컴포넌트에 해당하는 데이터는 따로 요청해서 별도로 받아온다.

 

클라이언트 라우트 캐시 확인

클라이언트 라우트 캐시가 잘 동작하는지 확인하기 위해서 인덱스 페이지와 서치 페이지에 적용된 공통된 레이아웃에

서치바 레이아웃 컴포넌트가 렌더링된 시간을 표시되도록 코드를 작성한다.

 

그리고 새로고침을 하면 렌더링된 시간이 잘 표시되는걸 확인할 수 있다.

그리고 서치바에 검색어를 작성하고 이동하여 그 결과를 살펴보면 시간이 렌더링된 시간이 변경되지 않고 그대로 유지되고 있음을 확인할 수 있었다.

이렇게 표시되는 이유는 위에 설명했던 것처럼 서치바 레이아웃 컴포넌트는 클라이언트 라우터 캐시에 보관되어 인덱스 페이지에서 서치 페이지로 이동했다 하더라도  클라이언트 라우터 캐시에 보관된 서치바 레이아웃 컴포넌트를 그대로 렌더링되기 때문이다.

 

그리고 클라이언트 라우터 캐시는 새로고침을 하면 없어지기 때문에 새로고침을 하게되면 시간이 변경되는걸 확인할 수 있다.

출처 : [한 입 크기로 잘라먹는 Next.js(15+) 강의]