Next.js 에서는 라우트는 정적이나 동적으로 렌더링 될 수 있다.
- 동적인 라우트에서, 컴포넌트들은 빌드 생성시에 렌더링 된다. 이 동작의 결과물은 후속 요청들에서 재사용되고 캐시된다.
- 동적 라우트에서는, 컴포넌트들은 요청시에 서버에서 렌더링된다.
정적 렌더링은 모든 작업이 미리 완료 되고, 지리학적으로 사용자들에게 더 가까운 CDN으로 부터 제공되기 때문에 성능을 향상시킨다.
너는 layout 이나 페이지에서 동적인 함수나 동적인 데이터 요청을 사용함으로써 동적인 렌더링을 선택할 수 있다. 이것은 요청시에 Next.js가 전체 라우트를 동적으로 렌더링하는걸 유발한다.
이 표는 얼마나 동적인 함수와 정적인 데이터요청이 라우트의 렌더링 동작에 영향을 끼치는지 요약한 표이다.
라우트가 정적으로 렌더링 될때, 데이터 요청은 캐시되고 동적인 함수는 없다.
기본적으로, Next.js 는 캐싱 동작에서 특별하게 선택하지 않는 fetch() 함수에 대한 결과물을 캐싱한다. 이것은 캐시 옵션을 지정하지 않는 Fetch 요청들은 force-cache 옵션을 사용한다는 것을 의미한다.
만약 라우트 안에서 어떠한 fetch 요청이 revalidate 옵션을 사용한다면, 라우트는 재평가되는 도안 정적으로 다시 렌더링 된다.
정적인 렌더링 동안, 만약 동적인 함수나 동적인 fetch (캐시 되지 않는) 요청이 발견된다면, Next.js는 요청시간에 전체의 라우트를 동적인 렌더링으로 변화시킨다. 캐시된 데이터 요청들은 동적인 렌더링 동안에 재사용 가능하다.
동적인 함수들은 현재 요청 헤더나 사용자의 쿠키 같은 요청 시간에만 알려질 수 있는 정보들에 의존한다. Next.js 에서 이런것들은 cookies(), headers(), useSearchParams()가 있다.
이러한 함수들의 반환값은 즉시 알려지지 않기때문에, layout 이나 Page에서 사용하는것은 요청시에 동적 렌더링을 강제할 것이다.
동적인 데이터 요청은 "no-store"나 revalidate를 0 으로 하는 캐시 옵션을 설정하는 fetch() 요청이다.
이 page나 layout에서의 모든 fetch 요청들에 대한 캐싱 옵션들은 segment config 객체를 사용함으로써 설정할 수 있다.