Pull Route Cache는 앞선 Page Router에서 배웠던 SSG 방식과 유사하게 빌드타임에 정적으로 페이지를 만들어 놓고 캐시에 보관한 다음에 브라우저에 요청이 들어왔을 때에는 캐시에 저장된 페이지를 그대로 응답해주는 페이지 캐싱 기능입니다.

Next의 페이지들은 자동으로 정적 페이지(Static Page)와 동적 페이지(Dynamic Page)로 나뉩니다.
특정 페이지가 접속 요청을 받을 때 마다 매번 변화가 생기거나, 데이터가 달라질 경우 입니다.
캐시되지 않는 Data Fetching을 사용할 경우

동적 함수(쿠키, 헤더, 쿼리스트링)을 사용하는 컴포넌트가 있을 때
쿠키

헤더

쿼리스트링

Dynamic Page가 아니면 모두 Static Page가 됩니다.

Static Page로 처리가 되어야만 페이지 캐싱이 진행되기 때문에 최적화를 위해서 페이지 캐싱을 처리하게 해주는 것이 좋습니다.
되도록이면 Static page로 적용하는 것이 좋지만, 그렇다고 해서 Dynamic Page가 항상 엄청 느리거나 엄청 안좋은 것은 아닙니다.
또한 풀 라우트 또한 revalidate 옵션이 가능합니다.

갱신 시간을 부여해서 풀 라우트 캐시에 저장되는 렌더링 결과 또한 계속해서 업데이트가 됩니다.

컴포넌트가 많아지게 된다면 모든 컴포넌트를 한 번씩 다 점검을 해줘야 하는데 어려움을 느낍니다.
그래서 페이지의 동작을 강제로 설정할 수 있는 라우트 세그먼트 옵션을 알아야 합니다.
즉,페이지 최상단에 페이지에 캐싱이나 revalidate 등의 동작을 직접 강제로 원하는 방법으로 동작하도록 설정입니다.
그 중 가장 많이 사용되는 옵션인 dynamic 옵션을 살펴보려고 합니다.
export const dynamic = 'auto'
기본값인만큼 생략을 해도 괜찮습니다.
export const dynamic = "force-dynamic";
export const dynamic = "force-static";
export const dynamic = "error";
위에 옵션들은 권장하지는 않는 옵션입니다.
기존의 메커니즘을 무시하고 강제로 설정하는 방법이기 때문에 부작용이 많아지기 때문에 사용하지 않는 것이 권장되고 있습니다.
클라이언트에 브라우저에 저장되는 캐시로, Next 앱에서 발생하는 페이지 이동을 효율적으로 진행하기 위해 페이지의 일부 데이터를 보관하는 기능을 말합니다.
라우터 캐시라는 공간을 추가해서 이제부터 페이지에 접속하려고 할 때, 여러 가지 과정을 거쳐서 서버로부터 전달받게 되는 RSC 페이로드의 값들 중에 레이아웃에 해당하는 부분의 데이터만 따로 추출을 해서 클라이언트 라우터 캐시라는 이름으로 보관하도록 자동으로 설정을 해주게 됩니다.

그러면 이제 새로운 페이지를 요청할 때에도 이전에 클라이언트 라우터 캐시에 저장해둔 레이아웃들만 그냥 그대로 사용하면 되서 마치 캐싱된 데이터처럼 그대로 레이아웃들을 사용하고 그 외에 페이지 컴포넌트나 기타 등등의 서버 컴포넌트에 해당하는 데이터들을 따로 요청해서 별도로 받아오도록 동작하게 됩니다.

공통된 레이아웃들을 서버로부터 중복되게 불러오지 않도록 페이지의 이동을 최적화해주는 기술입니다.
이러한 기술이 자동으로 Next 앱에 다 적용이 되어 있습니다.