렌더링이 무엇인지와 렌더링 과정에 대해서 간단히 살펴보고
서버 사이드 렌더링, 클라이언트 사이드 렌더링에 대해서 알아보도록 하자.
웹 페이지는 html, css, js로 이루어져있다.
이런 웹 페이지가 브라우저에 표현되는 것을 렌더링이라고 한다.

이렇게 웹 페이지를 그리는 과정인 렌더링 과정을 서버와 클라이언트, 둘 중 어디에서 진행하는가에 따라서 SSR과 CSR로 나누는 것이다.
보통 템플릿 엔진을 활용해서 서버에서 동적인 데이터로 html을 생성하는 방식으로 동작한다. 서버에서 데이터와 html을 모두 제공해준다.
js가 로드되지 않아도 html이 렌더링되어 보여지는 것이다. 따라서 사용자에게 브라우저 화면이 빠르게 보여질 것이다.
그래서 사용자가 느끼는 초기 응답 속도가 빠르다.
하지만 화면은 렌더링 되었지만 js가 아직 로드되지 않은 상태라면 동적인 기능은 동작하지 않을 것이므로, 버튼을 클릭해도 동작하지 않는 경우가 발생할 수 있다. 즉, 상호작용은 불가능한 상태일 수 있다.
조금 멋지게 말해보면 TTV는 빠르지만 TTI와의 차이가 난다.
js가 로드되지 않아도 html이 이미 전부 로딩된 상태이므로, 검색 엔진에도 유리하다.
웹 크롤러가 js를 읽어오는데에는 어려움있어서 온전히 로드된 html을 제공하는 SSR 방식이 검색 엔진 최적화에 더 유리하다고 한다.
일대일 대응으로 모든 사용자에게 요청을 받고 응답으로 웹페이지를 생성하고 전송하는 것이기 때문에, 많은 사용자가 동시 접속할 경우 서버에 부담이 될 수 있다.
요약을 해보자면 SSR의 장단점은 다음과 같다
장점
단점
최소한의 html 파일만을 가지고 있고, js를 통해서 동적으로 html을 추가하는 방식으로 동작한다.
서버는 데이터만을 제공하고, 클라이언트가 html을 제공한다.
React, Vue.js와 같은 프레임워크가 CSR 방식으로 동작한다.
서버 사이드 렌더링과는 다르게 js가 로드되어야 html도 로드되는 것이므로 SSR의 장점이 CSR의 단점, SSR의 단점이 CSR의 장점이 된다.
장점
단점
그래서 둘 중에 뭐가 더 좋고, 뭘 써야 하는가?
역시나 정답은 없다...
초기 렌더링은 SSR로 진행하고, 그 이후 동작에 따른 렌더링은 CSR를 사용하는 방식으로 SSR과 CSR을 혼합해서 사용하기도 한다고 한다.
Refs