Hydration ?
SSR이나 SSG를 통해 서버에서 완성된 HTML을 내려주더라도, 브라우저가 곧바로 동작 가능한
SPA(Single Page Application)로 변환되는 것은 아니다.
React 기반 프레임워크(Next.js 포함)에서는 이 과정을 Hydration이라고 부른다.
- 서버에서 내려온 HTML은 정적 콘텐츠일 뿐, 이벤트 핸들러나 상태 관리 기능이 없는 “죽은 페이지”다.
- 브라우저가 React의 JS 번들을 실행하여, 기존 HTML을 DOM과 연결하고 이벤트를 주입하는 과정이 Hydration이다.
- 즉, Hydration이 끝나야 비로소 사용자가 버튼을 클릭하거나 상태 변경을 할 수 있다.
Hydration 과정에서 발생할 수 있는 문제
Hydration Mismatch
- 서버에서 생성된 HTML과 클라이언트에서 렌더링된 결과가 다를 경우, React는 경고를 발생시키거나 DOM을 다시 그린다.
- 이때 화면이 깜빡이거나, 의도치 않은 레이아웃 깨짐이 발생한다.
- SEO 차원에서는 검색엔진이 본 HTML과 실제 사용자 화면이 달라질 수 있어, 콘텐츠 신뢰성에 영향을 줄 수 있다.
JavaScript 번들 크기 문제
- SSR/SSG를 하더라도 Hydration 단계에서는 JS 번들을 모두 다운로드하고 실행해야 한다.
- 번들이 크면 TTI(Time To Interactive)가 늦어져 Core Web Vitals 점수가 하락하고, 이는 곧 SEO 순위에 반영된다.
비동기 데이터 처리
- useEffect에서 데이터를 불러오는 경우, Hydration 시점에는 아직 데이터가 없어 빈 화면이 잠깐 노출될 수 있다.
- 구글봇은 기본적으로 HTML만 본다. Hydration 이후 동적으로 채워지는 콘텐츠는 렌더링 큐 처리를 기다려야 하므로 인덱싱이 지연될 수 있다.
Hydration과 SEO의 관계
Hydration 자체는 SEO에 직접적으로 반영되지 않는다.(검색엔진은 서버에서 내려온 HTML을 우선으로 보므로)
하지만 Hydration 과정이 실패하거나 지연되면, 다음과 같은 문제가 발생할 수 있다.
- 서버 HTML과 실제 사용자 화면 불일치 → 콘텐츠 신뢰도 저하
- JS 실행 지연으로 인한 사용자 경험 악화 → Core Web Vitals 점수 하락 → 검색 순위에 간접적 영향
- 구글봇이 JS 렌더링을 기다려야만 콘텐츠를 완전히 인덱싱 → 노출 지연
따라서, Next.js에서는 Hydration을 반드시 해결하라고 권장하고 있다.
실무에서의 Hydration
Hydration Mismatch 최소화
서버와 클라이언트 렌더링 로직을 일치시키고, 조건부 렌더링을 신중히 사용해야 한다.
e.g. typeof window !== “undefined”
번들 최적화
dynamic import로 불필요한 JS를 분리하고, critical path에 해당하는 컴포넌트만
우선 Hydration하도록 구성한다.
Skeleton / Placeholder
비동기 데이터는 빈 HTML을 노출하지 않고, 사용자 경험과 검색엔진 노출을 동시에 보완하는 UI 제공.
e.g. Skeleton UI 등
검색엔진 최적화 관점에서
Hydration은 단순히 클라이언트 상호작용을 가능하게 하는 과정이 아니라,
SEO와 성능 지표(Core Web Vitals)에도 직결되는 요소다.
따라서 SEO를 고려하는 페이지라면 다음과 같은 전략이 필요.
- 콘텐츠 중심 페이지 → 서버 HTML에 핵심 텍스트/메타정보를 포함하고, JS는 보조적 역할만 담당
- 인터랙션 중심 페이지 → CSR 비중이 커도 무방하므로, Hydration 최적화보다 사용자 경험에 집중
