CSR(Client-side Rendering)이란.

 CSR이란 말 그대로 서버가 아닌 클라이언트의 브라우저 프로세스가 동적으로 자바스크립트를 사용하여 html 구조를 렌더링 하는 방식을 뜻합니다. 클라이언트에서 어플리케이션 사이트의 html을 요청 시, 클라이언트는 body 태그에 아무 내용이 없는 html 파일을 응답으로 받게되고 이 html 파일로 dom 트리를 만들다가 src 태그에서 요청하는 자바스크립트 파일을 추가로 요청합니다. 이 자바스크립트 파일에는 어플리케이션을 구동하기 위한 모든 자바스크립트 로직이 번들링되어 담겨져있습니다. 이제 브라우저 프로세스는 이 자바스크립트 파일을 평가하고 메모리에 적재해 브라우저 종료 전까지 필요한 부분을 호출하여 어플리케이션 동작이 이루어질 수 있도록 합니다. 이 CSR 방식으로 만든 개발 프레이뭐크인 React와 Vue.js 등은 클라이언트가 어플리케이션 사이트에 처음 진입할 때 단 한 번 html 파일을 다운받고 특수한 경우 외에는 다른 html 파일을 요청하지 않기 때문에 SPA(Single Page Application)이라고 부릅니다.

 

 다운받은 자바스크립트 파일에는 브라우저 내에서 url 변경 요청에따라 어떤 화면과 내용을 보여줄 것인지에 대한 모든 로직이 포함되어 있습니다. 즉, 현재 도메인 내에서 다른 경로로 get요청을 하게되면 해당 화면에서 보여질 html파일을 서버로 요청하여 새로운 화면을 렌더링하는 것이 아니라 자바스크립트 파일 내부의 로직을 사용하여 필요한 부분만을 재렌더링합니다. 따라서 불필요한 서버와의 접속을 방지할 수 있으며, 만약 서버에서 필요한 컨텐츠가 있다면 ajax를 사용한 비동기 요청을 통해 html이 아닌 json 형식으로 데이터를 요청합니다. 이 json 데이터는 추가로 자바스크립트 객체형식으로 파싱과정을 거쳐 내부 자바스크립트 로직으로 이 데이터를 핸들링할 수 있게 됩니다.

 

 CSR의 장점은 뷰(view)에 관련된 비즈니스 로직을 대부분 클라이언트(브라우저)에서 처리하기 때문에 서버의 역할이 대폭 줄어들어 서버자원의 관리가 용이해진다는 것입니다. 또한, 다른 페이지로 이동하거나 뷰가 바뀌는 로직을 처리할 때, 브라우저가 새로운 html 파일을 렌더링하는 것이 아니라 내부적으로 dom api를 활용해 기존 dom 트리를 수정하는 것이기 때문에 화면의 깜빡임이나 서버와의 통신으로 인한 지연 없이 빠르게 원하는 페이지를 확인할 수 있습니다. 따라서 사용자 경험 측면에서 강한 이점을 가진다고 할 수 있습니다.

 

 CSR개념을 활용한 사이트는 성능상에도 확연한 강점을 보입니다. React의 가상 dom과 일반 바닐라스크립트의 dom 조작의 비교로 예시를 들어보겠습니다. 일반적으로 dom 트리에서 dom 조작 api를 사용하여 요소 노드의 css속성을 수정하거나 텍스트 노드, 요소 노드의 수정 및 생성과 삭제를 수행하는 것은 렌더링 트리의 재생성과 화면 재배치 작업을 요구합니다. dom 조작 api가 호출된다면 브라우저는 다시 렌더링 트리를 만들기 위해 수정된 dom 트리와 cssom 트리를 합쳐 렌더링 트리를 재구성합니다. 이후 브라우저는 화면의 뷰포트를 고려해 레이아웃을 작성하고 각 요소들의 위치를 결정합니다. 배치구성이 확정된 렌더링 트리는 실제 픽셀로 변환되어 화면에 반영됩니다. 이와 같은 작업들은 많은 연산들을 요구하며 특히 dom 조작 api들이 순간적으로 여러번 호출된다면 순간적으로 많은 자원들을 요구하게되기 때문에 실행에 치명적입니다. 반면 React같은 CSR어플리케이션은 수정된 dom 요소의 반영을 한 번에 모아서 처리하는 batching 작업을 수행하기 때문에 이에 자유로울 수 있습니다. batching 작업을 수행할 수 있는 중요한 요소는 바로 가상 돔(virtual dom)입니다. 이 가상 돔은 view를 컴포넌트화하여 트리 구조로 구성한 개념이며, 실질적으로 하나의 자바스크립트 객체로서 메모리에 존재합니다. 만약 CSR 어플리케이션에서 dom에 접근을 하여 수정 작업을 수행하면 브라우저는 이 수정 사항을 반영하지 않습니다. 왜냐하면 이러한 어플리케이션에서 dom 조작은 가상 돔을 통한 접근만을 인정하기 때문입니다. 이러한 구조는 가상 돔에서 컴포넌트 상태의 변경이 이루어질 때만 수정된 가상 돔이 이전의 가상 돔과 비교되어, 변경된 컴포넌트와 그 자식 컴포넌트들 만을 실제 dom의 수정에 적용합니다. 즉, 원하는 dom의 변화들을 컴포넌트의 상태 변화를 통해 한 번의 재렌더링으로 실제 view에 반영할 수 있기 때문에 성능상의 이점을 갖는다는 것입니다. 특히 요즘처럼 브라우저의 발달과 웹 시장의 거대화로 인해 소비자의 이목을 끄는 다이나믹한 웹어플리케이션에 대한 많은 기대와 수요가 있는 현재, CSR + SPA의 이러한 이점은 큰 주목을 받습니다.

 

 반면에 CSR + SPA의 단점은 번들링된 메인 자바스크립트 파일의 용량이 클 경우 브라우저가 해당 파일을 평가하는데 다소 시간이 걸릴 수 있다는 점입니다. CSR는 해당 어플리케이션에서 사용되는 모든 자바스크립트와 CSS 로직을 하나의 자바스크립트 파일로 압축해 번들링하기 때문에 볼륨이 큰 프로젝트의 경우 자바스크립트 파일의 용량 역시 클 수 밖에 없습니다. 브라우저는 dom을 만들어 렌더링 트리를 완성하기 전에 필요한 자바스크립트파일을 요청해 평가하기 때문에, 자바스크립트 파일의 용량이 크다면 이를 평가하는 동안 뷰가 사용자에게 보여지지 않고 아무것도 없는 하얀 화면만이 사용자에게 보여집니다. 이는 사용자 경험에 부정적인 영향을 미칩니다. 즉, CSR의 강점인 클라이언트 사이드 렌더링 방식이 역으로 약점이 될 수 있다는 것입니다.

 

 또한, SEO에 대한 문제도 빠질 수 없습니다. 이는 두 번째 문제인 다음 포스트 SSR이 필요한 이유에서 추가로 기술하겠습니다.

 

-----------------

 

이 글은 원티드 프리온보딩 첼린지 사전 과제를 위해 작성한 글입니다.

 

개인적으로 공부하면서 정리한 글이라 틀린 부분이 있을 수 있습니다.

 

틀린 부분은 지적해주시면 감사하겠습니다.