이전 포스팅에서, CSR의 한계점을 극복하기 위해 SSR(Server-side Rendering)가 떠올랐다고 하며 이전 포스팅을 마무리했다.
CSR(Client Side Rendering)이 직면한 문제점들
1. 최초 로딩시간이 길어질 수 있다
CSR의 한계점을 다시 한번 간략하게 정리하면 CSR은 텅텅 빈 index.html을 반환하고, 브라우저가 서버로부터 하나의 bundle.js 파일을 내려받아 화면에 element를 그리게 된다. (즉 SSR과 달리 완성된 html파일을 내려받지 않는다.) 이때 프로젝트가 커지면 커질수록 js 파일도 커져 클라이언트(브라우저)가 파일을 내려받는 시간이 오래 걸리게 되고, 화면을 내려받는 시간 동안 빈 화면만 보여주게 되어 사용자가 첫 화면을 보기까지 시간이 오래 걸릴 수 있다는거다.
2. SEO가 좋지 않다
이외에 좋지 않은 SEO(Search Engine Optimization)가 있다. SEO란 검색 엔진 최적화로 검색 엔진(Google, Naver, Web Crawlers)이 웹페이지를 발견하고, 읽어가고, 검색 엔진에 노출시켜 트래픽의 양과 질을 높일 수 있도록 웹사이트의 구조나 콘텐츠를 개선하는 작업을 의미한다.
검색엔진들은 서버에 등록된 웹사이트들을 추적하며 웹사이트의 HTML 문서를 분석해 웹사이트가 어떠한 컨텐츠를 제공하는지 파악한다. 그래서 사용자가 검색엔진에 어떠한 키워드를 검색했을 때, 읽어들인 웹사이트의 정보와 일치하는 검색 결과를 보여줄 수 있는거다.
그런데 문제는, CSR은 서버로부터 내려받는 index.html 파일의 내부가 텅텅 비어져 있다는거다. 따라서 검색 엔진들이 CSR로 작성된 웹페이지를 분석하는데 많은 어려움을 겪게 되어 결국 SEO가 좋지 않게 되는 것이다.
떠오른 SSR(Server-Side Rendering)
이러한 CSR의 문제점들이 대두되면서 **SSR(서버 사이드 렌더링)**이 떠오르게 된다. CSR이 클라이언트에서 모든 것을 처리하는 방식과는 다르게 SSR은 서버로부터 완성된 html 파일과 함께 html 파일을 동적으로 제어할 수 있는 js 파일을 내려받게 된다.
→ 그러면 이제 CSR과 달리 클라이언트(브라우저)가 서버로부터 html 문서를 받아오기 때문에 이 완성된 html을 DOM에 그려서 사용자에게 바로 보여줄 수 있게 되는 것이다!
SSR은 이런게 좋대요
1. 첫번째 페이지 로딩이 빨라진다
CSR과 달리, 서버로부터 완성된 html 파일을 내려받기 때문에 이 html을 바로 사용자들에게 보여줄 수 있어 최초 페이지 로딩이 빨라진다!
2. 좋은 SEO 🥳
서버로부터 완성된 html을 받기 때문에 모든 컨텐츠가 이제 html 요소 안에 다 들어있다. 따라서 완성된 html 파일을 검색 엔진에서 분석할 수 있게 되어, SEO가 더 좋아진다.
그러면 SSR은 완벽한가요? SSR이 가진 문제점
CSR의 문제점을 극복한 SSR은 그래서 다 완벽할까? 물론… 아니다.
1. 깜빡임 이슈 🫥
SSR은 페이지 이동을 할 때 마다 서버로부터 html 파일을 다시 내려받게 된다. 이 때 페이지 리로드가 일어나며 화면이 깜빡거리는 이슈가 발생한다.
2. 서버의 과부하 🤒
페이지를 이동할 때 마다 ‘페이지에 해당하는 html 좀 보내줘~’ 라고 서버에 요청을 보내고, 서버에서 필요한 데이터를 가져와서 html을 만들어야하므로 서버에 과부하가 걸리기 쉬워진다..🤒💦
3. TTV(Time To View) 와 TTI(Time To Interaction)가 일치하지 않음
사용자가 페이지를 보는 시점은 빨라졌지만, 동적인 데이터를 처리하는 자바스크립트 코드는 아직 내려받지 못해서 사이트를 클릭하는 등의 인터렉션을 발생시켜도 반응이 없을 수 있다. 이것을 TTV(Time To View)와 TTI(Time To Interaction)가 다르다고 한다.
CSR과 SSR의 TTI, TTV
CSR의 TTI, TTV
CSR의 작동 방식을 살펴보면 다음과 같다. 서버로부터 비어있는 index.html을 받아오고, JS 파일을 요청하고 JS파일을 내려받은 그 시점부터 화면을 볼 수 있으며, 동시에 웹사이트에 인터렉션(클릭 등)을 할 수 있다. 즉TTV(Time To View)와 TTI(Time To Interaction)의 시점이 동일한 것이다. (TTI=TTV)
SSR의 TTI, TTV
반면 SSR의 작동 방식은 CSR과 조금 다르다. 일단 SSR은 서버로부터 완성된 index.html 파일을 내려받는다. 하지만 사용자의 클릭과 같은 인터렉션을 동적으로 처리할 수 있는 자바스크립트 파일은 아직 내려받지 않은 상태다. 따라서 index.html을 내려받은 이 시점에서 사용자가 완성된 html 파일에서 클릭을 해도 반응이 없는 현상이 발생하게 되고, 클라이언트가 서버로부터 js파일을 모두 내려받은 이후부터 인터렉션이 가능해진다. 즉, TTV(Time To View)와 TTI(Time To Interaction)의 시점이 다르다. (TTI =/=TTV)
따라서 SSR과 CSR은 모두 장점과 단점이 존재한다고 볼 수 있다. CSR을 활용하고 싶다면 CSR의 단점을 극복하기 위해 bundle.js의 사이즈를 줄일 수 있는 방법을 생각해보고, SSR을 활용하고 싶다면 SSR의 단점을 해결하기 위해 TTV와 TTI의 간극을 어떻게 줄일 수 있을지 생각해보면 좋겠다.
SSG(Static Side Generation)
이러한 CSR과 SSR의 문제를 해결하기 위해 SSG(Static Side Generation)도 존재한다. 이 SSG를 활용할 수 있는 다양한 프레임워크가 존재하는데 다음 포스팅때는 Next.js가 SSG를 어떻게 활용하는지 포스팅해보려고 한다! 그럼 다음 시간에~👋
출처 (Reference)
