SSR과 Server Component
NextJS는 기본적으로 SSR(Server Side Rendering)으로 모든 컴포넌트를 렌더링하고 있습니다. SSR의 장점으로는
- 데이터베이스와 가까운 위치(서버)에서 데이터를 요청하여, 응답시간을 단축시켜 속도를 빠르게 할 수 있습니다.
- 컴포넌트가 의존하고 있는 큰 사이즈의 모듈들을 서버에 두어 클라이언트가 가지는 자바스크립트 번들 사이즈를 크게 줄일 수 있습니다.
하지만 SSR에는 치명적인 단점이 있는데, 그건 hydration 비용입니다. 서버에서 html을 렌더링해서 클라이언트에 내려준다고 해도 각 엘리먼트의 event들은 기본적으로 자바스크립트입니다. html의 각 요소에 어떤 자바스크립트 handler가 붙어있는지 클라이언트는 서버에서 렌더링된 html 만으로는 알지 못합니다. 그래서 서버에서 내려준 html과 자바스크립트로 이루어진 이벤트 handler를 연결해주는 과정이 필요한데 이 과정에 hydration입니다.
최근 구글은 Web Vital의 주요 성능 지표로 INP(Interaction to Next Paint)를 추가했습니다. 페이지가 렌더링 되고 얼만큼 빠르게 사용자가 이벤트를 실행시킬 수 있는지를 측정하는 지표입니다. hydrate비용은 이 지표에 치명적입니다. 그래서 NextJS는 이 비용을 줄일 필요가 있었습니다.
리액트 진영에서 고안한 방법이 바로 Server Component 입니다.쉽게 말해 기존에 페이지 단위로 했던 SSR을 컴포넌트 단위로 축소한 것입니다. 여기서 중요한 것은 사실 Server Component가 아닙니다. 정말 중요한 것은 Client Component를 분리한 것입니다.서버에서 html을 렌더링하고 client 컴포넌트가 렌더링 되는 부분은 slot으로 비워놓고 Client에서 실행될 수 밖에 없는 컴포넌트들(이벤트 handler가 있거나 useState,useEffect 같은 리액트 훅을 사용하거나 browser api를 사용하는 컴포넌트)은 서버에서 pre-render 후 클라이언트에서 hydration과정을 거쳐서 slot에 채워집니다. 이렇게 되면 hydration비용을 효과적으로 줄일 수 있습니다.
