SSR

❓질문

SSR(Server Side Rendering)에 대해 설명해주세요.

💡 조사하기전 내가 알고 있던 내용

먼저 CSR은 브라우저가 비어있는 HTML를 받고 필요한 자바스크립트 번들을 다운로드하고 동적으로 컨텐츠를 채우는 방식입니다.
반대로 SSR방식은 서버에서 정적 HTML를 내려주는 방식입니다.
이를 통해서 크롤러가 채워진 HTML을 볼수있기 때문에 SEO최적화 측면에서 유리합니다.

그리고 근래 프레임워크 next.js는 SSR로 받은 HTML에 <sciprt> 태그를 읽어 자바스크립트를 다운한뒤 하이드레이션 작업을 거쳐 html에 이벤트 리스너와 상태를 추가하여 동적인 컨텐츠 제작을 할수있게 도와줍니다
13버젼이후 app router에서는 rsc rcc개념이 등장하나 ssr과 혼동하면 안되고 봐야할점은
streaming ssr을 지원을 한다는 것이다. 이는 전체 페이지가 완성되는것을 기다리지않고 준비된 UI부터 점진적으로 스트리밍 할수있게 해주는 기법이다

🏫 정리한 내용

SSR의 개념을 적었기때문에 장단점만 요약하겠습니다.

SSR의 장점 SEO측면에서 유리하고 사용자가 빠른 초기 로딩 속도를 경험 할 수 있습니다. CSR과 다르게 SSR에서는 번들을 다운받거나 번들을 실행하여 동적으로 화면을 그려야 할 필요가 없기 떄문입니다.

SSR의 단점은 전통적인 SSR 방식에서는 클라이언트 사이드 라우팅이 불가능하기 때문에 빠르고 매끄러운 페이지 전환 경험을 제공하기 어렵습니다. 요청시 마다 페이지를 동적으로 내려주어야하는 경우에는 WAS 서버 구동 으로 인행 서버 비용이 증가할 수 있다는 단점도 있습니다.

Next.js를 통한 최신 방식으로 SSR을 구현할 경우에는 다음과 같은 단점이 있습니다.

첫째 hydration을 통해 동적인 화면으로 전환할 경우 상호 작용 초기화가 비교적 느립니다.
이는 페이지가 표시되기까지 걸리는 시간(TTV)과 상호작용까지 걸리는 시간(TTI) 사이에 격차가 발생한다는 의미입니다. 그 사이에 사용자는 버튼을 클릭해도 작동이 되지않는 답답한 경험을 줄수있습니다.

둘째 상대적으로 구현 복잡도가 올라갑니다. 현대의 웹앱은 SSR과 CSR을 동시에 사용하는 경우가 많습니다. 이떄 클라이언트 사이드 로직과 서버 사이드 로직을 구분해가면서 구현 해야 하기떄문에 상대적으로 구현 복잡도가 높습니다.