junn.dev

[ Web ] CSR, SSR, SSG, ISR 렌더링 방식

CSR, SSR, SSG, ISR 렌더링 방식

렌더링 방식이란

웹 페이지를 사용자에게 보여주려면 결국 브라우저가 HTML을 받아서 화면을 그려야 한다.
이때 HTML을 언제, 어디서 만드느냐에 따라서 렌더링 방식이 나뉜다.

같은 화면을 보여주더라도 HTML을 브라우저에서 만드는지, 서버에서 만드는지, 빌드 시점에 미리 만들어두는지에 따라 초기 로딩 속도, SEO, 서버 비용, 데이터 최신성에 차이가 생긴다.

데이터 최신성

사용자가 보는 데이터가 현재 시점 기준으로 얼마나 최신 상태인지 의미하며, HTML을 미리 생성해두는 방식일수록 최신성이 떨어질 수 있다.

CSR(Client-Side Rendering)

CSR은 서버가 비어있는 HTML 파일을 보내고, 브라우저가 JavaScript를 실행해서 직접 화면을 렌더링하는 방식이다.

CSR 동작 흐름

CSR 동작 흐름

  1. 브라우저가 서버에 페이지를 요청한다.

  2. 서버는 최소한의 HTML, CSS, JavaScript 파일을 응답한다.

  3. 브라우저가 JavaScript를 다운로드하고 실행한다.

    React 같은 라이브러리가 실행되면서 API를 호출해 데이터를 받아온다.

  4. 가져온 데이터를 기반으로 DOM을 생성하고 화면을 렌더링한다.

CSR의 장점

  • 초기 로딩 이후 페이지 전환이 빠르다.

    • 필요한 데이터만 API로 받아 화면을 갱신하기 때문이다.

  • 서버는 HTML을 매번 생성하지 않아도 되기 때문에 서버 부담이 상대적으로 적다.

  • 클라이언트에서 직접 API를 호출해 언제든 최신 데이터를 보여줄 수 있다.

CSR의 단점

  • 초기 로딩이 느릴 수 있다.

    • 브라우저가 JavaScript를 다운로드하고 실행하기 전까지는 실제 콘텐츠가 보이지 않을 수 있다.

    • 사용자의 네트워크 환경이 느리거나 JavaScript 파일 크기가 크면 빈 화면이 오래 보일 수 있다.

  • 초기 HTML에 콘텐츠가 거의 없기 때문에 SEO(검색 엔진 최적화)에 불리할 수 있다.

    • 최근 검색 엔진은 JavaScript 렌더링을 어느 정도 처리할 수 있지만, 서버에서 완성된 HTML을 제공하는 방식보다 안정적이라고 보기는 어렵다.

CSR은 관리자 페이지, 대시보드, 로그인 이후 사용하는 서비스처럼 SEO보다 사용자 인터랙션이 중요한 화면에 잘 어울린다.

SSR(Server-Side Rendering)

SSR은 사용자가 페이지를 요청할 때 서버에서 HTML을 생성해 브라우저에 전달하는 방식이다.

SSR 동작 흐름

SSR 동작 흐름

  1. 브라우저가 서버에 페이지를 요청한다.

  2. 서버는 필요한 데이터를 조회한 뒤 조회한 데이터를 기반으로 HTML을 생성한다.

  3. 브라우저는 완성된 HTML을 받아 화면을 표시한다.

  4. 이후 JavaScript가 로드되면서 Hydration 단계를 거쳐 인터랙티브한 상태가 된다.

Hydration

서버에서 만들어진 정적인 HTML에 JavaScript 이벤트와 상태를 연결해 인터랙션 가능한 화면으로 만드는 과정이다.

SSR의 장점

  • 완성된 HTML이 전달되기 때문에 초기 화면 표시가 빠르고 SEO에 유리하다.

    • 검색 엔진이나 SNS 미리보기 봇이 페이지에 접근했을 때 완성된 HTML을 바로 읽을 수 있기 때문이다.

  • 요청 시점에 데이터를 가져오므로 항상 최신 데이터가 보장된다.

  • 쿠키, 헤더, URL 파라미터 등 요청 정보를 서버에서 읽어 사용자별 맞춤 HTML을 생성할 수 있다.

