CSR
어제 알아본 SPA(Single Page Application)는 CSR(Client Side Rendering)로 동작한다.
CSR은 Client Side Rendering, 즉 클라이언트 측에서 렌더링이 동작하는 방식이다.
렌더링이란 쉽게 말하자면 화면에 사용자가 봐야하는 컨텐츠를 나타내는 것이라고 볼 수 있다.
그렇다면 클라이언트 측에서 렌더링이 실행된다는게 어떤 의미인지를 알아봐야한다.
위 그림과 같이 서버로부터 클라이언트는 index.html이라는 html파일 하나와 자바스크립트 파일, 그리고 필요한 데이터들을 받아온다.
문제는 이 자바스크립트 파일이 개발자가 작성한 코드 외에도, 라이브러리나 프레임워크의 소스코드도 포함한다는 것이다.
이 많은 파일들을 다운로드 받은 뒤, 이것들을 기반으로 동적으로 html을 생성해 사용자에게 보여주는 과정이 바로 CSR방식이다.
때문에 이러한 렌더링 방식은 사용자가 첫 화면을 보기까지의 시간이 오래 걸릴 수 있고, SEO(Search Engine Optimization)가 낮다는 단점이 있다.
SSR
SSR은 이러한 CSR의 단점들을 보완하기 위해서 Static Sites의 특징들을 따와 생겨난 렌더링 방식이다.
Server Side Rendering의 약자로 CSR과는 다르게 이 방식은 클라이언트에서 요청을 받으면 필요한 데이터를 서버에서 모두 처리해 html파일을 생성하고, 이 파일을 동적으로 제어할 수 있는 코드와 함께 클라이언트에 전송한다.
따라서 CSR보다 첫 페이지의 로딩시간이 짧아진다는 장점과, SEO가 높아진다는 장점이 있다.
다만, 모든 요청에 대해 완전히 새페이지를 로딩하고 렌더링해준다는 단점이 있어 사용자 경험이 낮아진다.
또 서버에 과부하가 걸리기 쉬우며, 동적으로 제어할 수 있는 코드를 html보다 늦게 다운로드받게되어 TTV(Time to view)보다 TTI(Time to interact)가 길어지는 현상. 즉, 클릭을 해도 반응이 일어나지 않는 경우가 발생할 수 있다.
SSG
이렇게 상황에 따라서 혹은 웹사이트의 특성에 따라서 CSR이나 SSR을 선택하는 경우가 있는데, 둘을 유연하게 사용하는 방식이나 SSG(Static Site Generation)라는 방식이 생겨나서 사용되기도 했다.
SSG는 CSR로 만든 웹 페이지를 미리 정적 웹 페이지로 생성해두어 서버에 배포가 가능하게 하는 방식이다.
그렇다고 정적인 웹 페이지인 것은 아니고 동적으로 필요한 데이터나 처리할 로직을 미리 JS파일로 함께 생성해놓는게 가능하다.
