SSG와 빌드 타임이나 런타임에 리벨리데이션(revalidation)되는 페이지들과 연관되어 있습니다.cache-control 헤더들이 자동적으로 적용되도록 해줍니다.revalidate에 작성된 값은 페이지에 포함된 fetch에 cache-control revalidate 값으로 자동 적용됩니다. ⚠️하지만, force-cache 옵션이 지정된 fetch의 경우, 자동 설정이 무시되어 적용되지 않습니다. 직접 revalidate을 추가해 줘야 합니다.)next build시간을 소요하지 않고 많은 양의 페이지들을 처리합니다.generateStaticParams 추가 시, dynamicParams는 true로 설정됩니다.generateStaticParams에 포함된 parms의 페이지만 생성하고.generateStaticParams에 포함되지 않은 요청은 그때 생성하여 revalidation이 적용됩니다.Next.js 공식 문서 - ISR
Next.js 공식 문서 - revalidate
Next.js 공식 문서 - dynamicParams
Next.js 공식 문서 - Intercepting Routes


위 그림에서 알 수 있듯
영구적(재검증 가능하지만)+서버에 위치한 캐시는 Full Route Cache와 Data Cache임을 알 수 있습니다.
하지만, Full Route Cache는 HTML and RSC가 저장되어야 하기 때문에 SSG/ISR처럼 경로 자체가 가능할 때 사용되는 캐시 저장소임을 알 수 있습니다.
그렇다면, SSG/ISR처럼 들어오는 요청들에 캐시 된
캐시 할 수 있는 방법은 Data Cache만 가능함을 알 수 있습니다.
Next.js 공식 문서 - Caching in Next.js
다시 돌아와서 해결하고 싶은 문제를 살펴봅시다.
Intercepting route 를 ISR처럼 만들 수 있을까?
ISR이 될 수 있는가?
➡️ 위 Intercepting route 정의 부분에서 확인했듯,
Intercepting route를 통해 보여주는 컨텐츠는 실제 다른 경로의 페이지를 보여주는 것이 아니라
현재 경로에서 주소만 변경시켜주는 하나의 편의 기능입니다.
그렇기 때문에 ISR 페이지로 캐시 될 수 없습니다.
ISR 처럼이란 무엇을 의미하는 가?
➡️ ISR 처럼이란 요청을
자, 그럼 이 문제들을 해결해 봅시다.
위에서 정리한 Next.js의 캐시 저장소들을 다시 살펴봅시다.
저장소의 위치 + 지속 시간 을 기준으로 저장소들을 나눠보면 아래와 같은 분류가 나옵니다.
서버에 위치하고 오랜 지속 시간으로 가지며 많은 요청에도 같은 캐시를 사용할 수 있는 캐시 저장소는
Full Route Cache와 Data Cache 2가지입니다.
하지만, Full Route Cache 는 HTML와 RSC payload만 저장이 가능하기 때문에 SSG/ISR과 같은 경로 자체의 캐시가 저장될 수 있음을 알 수 있습니다.
그렇다면, 사용할 수 있는 저장소는
Data Cache 임을 알 수 있습니다.
Data Cache 캐시 저장소를 사용하기 위해서는
Next.js의 fetch 옵션에서 cache: 'force-cache'을 지정해 주면 됩니다.
이렇게 저장된 데이터 캐시는 Next.js의 fetch 옵션의 next.revalidate을 사용하여 재검증 시간을 지정해 줄 수 있습니다.
fetch('url', {
cache: 'force-cache',
next: {
revalidate: 86400, // 1 day Unit:second
},
});