1. 렌더링 전략 결정 방법1-1. fetch1-2. dynamic1-3. revalidate1-4. fetchCache2. 렌더링 전략 별 기본 동작3. 캐싱 대상4. 캐시 엔트리 기준 값
1. 렌더링 전략 결정 방법
API Routes도 fetch cache가 동작하지만, 기본 값이
cache: no-store입니다.Next.js App Router는 페이지의 렌더링 방식을 개별 fetch 옵션과 page 옵션에 따라 자동으로 결정합니다.
- fetch 캐시 옵션
- 페이지 내의 fetch 호출의
cache,next.revalidate옵션
ㅤ | SSR | SSG | ISR | CSR |
cache 여부 | 캐시 없음 | 빌드 시 fetch 후 고정 | 빌드 시 fetch 후 revalidate 시간이 지난 후 요청 시 re-fetch | 미적용 |
cache | no-store | force-cache | force-cache | - |
next | - | - | revalidate: {duration} | - |
- 페이지 캐시 옵션 (개별 fetch 옵션보다 높은 우선 순위)
export const dynamic = '값';export const revalidate = 값;export const fetchCache = '값';
1-1. fetch
- 기본 값:
{ cache: force-cache }- 1회 요청 후 영구 캐싱
- 타입:
force-cache,no-store
- 의미: 해당 fetch 요청의 캐싱 여부를 설정합니다.
- 별도의 기본적으로 SSG로 설정된 셈입니다.
1-2. dynamic
- 기본 값:
auto- 페이지에서 사용된 fetch의 옵션을 바탕으로 결정
- 타입:
force-static(SSG/ISR),force-dynamic(SSR)
- 의미: fetch 옵션에 상관 없이 렌더링 전략을 강제로 설정
1-3. revalidate
- 기본 값:
false
- 타입: number
- 의미: 초 단위의 revalidate 기간, 해당 기간이 지난 후 첫 요청이 발생하면 비동기적으로 페이지 재생성
1-4. fetchCache
- 기본 값:
default-cache
- 타입:
force-cache,only-no-store,default-cache
- 의미: 페이지에서 사용되는 fetch의 캐시 옵션을 강제로 지정
- dynamic 옵션과 충돌 시 빌드 오류가 발생합니다.
2. 렌더링 전략 별 기본 동작
- SSR에서는 dynamic, fetchCache, fetch에서 명시적으로
no-store를 명시해야 합니다. - SSR에서 캐시를 사용하려면
dynamic=force-dynamic지정 후force-cache옵션을 지정해야 합니다.
- SSG/ISR에서는 빌드 시점에 페이지가 결정되어야 하므로, 항상 force-cache를 사용해야 합니다.
3. 캐싱 대상
- Http method: GET 인 요청에 대해서만 동작
4. 캐시 엔트리 기준 값
- URL (queryParameter 포함)
- Header 전체가 동일해야 함