"Next.js" 태그로 연결된 3개 게시물개의 게시물이 있습니다.

Next.js 캐싱 가이드를 읽고 나서, 지금 운영 중인 프로젝트의 캐싱 전략도 한 번 정리해봐야겠다는 생각이 들었습니다.

Next.js App Router의 캐싱은 레이어가 많습니다. Request Memoization, Data Cache, Full Route Cache, Router Cache를 각각 이해하는 것도 중요하지만, 실무에서는 그보다 먼저 물어야 할 질문이 있었습니다.

이 데이터는 모든 사용자에게 같은 값을 보여줘도 되는가?

이 질문에 대한 답에 따라 Next.js 캐시에 올릴 데이터, TanStack Query에 남길 데이터, 클라이언트에서만 요청할 개인화 데이터를 나눌 수 있었습니다.

이 글은 Next.js 캐싱 전체를 깊게 설명하는 글이 아닙니다. 원래 Next 캐싱을 적극적으로 쓰지 않던 프로젝트에 일부 캐싱을 도입하면서, 어떤 기준으로 경계를 나눴는지 정리한 실무 기록입니다.

Vercel에 배포된 Next.js 프로젝트에서 <Image> 컴포넌트를 사용해 외부 이미지를 불러오는 경우, 원본 이미지를 교체해도 변경 내용이 반영되지 않는 문제가 발생할 수 있습니다.

Vercel 배포 환경을 기준으로 여러 계층의 캐시로 인해 발생하는 이 문제의 원인을 살펴보고, Vercel Cache Purge와 CloudFront Invalidation을 통해 해결하는 방법을 알아봅니다.

이전 포스팅에서 코어 웹 바이탈에 대해 살펴보고, 웹을 개선하기 위해 어떻게 코어 웹 바이탈을 측정할 수 있는지에 대해 알아보았다. 두 번째 단계로, 측정한 코어 웹 바이탈을 어떻게 개선할지 알아보자.

현재 담당하고 있는 프로젝트의 개발 환경인 Next.js 를 기준으로 정리해 보았다.

이전 포스팅:
웹 성능 지표, 코어 웹 바이탈(CWV)
코어 웹 바이탈 측정을 위한 도구 모음