웹에 대해서... (SSR -> CSR -> SSR Hydration -> SSG)

1. 웹은 원래 어떻게 동작했을까?

 

- 초기에 웹은 서버가 완성된 HTML을 만들어 서버에서 그대로 클라이언트로 보내는 구조였다.

 

2. 문제 발생 (느림 / UX )

페이지 클릭 -> 서버 요청 -> 전체 새로고침

 

이 SSR 방식은 정적인 페이지 (즉, 화면의 변화가 많지 않거나 전혀 없는 경우)에는 문제가 없었으나,

사용자가 자주 화면에서의 동적인 변화를 요청하게 되는 일이 많아지며

페이지를 이동하거나 새롭게 페이지가 리로딩될 때마다 페이지를 서버에서 새롭게 만들어서 보내주는 과정이 계속 반복되다보니 속도도 느려지고, UX(User Experience)적으로 로딩되는 시간이 길어지면서 불편함을 초래했다.

 

3. CSR + SPA 등장

ⓐ. 서버는 빈 HTML + JS만 전달하게 되었고,

ⓑ. 브라우저는 DOM에서 JS 객체로 Tree를 만들고 렌더링하는 단계로 변화함.

ⓒ. CSR(Client Side Rendering) + SPA (Single Page Application) 애플리케이션 구조로 변화하였다. (페이지 새로고침 없이 동작)

  - SPA (구조) ⊃ CSR (렌더링 방식) 관계라고 생각해도 된다.

 

4. CSR의 한계

- CSR의 본질적인 문제 (초기 HTML에 콘텐츠가 없음)

<div id="root"></div>
<script src="app.js"></script>

이 상태에서 크롤러가 보면

- 콘텐츠가 없음

- 텍스트 없음

- 링크 없음

 

검색엔진 입장에서

- HTML을 먼저 수집하는데, 내용이 없어 평가가 불가능해짐

- 초기 지연 렌더링 때문에 JS 실행 실패 가능성이 있음

- 결과적으로 콘텐츠 인덱싱 늦어지고, 일부 페이지는 아예 누락이 되어 SEO 점수가 하락

 

5. SSR 재등장

- 서버에서 HTML 완성해서 전달

- 바로 화면이 보임

- 이후 JS 붙음 (hydration)

- SSR Hydration

Hydration은 서버가 미리 그려준 HTML에, 브라우저가 나중에 JavaScript를 붙여서 "동작하는 화면"으로 만드는 과정
즉, SSR은 서버가 먼저 HTML을 보내주고 Hydration은 그 HTML에 이벤트와 상태를 연결함

 

ⓐ. 예를 들어 서버가 특정 HTML을 보냈다고 가정

<div>
  <h1>상품 목록</h1>
  <button>장바구니 담기</button>
</div>

브라우저는 이걸 바로 화면에 그릴 수 있지만, 아직 문서일 뿐 살아있는 UI는 아님

(이벤트가 연결되어 버튼이 작동되거나 상태가 변화하거나)

 

ⓑ. 브라우저가 JS 번들을 다운로드한 후

<script src="/main.js"></script>

이 파일이 다운로드되고 실행되면 React가 동작하기 시작함

 

ⓒ. React가 기존 HTML과 자신의 컴포넌트를 연결하게 됨

- React는 새로 DOM을 처음부터 다 만드는 게 아니라, 이미 서버가 만들어 둔 HTML을 보고 거기에 연결을 시도함

  - 기존 DOM을 사용

  - 이벤트 리스너를 붙임

  - 상태 관리 연결

  - 클라이언트에서 React 앱처럼 동작하게 만듦

 

6. SSG 등장

- 미리 HTML 생성 (빌드[컴파일] 시점)

- 요청 오면 바로 제공

 

ⓐ. 빌드 시점

- 서버에서 React 실행

- HTML 파일 생성

ⓑ. CDN(Content Delivery Network) / 서버에 저장

- 그냥 파일로 저장

ⓒ. 사용자 요청

- 파일 그대로 꺼내서 그대로 줌

 

7. SSR / CSR / SSG 비교

방식	HTML 생성 시점	Who Made	단점
CSR (Client Side Rendering)	요청 후 (브라우저)	브라우저(JS)	SEO 약함
SSR (Server Side Rendering)	요청 시마다	서버	서버 부담
SSG (Static Side Generation)	빌드 시점(컴파일)	서버(미리)	실시간 데이터 어려움