SSR의 단점

  • 요청이 들어올 때마다 서버에서 HTML을 생성해야 하므로, 트래픽이 많아질수록 서버 부담이 커질 수 있다.

  • 서버에서 데이터를 조회하고 HTML을 만드는 시간이 필요하기 때문에 캐싱 전략이 없다면 응답 속도가 느려질 수 있다.

  • Hydration이 완료되기 전까지는 화면은 보이지만 버튼 클릭 같은 인터랙션이 바로 동작하지 않을 수 있다.

SSR은 블로그, 상품 상세 페이지, 검색 결과 페이지처럼 외부 노출이 중요한 페이지에 적합하다.

SSG(Static Site Generation)

SSG는 빌드 시점에 HTML을 미리 생성해두는 방식이다.

SSG 동작 흐름

SSG 동작 흐름

  1. 빌드 시점에 필요한 데이터를 가져온다.

  2. 데이터를 기반으로 각 페이지의 HTML을 미리 생성한다.

  3. 생성된 HTML 파일을 서버나 CDN에 배포한다.

  4. 사용자가 요청하면 미리 생성된 HTML을 즉시 응답한다.

SSG의 장점

  • 요청 시점에 이미 생성된 파일을 그대로 전달하므로 응답 속도가 매우 빠르다.

    • 여러 지역의 CDN에 배포하면 사용자와 가까운 서버에서 빠르게 응답할 수 있다.

  • 정적 파일이므로 보안 취약점이 적고 캐시 활용이 쉽다.

  • SSR처럼 완성된 HTML을 제공하기 때문에 검색 엔진이 콘텐츠를 쉽게 읽을 수 있어 SEO에도 유리하다.

SSG의 단점

  • 빌드 시점에 HTML이 생성되기 때문에, 최신 데이터를 반영하려면 다시 빌드하고 배포해야 한다.

  • 페이지 수가 많아질수록 빌드 시간이 길어질 수 있다.

SSG는 블로그, 문서 사이트, 회사 소개 페이지, 포트폴리오처럼 자주 바뀌지 않는 콘텐츠에 적합하다.

ISR(Incremental Static Regeneration)

ISR은 SSG의 성능과 SSR의 최신성을 동시에 잡으려는 방식이다.
빌드 시점에 HTML을 미리 생성해두되, 일정 시간이 지나면 백그라운드에서 해당 페이지를 다시 생성할 수 있는 방식이다.

ISR 동작 흐름

ISR 동작 흐름

  1. 처음에는 빌드 시점에 생성된 정적 HTML을 제공한다.

  2. 설정한 재검증 시간이 지나도 기존 HTML은 계속 제공된다.

  3. 이후 사용자의 요청이 들어오면 백그라운드에서 새로운 HTML을 다시 생성한다.

  4. 재생성이 완료되면 다음 요청부터 새 HTML을 제공한다.

ISR의 장점

  • SSG의 빠른 응답 속도를 유지하면서도 데이터 갱신이 가능하다.

    • 기존 페이지를 먼저 빠르게 제공하고, 이후 백그라운드에서 갱신하는 방식으로 사용자 경험과 성능을 동시에 확보할 수 있다.

  • 전체 사이트를 다시 빌드하지 않고 필요한 페이지 단위로 다시 생성할 수 있기 때문에 규모가 큰 사이트에서도 효율적이다.

ISR의 단점

  • 설정된 재검증 시간 동안 이전 데이터가 계속 노출될 수 있다.

  • 사용자의 요청 시점과 실제 페이지가 갱신되는 시점이 다르기 때문에, 실시간성이 중요한 데이터에는 적합하지 않다.

ISR은 상품 상세 페이지, 뉴스 목록, 블로그 글, 채용 공고처럼 빠른 응답 속도와 어느 정도의 최신성이 모두 필요한 페이지에 적합하다.

← 목록으로 돌아가기