CSR(Client Side Rendering)
CSR(Client Side Rendering) 방식은 브라우저가 서버로부터 비어있는 뼈대 HTML을 받아온 후, 필요한 자바스크립트 번들을 다운로드하고 번들을 실행하여 동적으로 컨텐츠를 채우는 방식입니다.
SSR(Server Side Rendering)
반면, SSR(Server Side Rendering) 방식은 서버에서 완성된 정적 HTML을 클라이언트에 내려주는 방식입니다. 클라이언트 측에서는 해당 HTML을 파싱만 하여 화면을 그리게 됩니다.
Next.js에서는, SSR 방식으로 정적인 HTML을 내려주어 초기 화면을 빠르게 렌더링한 후, Hydration을 통해 이벤트 리스너 부착 등의 자바스크립트 작업을 수행하여 정적인 화면을 동적으로 전환하는 작업을 수행합니다.
Hydration
Server Side에서 렌더링 된 정적 페이지(HTML)와 번들링 된 JS 파일을 클라이언트에게 보내면, Client Side에서 HTML 코드와 JS(React) 코드를 서로 매칭시키는 과정입니다.
SSR의 장점
-
SEO(검색 엔진 최적화)
화면이 동적으로 그려지는 CSR에 비해 크롤러가 컨텐츠를 쉽게 인식하며, 초기 로드가 상대적으로 빨라 우선순위가 부여되어 상위에 노출될 가능성이 높아지기 때문입니다. 이런 점에서 SSR은 블로그나 커머스 등 SEO가 중요한 웹 애플리케이션에 특히 적합합니다. -
빠른 초기 로딩 속도
CSR과 달리 SSR에서는 번들을 다운로드 받거나 번들을 실행하여 동적으로 화면을 그려야 할 필요가 없기 때문입니다.
SSR의 단점
-
페이지 전환 지연
전통적인 SSR 방식에서는 클라이언트 사이드 라우팅이 불가능하기 때문에 빠르고 매끄러운 페이지 전환 경험을 제공하기 어렵습니다(페이지 전환 시 새로고침이 일어남). -
서버 비용 증가
단순히 정적인 리소스를 내려주는 것이 아니라, 요청 시마다 페이지를 동적으로 구성해서 내려주어야 하는 경우에는 WAS 서버 구동으로 인해 서버 비용이 증가할 수 있습니다.
Next.js를 통한 SSR의 단점
-
상호작용 초기화 지연
Hydration을 통해 동적인 화면으로 전환할 경우 상호작용 초기화가 비교적 느립니다. 이는 페이지가 표시되기까지 걸리는 시간(TTV)과 상호작용까지 걸리는 시간(TTI) 사이에 격차가 발생한다는 의미입니다. 그 사이에 사용자가 버튼을 클릭해도 동작하지 않는 등의 답답한 상황을 겪을 수 있습니다. -
높은 구현 복잡도
현대의 웹 앱은 SSR과 CSR을 동시에 사용하는 경우가 많습니다. 이 때 클라이언트 사이드 로직과 서버 사이드 로직을 구분해가면서 구현해야 하기 때문에 상대적으로 구현 복잡도가 높습니다.
