웹 렌더링 방식 (CSR / SSR / SSG / ISR)

개요

사용자가 웹사이트에 접속했을 때, 어떻게 html을 만들어서 브라우저에 보여줄지에 대한 방식 4가지를 살펴본다.

이런 렌더링 방식에 따라 속도, SEO(검색 엔진 최적화), 사용자 경험이 결정된다.

사용자가 `/about` URL을 호출하는 상황을 가정하였을 때, 각 렌더링 방식은 다음과 같이 동작한다.

 

🍉 CSR(Client Side Rendering) 

모든 라우팅과 렌더링을 브라우저(JS)에서 처리!

• 서버는 비어있는 `index.html` 하나를 응답하고 브라우저가 이를 파싱한다.
• JS 번들을 로드하고 앱이 초기화된다.
• JS 내 라우터가 현재 URL(`/about`)을 보고 그에 맞는 컴포넌트를 렌더링 한다. 

 

🍉 SSR(Server Side Rendering)

html 생성은 서버에서, 동작 연결은 브라우저에서!

• 서버가 사용자의 요청을 분석해 앱을 초기화하고, html을 직접 생성한다.
• 서버는 `/about`에 해당하는 html 뷰를 완성해서 사용자에게 응답한다.
•  이후 JS 번들이 로드되고 hydration(동작 연결)이 수행된다.

 

🍉 SSG(Static Site Generation)

페이지가 미리 준비되어 있고, 요청 시 파일만 전송

• 빌드 시 `/about`를 포함한 모든 라우팅 경로에 대한 html이 미리 생성되어 `dist/about/index.html`처럼 저장된다.
• 사용자가 `/about`에 대한 요청을 하면 서버가 바로 미리 생성된 정적 html 파일을 서빙한다.
• 브라우저가 html을 파싱하고 렌더링 한다.

 

🍉 ISR(Incremental Static Regeneration)

SSG처럼 빠르게 제공하되, 변경사항 반영을 점진적으로

•  사용자가 `/about`에 대해 초기 요청 시 서버는 SSG과 마찬가지로 미리 생성된 `index.html`을 즉시 응답한다.
• 브라우저에서 이 html을 파싱하고 렌더링 한다.
• 설정된 `revalidate` 주기 이후 누군가 요청하면 서버가 백그라운드에서 `/about` 페이지를 다시 생성한다.
• 그 이후 요청에 대해서는 새롭게 생성된 html로 응답한다. 

 

🤗 CSR / SSR / SSG / ISR 비교

	CSR	SSR	SSG	ISR
HTML 생성 시점/위치	브라우저 실행 시	요청 시 서버에서 생성	빌드 시 서버에서 생성	빌드 시 + 갱신 주기마다 서버에서 재생성
최초 응답 속도	느림 (빈 html + JS 로딩)	보통 (서버에서 html 응답)	매우 빠름 (정적 파일 제공)	매우 빠름 (정적 파일 + 자동 갱신)
JS 필요 여부	필수 (렌더링 자체가 JS 기반)	부분적 (렌더링은 서버, 인터렉션은 JS)	선택적 (렌더링 완료된 html 제공)	선택적 (렌더링 완료된 html 제공)
페이지 콘텐츠 준비 위치	브라우저에서 JS 실행	서버에서 html 생성	CDN/정적 파일	CDN + 갱신 시 서버 재생성
변경사항 반영 방식	클라이언트 요청 후 fetch 후 재렌더링	서버 요청마다	다시 빌드 필요	재요청 + revalidate로 백그라운트 갱신