JavaScript 번들이 훨씬 더 작아질 수 있습니다. (next.js page-router의 차이점)오늘날 클라이언트 측 JavaScript의 서버 측 렌더링은 차선책일 수 있다. 컴포넌트에 대한 JavaScript코드는 서버에서 HTML 문자열로 렌더링됩니다. 이 HTML은 브라우저에 전달되어 빠른 결과를 가져올 수 있습니다. (FCP나 LCP 관점에서)
하지만, 유저와의 상호작용을 위해서는 여전히 JavaScript를 가져와야 합니다. 보통은 hydration 과정을 통해 가져오게 된다. 서버 사이드 렌더링한 결과물은 초기 페이지 로드에만 사용되고, hydration 과정을 거치게되면 다시 사용될 일이 없다. (hydration과정을 통해 다시한번 화면이 그려지기 때문임. 서버측에서 한번, 브라우저쪽에서 한번 두번 그림 ⇒ 그래서 html결과가 똑같아야함. 다르면 next.js에서 에러를 내뿜는것을 볼 수 있음.)
서버컴포넌트는 하이드레이션할지말지(두번그릴지)를 페이지단위가 아닌 컴포넌트단위에서 이를 컨트롤 할 수 있다. 예를들어 인터렉션이 필요없는 컴포넌트들은 그냥 서버측 렌더링만으로 끝남. 하지만 인터렉션이 있는 컴포넌트는 page-router와 똑같이 서버에서 한번 렌더링하고, hydration 과정을 거쳐서 클라이언트에서 한번 더 렌더링을 한다. ⇒ 기존 page-router의 인터렉션이 없는 컴포넌트들도 (사실 서버측에서 랜더링한 결과 그대로 두면되는데 굳이 hydration과정을 거쳤었음) 2번 그렸던 작업을 안 할수 있게 된다.
<aside> 💡 이전 버전인 page-router와 비교했을때 얻을 수 있는 이점은, 인터렉션이 필요없는 컴폰너트들은 사실상 두 번 렌더링(서버, 클라이언트)될 필요가 없었음에도 불구하고, 페이지 단위로 서버에서 그렸기 때문에, 인터렉션이 있는 컴포넌트, 없는 컴포넌트 모두 hydration 과정을 거쳐야했고, 이는 결국 자바스크립트를 통해 모든 페이지를 한번 더 그리는 것이기 때문에, 자바스크립트 번들양은 똑같이 컸다.
서버 컴포넌트가 도입되면서, 인터렉션이 없는 컴포넌트들은 서버에서 렌더링후 더이상 렌더링이 일어나지 않게된다. (hydration 할 필요가 없음). 인터렉션이 있는 컴포넌트들만 자바스크립트로 다시 한번 레더링을 하기 때문에 이전버전과 비교했을때 자바스크립트 번들량이 감소했다. 이제 개발자가 서버에서 그릴 컴포넌트를 선택할 수 있고(페이지 단위 ⇒ 컴포넌트 단위 컨트롤) 이것은 하이드레이션 과정을 거치지 않으며, 브라우저가 다운로드해야하는 자바스크립트 번들량을 줄 일 수 있다는 이점이 있다.
</aside>
React Server Component를 사용하면 구성 요소를 정기적으로 다시 가져올 수 있습니다. 새 데이터가 있을 때 다시 렌더링되는 구성 요소가 포함된 애플리케이션을 서버에서 실행할 수 있으므로 클라이언트에 전송해야 하는 코드의 양이 제한됩니다.
React의 새로운 서버 컴포넌트는 SSR을 보완하여 JavaScript 번들에 추가하지 않고도, 중간 추상화 형식으로 렌더링할 수 있습니다. 상태(state)손실없이, 서버트리와 클라이언트 트리를 병합할 수 있고, 더 많은 컴포넌트들로 확장할 수 있다.
서버컴포넌트는 SSR의 대체제가 아니다.
<aside> 💡 결국은 클라이언트에 보내야하는 코드량을 감소 시킬 수 있다.
</aside>