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
},
});