안녕하세요 IT 비즈니스 파트너 똑똑한개발자에서 프론트엔드 개발을 하고 있는 손은경입니다 ☺️

개발을 보다 효율적으로 운영하기 위해 개인적으로 스터디 문서를 작성하고 있는데요, 팀원들과 가장 많은 이야기를 나누었던 주제들 중심으로 하나씩 포스팅을 해보려고 합니다:)

이번 포스팅에서는 Next.js 를 사용하면서 직접 경험한 지식들을 소개해보려고 합니다. 들어가기에 앞서 Next.js에서는 두가지 App Router와 Page Router가 있는데요. 오늘 주로 다룰 내용인 App Router가 Next.js 13.4 버전부터 보다 안정적인 버전으로 변경되었습니다.

이를 바탕으로 본 글에서는

1. 데이터 캐싱을 통한 API 호출 비용 절감 방법

2. Page Router보다 빠른 페이지 초기 로드 속도 달성

3. 사용자 경험 향상을 위한 스킬

위의 3가지 내용을 주로 다뤄보려고 합니다.

1. Fetching

개인화 되지 않은 요청

• fetch 의 기본 캐시 옵션은 force-cache 로 요청의 응답이 원격 서버에 캐싱 됩니다

• force-cache는 개인화되지 않고 GET 메서드로 요청할 때에만 사용합니다.

  
  

개인화 된 요청

개인화된 요청인 경우, force-cache를 사용하면 모든 사용자에게 동일한 응답이 반환됩니다.

API와의 통신 과정에서 개인화된 요청에는 Authorization 헤더를 추가하여 보냅니다.

• Authorization 에는 cookie의 access가 포함됩니다.

• cookies(), headers(), noStore(), searchParams 등의 동적 함수를 사용하면 동적 요청으로 간주되어 동적 렌더링으로 전환됩니다.

• Authorization header or cookie를 사용하면 요청이 캐시되지 않습니다.

• 개인화된 요청은 cache 옵션을 no-store로 설정해야 합니다. 이렇게 하면 캐시를 조회하지 않고 요청이 있을 때마다 원격 서버에서 리소스를 가져옵니다. 해당 리소스로 캐시를 업데이트 하지 않습니다.→ 개인화된 요청을 원격 서버에 캐싱하지 않음을 의미합니다.

• GET이 아닌 method (예: POST, PUT, DELETE…) 도 자동으로 캐시 되기 때문에, no-store로 설정합니다.

‼️ 기존에는 tanstack-query를 사용하여 client-side에서 백엔드 API 호출 시 사용자의 네트워크 비용이 발생했습니다. 그러나 서버 컴포넌트에서 fetch를 사용한 요청은 프론트 서버 비용이 발생합니다. 캐시 관리를 효율적으로 하지 않으면, 불필요한 프론트 서버 비용과 백엔드 API 호출 비용이 동시에 발생할 수 있습니다.

2. Caching

Data Cache

💡 Next.js 에서는 서버 요청 및 배포 전반에 걸쳐 fetch 요청에 대한 결과를 유지하는 데이터 캐시가 내장되어 있습니다. 이 데이터 캐시는 클라이언트 캐시가 아닌 서버 캐시를 의미합니다.

Duration

fetch의 캐시 옵션을 force-cache 로 설정 후 배포하게 되면, revalidate 하거나 opt-out 하지 않는 이상 모든 배포에서 캐싱된 데이터가 유지됩니다.

• Vercel에서 Project 캐시를 삭제하는 방법

  (첫번째로 첨부된 이미지를 확인해주세요!) Purge Everything 버튼을 클릭해 캐시된 데이터를 삭제할 수 있습니다. 하지만 적절한 갱신 방법을 통해 API를 갱신하는 것이 바람직합니다.

이에 이어지는 내용은 이미지 추가 첨부가 필요하여, 똑똑한개발자 팀블로그에서 이어서 작성하도록 하겠습니다! 아래 링크를 클릭해주세요!

https://blog.toktokhan.dev/next-js%EC%9D%98-data-fetching-caching-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0-e1e0bef2f66f