티스토리 뷰

 

CSR (Client-Side Rendering, 클라이언트 사이드 렌더링)

 

실행 흐름

  1. 사용자 요청: 사용자가 페이지를 요청
  2. 빈 HTML 전송: 서버는 빈 HTML 파일과 JavaScript 파일을 클라이언트로 전송
  3. 클라이언트에서 데이터 fetching: 클라이언트(ex.크롬 브라우저)는 JavaScript를 실행해 필요한 데이터를 API 등에서 가져온다.
  4. 클라이언트에서 렌더링: 클라이언트는 데이터를 사용해 페이지를 동적으로 렌더링한다.

특징

  • 렌더링 위치: 클라이언트(브라우저)에서 렌더링.
  • 렌더링 시점: 사용자 요청 후 JavaScript 실행 시

리액트의 기본 동작 방식. 클라이언트에서 데이터를 fetching( JavaScript 파일 다운로드 및 실행 , JavaScript  파일로부터 DOM을 렌더링)하는 과정에서 시간이 오래 걸릴 수 있으나, 그 이후의 동작은 클라이언트에서 변경되므로 동적인 요소 변경이 빠르게 이루어진다. (ex. 차트, 그래프, 테이블 등을 동적으로 업데이트, 무한 스크롤)

그러나 미리 생성된 HTML이 없으므로 SEO에 불리하다. 검색 엔진은 완성된 HTML을 수집하기 때문이다.


 

SSR (Server-Side Rendering, 서버 사이드 렌더링)

실행 흐름

  1. 사용자 요청: 사용자가 페이지를 요청
  2. 서버에서 데이터 fetching: 서버는 필요한 데이터를 API 등에서 가져온다.
  3. 서버에서 렌더링: 서버는 데이터를 사용해 페이지를 렌더링하고, 완성된 HTML을 생성한다. 이 HTML에는 초기 상태(데이터)와 함께 React 컴포넌트의 구조가 포함된다.
  4. HTML 전송: 서버는 완성된 HTML을 클라이언트(브라우저)로 전송한다. 이 HTML 파일에는 <script> 태그를 통해 Hydration에 필요한 JavaScript 파일이 포함되어 있다.
  5. 클라이언트에서 Hydration*: 클라이언트는 받은 HTML을 표시하고, HTML에 포함된 JavaScript를 실행해 페이지를 인터랙티브하게 만든다. 또한 이 JavaScript는 React 컴포넌트를 "재활성화"하여 페이지를 인터랙티브하게 만든다. 이 과정을 Hydration*이라고 칭한다.

*서버에서 렌더링된 HTML에 React 컴포넌트를 연결하여, 클라이언트에서 동작할 수 있도록 만드는 과정


특징

  • 렌더링 위치: 서버에서 렌더링.
  • 렌더링 시점: 사용자 요청 시마다 실시간으로 렌더

요청 시마다 서버에서 렌더링되기 때문에 서버 부하가 높아질 수 있다. 실시간 데이터가 필요한 페이지(ex.실시간 채팅), SEO가 중요하지만 데이터가 자주 변경되는 페이지에 적합하다.


 

SSR(서버 사이드 렌더링) VS CSR(클라이언트 사이드 렌더링)

요점 : 어디에서 페이지를 렌더링 하는가?

항목 서버 사이드 렌더링 (SSR) 클라이언트 사이드 렌더링 (CSR)
정의 서버에서 페이지를 렌더링하여 완성된 HTML을 클라이언트로 전송 클라이언트(브라우저)에서 JavaScript를 사용하여 페이지를 동적으로 렌더링
초기 로딩 속도 빠름 (완성된 HTML을 바로 제공). 느림 (JavaScript를 다운로드하고 실행해야 함).
SEO(검색 엔진 최적화) 유리 (완성된 HTML을 검색 엔진에 제공). 불리 (JavaScript를 실행해야 콘텐츠가 표시됨).
서버 부하 높음 (모든 요청에 대해 서버에서 렌더링 수행). 낮음 (초기 로딩 후 클라이언트에서 렌더링 수행).
클라이언트 성능 의존도 낮음 (렌더링 작업이 서버에서 이루어짐). 높음 (렌더링 작업이 클라이언트에서 이루어짐).
TTFB(Time To First Byte)* 길 수 있음 (서버에서 렌더링 완료까지 시간 소요). 짧음 (빈 HTML 파일을 빠르게 전송).
인터랙티브한 사용자 경험 페이지 전환 시 전체 페이지를 다시 로드해야 할 수 있음. 페이지 전환 시 필요한 부분만 업데이트 가능 (더 부드러운 사용자 경험).
적합한 사용 사례 SEO가 중요한 페이지 (블로그, 뉴스, 이커머스 등). 인터랙티브한 웹 애플리케이션 (대시보드, SPA 등).
캐싱 활용 제한적 (서버에서 매번 렌더링 필요). 가능 (JavaScript 파일 캐싱 후 재사용).

*리소스 요청과 응답의 첫 번째 바이트가 도착하기 시작하는 시점 사이의 시간을 측정하는 웹 성능 측정항목


 

SSG (Static Site Generation, 정적 사이트 생성)

실행 순서:

  1. 빌드 시점: 프로젝트를 빌드할 때 정적 페이지를 생성
    • 데이터 fetching: 필요한 데이터를 API 등에서 가져온다.
    • 페이지 렌더링: 데이터를 사용해 페이지를 렌더링하고, 정적 HTML 파일로 저장한다.
  2. 사용자 요청: 사용자가 페이지를 요청
  3. 정적 HTML 전송: 서버는 미리 생성된 정적 HTML 파일을 클라이언트로 전송
  4. 클라이언트에서 Hydration: 클라이언트는 받은 HTML을 표시하고, JavaScript를 실행해 페이지를 인터랙티브하게 만든다.

