CSR 클라이언트 사이드 렌더링

클라이언트 사이드 렌더링에서 클라이언트는 브라우저를 의미!

html을 가장 기본적인 것만 가져온 뒤 자바스크립트를 이용해서 DOM을 생성해서 html에 그려주면 어떨까? 라는 접근이 CSR이다.

DOM을 js가 직접 그려주기 때문에 html의 용량은 현저히 낮다. 대신 js의 용량이 커짐.

필요한 DOM만 그때그때 만들어 쓸 수 있다는 장점. html을 매번 불러오는 것이 아니라 js로 필요한 것만 그려낸다. 

이때 history API를 통해서 라우팅 처리를 하고 DOM을 이용해서 렌더링을 수행하게 된다.

리액트, 뷰, 앵귤러와 같은 SPA 프레임워크는 기본적으로 브라우저에서 컴포넌트를 만들어서 그 컴포넌트를 렌더링 시키는 것을 최우선 목표로 한다.

즉 리액트에서 컴포넌트를 만드는 행위가 DOM을 만드는 행위와 유사한 것이다. 그러나 DOM을 하나하나 만드는 것은 매우 귀찮은 작업이므로 html 대신 JSX라는 문법을 사용하여 자바스크립트 element를 만든다.

JS 번들 사이즈가 커진다는 단점이 있고 DOM을 브라우저에서 직접 만들기 때문에 브라우저의 컴퓨팅 파워를 많이 쓰게 된다. 이 때문에 렌더링 퍼포먼스가 저하된다. - 크롬이 메모리를 많이 먹는 이유는 크롬이 다양한 브라우저 렌더링을 수행해야 하기 때문이다. 대신 한번 렌더링 한 이후에는 필요한 부분(변경되는 부분)만 다시 렌더링 하면 되므로 성능상의 장점 또한 존재한다. 때문에 CSR이 반드시 느리다고 할 수도 없다. 다만 브라우저 파워는 많이 쓰게 된다(이건 쩔수). 아티클 위주의 웹사이트는 CSR을 할 필요가 없다. 그러나 페이스북, 인스타그램, 트위터처럼 실시간성이 중요한 웹일수록 CSR이 유리하다.

CSR과 SSR을 섞어서 쓸 수도 있고, SSR과 SSG를 섞어서 쓸 수도, CSR과 SSG를 섞어서 쓸 수도 있다. 다양한 아키텍처들 사이에서 유연하게 사용하는 것이 중요하다.