Next.js에서의 서버 측 캐싱과 클라이언트 측 캐싱 비교: 성능 최적화를 위한 최선의 실천 방법
카테고리
프로그래밍/소프트웨어 개발
서브카테고리
웹 개발
대상자
Next.js 프로젝트에서 성능 최적화를 담당하는 중급 이상의 프론트엔드 개발자
- 난이도: 실무 적용 중심의 기술적 내용, 중간 수준의 캐싱 개념 이해 필요
핵심 요약
- 서버 측 캐싱(Redis, CDN)은 모든 사용자 공유 데이터(블로그 게시물, 상품 카탈로그)를 처리하는 데 적합하며, 서버 부하 감소와 응답 시간 최적화를 목표로 함
- 클라이언트 측 캐싱(SWR, React Query)은 사용자별 데이터(프로필, 장바구니)를 처리하며, 실시간성과 인터랙티브 UI 성능 향상을 위해 사용됨
- Redis 예시:
redis.set("products", JSON.stringify(products), "EX", 60)
을 통해 60초 TTL로 데이터 캐싱 - SWR 예시:
useSWR("/api/user", fetcher)
로 캐시된 데이터 즉시 제공 후 백그라운드에서 업데이트
섹션별 세부 요약
1. 서버 측 캐싱의 역할과 사용 사례
- 서버 측 캐싱은 요청이 처리되기 전에 백엔드 부하를 줄이는 데 초점
- Redis: 상품 목록, 카테고리 페이지 등 공유 데이터 캐싱
- CDN: 정적 자산, HTML 페이지, API 응답 엣지 네트워크 캐싱
- SSR 페이지 캐싱:
getServerSideProps
결과를 서버 레벨에서 캐싱 - 적용 대상:
- 빈번하게 생성되는 데이터(데이터 집합, DB 쿼리)
- 사용자별로 변하지 않는 데이터(사이트 설정, 카테고리)
2. 클라이언트 측 캐싱의 역할과 사용 사례
- 클라이언트 측 캐싱은 사용자가 페이지를 로드한 이후 브라우저 캐시를 활용해 데이터의 신선도와 반응 속도를 유지
- SWR/React Query: 프로필 정보, 알림, 대시보드 통계 등 사용자별 데이터 즉시 제공
- 브라우저 캐시: 이미지, 스크립트 등 정적 자산 헤더 기반 캐싱
- 적용 대상:
- 사용자별로 변경되는 데이터(장바구니, 위시리스트)
- 실시간 업데이트가 필요한 데이터(알림, 실시간 피드)
3. 서버 측 vs 클라이언트 측 캐싱의 선택 기준
- 서버 측 캐싱은 모든 사용자 공유 데이터에 적합
- 예: 상품 목록, 블로그 게시물, 카테고리 페이지
- Redis 사용 시 TTL(60초) 설정 필수
- 클라이언트 측 캐싱은 사용자별 데이터에 적합
- 예: 사용자 프로필, 알림, 대시보드 요약
- SWR의 stale-while-revalidate 전략으로 캐시 즉시 제공 후 백그라운드 업데이트
결론
- 서버 측 캐싱(Redis, CDN)과 클라이언트 측 캐싱(SWR, React Query)을 결합하여 사용해 성능과 유연성을 균형 잡는 것이 핵심
- Redis를 사용할 때는
EX
옵션으로 TTL 설정하고, SWR은useSWR
로 캐시 즉시 제공 후 백그라운드 업데이트를 적용 - 공유 데이터는 서버 측, 사용자별 데이터는 클라이언트 측 캐싱을 통해 최적의 성능 달성