Router Cache

드디어 마지막 캐시를 소개드리게 되었습니다.

이번 캐시는 생각보다 익숙한 내용일 수도 있습니다! 그 이유는 공식문서에 따르면 라우터 캐시가 Client 캐시 또는 Prefetch 캐시라고 불린다고 하는데요.

물론 좀 더 디테일하게는 Prefetch Cache는 Prefetch된 경로를 참조하는 반면, Client 캐시는 방문한 경로와 Prefetch한 경로 모두를 포함하는 전체 라우터 캐시를 참조한다고 하네요.

디테일하게 파고들면 어렵겠지만, 간단하게 정리하자면 방문한 또는 방문 할 페이지의 HTML/RSCP를 저장하여 저장한 페이지를 방문할 시 빠르게 로딩하도록 도와주기 위한 기능이라고 보시면 됩니다.

특징

export default async function Page() {
  const blogData = await getBlogList()

  return (
    <div>
      <h1>Blog Posts</h1>
      <ul>
        {blogData.map(post => (
          <li key={post.slug}>
            <Link href={`/blog/${post.slug}`}>
              <a>{post.title}</a>
            </Link>
            <p>{post.excerpt}</p>
          </li>
        ))}
      </ul>
    </div>
  )
}

예시와 함께 보겠습니다.

위 코드에서 보이듯이 ‘동적’ 경로도 저장됩니다.

저장되는 시간은 다릅니다. 정적 경로 기준 5분, 동적 경로 기준 30초 입니다.
RSCP를 저장하는 방식이기 때문에 서버 컴포넌트는 저장되지만, 클라이언트 컴포넌트는 저장되지 않습니다.
라우터 캐시는 Opt out이 되지 않습니다. 그러나 무효화 하는 기능을 제공하고 있습니다.

router.refetch, revalidatePath, revalidateTag 또는 Next/Link의 prefetch 옵션을 false로 설정
한 세션 동안만 유지된다.

클라이언트 측 캐시이기 때문에 아무래도 복잡한 특징을 갖고 있으면 이런 저런 문제가 생길 가능성이 높기 때문일까요?

생각보다 간단한 특징을 가지고 있기 때문에 이해하기가 어렵지 않습니다.

단점(?)이자 장점인 기능

개인적으로 라우터 캐시를 잘 사용하기 위해서 코드 분할을 디테일하게 설정해야 할 필요가 있다고 느꼈습니다.

Prefetch는 분명 로딩을 빠르게 할 수 있도록 도와주긴 하지만, 만약 빠르게 불러올 페이지가 굉장히 큰 페이로드를 가졌다면 현재 보고 있는 페이지에는 전혀 필요없는 페이로드를 다운로드 해야 한다는 점인데요.

그러니 코드 분할을 얼마나 잘 활용하느냐에 따라 ‘단점’이 될 수도 ‘장점’이 될 수도 있겠습니다.

마무리

드디어 네 번째 캐싱 매커니즘 까지 마무리가 되었는데요.

정말 놀라운 점은 사실 이전까지 디테일하게 몰랐던 이 캐싱 기능들이 지식이 부족한 개발자 임에도 제대로 동작하게 구성되었다는 점이 놀라웠습니다.

저는 사실상 Prefetch 기능을 제외하고선 거의 모르던 캐싱 개념들이었는데도 개발하는데 이슈가 없었을 정도라니..

저도 언젠가 이렇게 의존성을 쫙 뺀 담백하고 좋은 기능들을 많이 만들어 낼 수 있는 개발자가 되고 싶습니다. 🙂

마지막으로 라우터 캐시의 다이어그램을 보여드리고 마무리 하겠습니다.

Reference.

👉🏻 Finally Master Next.js's Most Complex Feature - Caching

Next.js의 캐싱 매커니즘 네 번째 ‘Router Cache’

Router Cache

특징

단점(?)이자 장점인 기능

마무리

Reference.