[Next.js] Next.js 14 Rendering 및 서버 실전 압축 정리

Rendering

SSR(Server-Side Rendering)

: 매 요청마다 페이지를 서버에서 렌더링하여 클라이언트에 전송하는 방식

• 특징
  • 요청 시마다 페이지가 서버에서 생성
  • 데이터를 동적으로 가져오기에 페이지는 최신 데이터를 반영
  • 유저별 동적 데이터 처리에 적합
• 장점
  • SEO에 유리
  • 최신 데이터 보장
• 단점
  • 초기 로딩 시간 존재 -> Suspense를 사용하자
  • 많은 요청이 들어오면 서버 부하 발생
• 적합한 사용처
  • 최신 데이터를 항상 보여줘야하는 페이지

CSR(Client-Side Rendering)

: 브라우저가 초기 HTML, CSS, JavaScript 파일을 서버로부터 받아온 후, JavaScript를 통해 클라이언트(브라우저)에서 페이지를 렌더링하는 방식

• 특징
  • 서버는 초기 HTML과 함께 JavaScript 파일을 제공하며, 이후의 모든 렌더링은 클라이언트에서 처리
  • 주로 API 호출을 통해 통신함
• 장점
  • 한번 로드되면, 이후 페이지 전환이 매우 빠르고 부드러움 -> 동적인 UI 구현 시 용이함
  • 서버 부하 감소
• 단점
  • SEO 최적화가 어려움
  • 초기 Javascript 번들 다운로드 -> 첫 페이지 로딩 속도는 SSR보다 느릴 수 있음
• 적합한 사용처
  • 데이터가 자주 변경되는 UI가 필요한 페이지
  • SPA 환경

SSG(Static Site Generation)

: 빌드 시에 페이지가 한번 렌더링되고, 그 결과가 정적 파일로 저장되는 방식

• 특징
  • 빌드 시에 페이지가 생성되어 배포되고, 클라이언트 요청 시 그대로 전송
  • 모든 요청에 대해 동일한 정적 페이지 제공
  • 데이터가 자주 변경되지 않는 페이지에 적합
• 장점
  • 매우 빠른 초기 로딩 시간
  • SEO 최적화
  • 서버 부하 최소화
• 단점
  • 데이터 최신화 어려움 -> 빌드 후 변경된 데이터는 즉각 반영 X
  • 데이터가 많거나 페이지가 많은 경우 -> 빌드 시간 증가
• 적합한 사용처
  • 콘텐츠가 자주 변경되지 않는 페이지 (ex. 블로그, 문서, 제품 카탈로그)

ISR(Incremental Static Regeneration)

: SSG와 SSR의 장점을 결합한 방식으로, 정적 페이지를 주기적으로 재생성

• 특징
  • SSG의 단점 보완: 정적 파일을 빌드 시 생성하되, 특정 페이지는 일정 간격으로 다시 생성
  • revalidate를 사용하여 특정 시간(초 단위)마다 정적 페이지를 재생성하여 최신 데이터 유지
• 장점
  • 빠른 로딩 속도 (기본적으로는 SSG 방식임)
  • revalidate를 통해 최신 데이터 반영 가능
  • 서버 부하 적음
• 단점
  • 복잡성 증가 -> 정적 파일과 동적 파일의 혼합 관리 필요
  • revalidate로 설정한 시간이 지나면, 첫 요청 시 페이지를 재생성하므로 약간의 지연 발생 가능
• 적합한 사용처
  • 데이터가 자주 변경되지만, 즉시 최신성이 요구되지 않는 경우 (ex. 뉴스, 제품 리스트)
  • 콘텐츠 중심의 사이트로, 변경 사항이 시간차를 두고 반영되어도 되는 경우

요약

렌더링 방식	데이터 최신성	초기 로딩 속도	서버 부하	SEO	사용 사례
SSR	최신	느림	높음	좋음	로그인 대시보드 ,실시간 데이터 필요 페이지
CSR	최신	느림	낮음	별로	대화영 웹앱, 채팅 앱
SSG	빌드 시점 데이터	빠름	매우 낮음	좋음	블로그, 문서 페이지
ISR	시간 단위 최신	빠름	낮음	좋음	뉴스, 제품 리스트

결론

• SSR: 데이터 최신성이 중요하고, 유저별 동적 데이터가 필요한 경우
• CSR: 매우 동적이고, 데이터가 자주 업데이트되는 경우
• SSG: 데이터 변경이 드물고 빠른 응답 속도가 중요한 경우
• ISR: 데이터 변경 주기가 길고, 정적 파일로 제공하되 최신성을 일정 부분 유지해야 하는 경우

Nextjs의 기본 렌더링 방식

이전 버전에서는 각 페이지에서 getStaticProps, getServerSideProps 등으로 SSR, SSG, ISR을 수행했지만, Nextjs 14는 서버 컴포넌트(React Server Components)를 사용함
=> 더 이상 페이지 단위의 SSR이 아니라 서버 컴포넌트와 클라이언트 컴포넌트를 이용해 컴포넌트 단위로 CSR, SSR, SSG, ISR로 렌더링 방식 설정 가능

• Next.js 14는 SSG를 기본값으로 사용
  • => 전체 사이트가 빌드 타임에 서버에서 미리 렌더링되고, 정적 파일로 저장됨 (일종의 캐싱)
  • Nextjs 내부 캐싱 매커니즘 덕분에 모든 페이지를 서버에서 만들더라도 부담이 적음
• SSG 덕분에 서버 부하를 줄일 수는 있지만, 데이터 최신화가 어렵다는 단점..
  • => 이를 보완하기 위해 ISR 사용 가능

---

Next.js에서의 서버?

• 여기서의 ‘서버’는 백엔드 서버를 의미하는 것이 아니라, 프론트엔드 서버를 의미함.
• Next.js는 Node.js 기반으로 실행되고, SSR이나 SSG 같은 작업도 이 Node.js 기반 서버에서 수행된다
  • Node.js 런타임
    • 전통적인 서버 환경: JavaScript를 서버 측에서 실행하는 런타임으로, Next.js 애플리케이션이 주로 실행되는 환경
    • 광범위한 모듈 지원: 파일 시스템, 네트워크 요청 등 다양한 서버 사이드 기능을 지원하는 풍부한 모듈을 제공
    • 고성능 서버 기능: 대규모 데이터 처리와 실시간 애플리케이션에 적합하며, 서버 사이드 렌더링(SSR)과 정적 사이트 생성(SSG) 등 다양한 기능을 효과적으로 지원
  • Edge 런타임
    • 서버리스 배포: Vercel과 같은 서버리스 플랫폼에서 애플리케이션을 분산된 엣지 네트워크로 배포
    • 초고속 응답 시간: 전 세계에 분산된 엣지 서버를 통해 사용자가 지리적 위치에 관계없이 매우 빠른 응답 받음
    • 제한된 모듈 사용: 경량화와 보안을 위해 일부 Node.js 모듈은 지원 X -> 클라우드 인프라 최적화