특징:

  • 렌더링 위치: 빌드 시점에 서버에서 렌더링
  • 렌더링 시점: 빌드 시점
  • 데이터 최신성: 빌드 시점의 데이터를 제공 (재빌드 필요)
  • 초기 로딩 속도: 매우 빠름 (미리 렌더링된 HTML 제공).
  • SEO: 매우 유리 (완성된 HTML 제공)
  • 적합사례
    • 콘텐츠가 자주 변경되지 않는 페이지 (예: 블로그, 문서, 제품 소개 페이지)
    • SEO가 중요한 페이지 

빌드 시점에 모든 페이지를 미리 렌더링하므로, 배포 후에는 서버에서 추가 작업이 필요하지 않다. 이는 초기 로딩 속도 SEO를 크게 향상시킨다. 그러나 데이터가 자주 변경되는 경우, 재빌드가 필요할 수 있다.


 

SSR과 SSG의 차이 - "언제" 페이지를 렌더링 하는가? 

 

항목 SSG SSR
렌더링 시점 빌드 시점에 미리 렌더링. 사용자 요청 시점에 실시간으로 렌더링.
데이터 최신성 빌드 시점의 데이터를 제공 (재빌드 필요). 항상 최신 데이터를 제공.
초기 로딩 속도 매우 빠름 (미리 렌더링된 HTML 제공). 느림 (요청 시마다 서버에서 렌더링).
서버 부하 낮음 (빌드 시점에만 렌더링). 높음 (요청 시마다 서버에서 렌더링).
적합한 사례 콘텐츠가 자주 변경되지 않는 페이지 (예: 블로그, 문서, 제품 소개 페이지). 실시간 데이터가 필요한 페이지 (예: 사용자 프로필, 실시간 채팅).

 

ISR (Incremental Static Regeneration, 증분 정적 재생성)

실행 순서:

  1. 빌드 시점: 프로젝트를 빌드할 때 초기 정적 페이지를 생성한다.
    • 데이터 fetching: 필요한 데이터를 API 등에서 가져온다.
    • 페이지 렌더링: 데이터를 사용해 페이지를 렌더링하고, 정적 HTML 파일로 저장한다.
  2. 사용자 요청: 사용자가 페이지를 요청.
  3. 정적 HTML 전송: 서버는 미리 생성된 정적 HTML 파일을 클라이언트로 전송.
  4. 백그라운드에서 재검증: 설정된 시간(revalidate)이 지나면, 서버는 백그라운드에서 데이터를 다시 가져와 페이지를 재렌더링.
  5. 새로운 HTML 저장: 재렌더링된 페이지를 새로운 정적 HTML 파일로 저장.
  6. 다음 요청 시 새로운 HTML 전송: 다음 사용자 요청 시 업데이트된 HTML을 제공.

특징:

  • 렌더링 위치: 빌드 시점에 서버에서 초기 렌더링, 이후 주기적으로 재렌더링.
  • 렌더링 시점: 빌드 시점 + 설정된 주기(revalidate)마다 재렌더링.
  • 데이터 최신성: 주기적으로 최신 데이터로 업데이트.
  • 초기 로딩 속도: 매우 빠름 (미리 렌더링된 HTML 제공).
  • SEO: 매우 유리 (완성된 HTML 제공).
  • 서버 부하: 중간 (빌드 시점에 초기 렌더링, 이후 주기적으로 재렌더링).
  • 적합한 사례:
    • 콘텐츠가 가끔 변경되는 페이지 (예: 블로그, 이벤트 페이지).
    • SEO가 중요하고, 데이터가 주기적으로 업데이트되는 페이지.

SSR, CSR, SSG, ISR 특징 정리

항목 SSR CSR SSG ISR
렌더링 위치 서버 클라이언트 서버 (빌드 시점) 서버 (빌드 시점 + 주기적 재렌더링)
렌더링 시점 요청 시마다 클라이언트에서 JavaScript 실행 시 빌드 시점 빌드 시점 + 주기적 재렌더링
데이터 최신성 항상 최신 클라이언트에서 최신 데이터 가져옴 빌드 시점 데이터 (재빌드 필요) 주기적으로 최신 데이터로 업데이트
초기 로딩 속도 느림 (서버 렌더링 시간 추가) 느림 (JavaScript 다운로드 및 실행 필요) 매우 빠름 (미리 렌더링된 HTML 제공) 매우 빠름 (미리 렌더링된 HTML 제공)
SEO 매우 유리 불리 매우 유리 매우 유리
서버 부하 높음 낮음 낮음 중간
적합한 사례 실시간 데이터가 필요한 페이지 (예: 사용자 프로필, 실시간 채팅) 인터랙티브한 웹 애플리케이션 (예: 대시보드, 관리자 패널) 콘텐츠가 자주 변경되지 않는 페이지 (예: 블로그, 문서, 제품 소개 페이지) 콘텐츠가 가끔 변경되는 페이지 (예: 블로그, 이벤트 페이지)
  • SSR: 요청 시마다 서버에서 실시간으로 렌더링.
  • CSR: 클라이언트에서 JavaScript로 동적으로 렌더링.
  • SSG: 빌드 시점에 미리 렌더링하여 정적 HTML 제공.
  • ISR: 빌드 시점에 초기 정적 페이지를 생성하고, 주기적으로 재검증하여 업데이트.

'Web' 카테고리의 다른 글

Atomic Design System(원자 설계 방법론)  (1) 2024.12.23
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG
more
«   2025/07   »
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31
글 보관함