CSR, SSR

CSR(Client Side Rendering)

CSR은 Client Side Rendering을 줄인 말로 클라이언트로 렌더링 책임을 넘기는 방식입니다. Single Page Application(SPA)를 구축하는데 주로 사용합니다. SPA는 하나의 페이지로 이뤄진 애플리케이션으로 페이지를 동적으로 변경해 콘텐츠를 렌더링합니다. 이러한 방식은 페이지의 리로딩이 없어 자연스러운 화면 전환과 좋은 사용자 경험을 제공합니다.

위의 그림처럼 서버로부터 하나의 HTML을 받고 필요한 영역의 데이터만 요청해서 갱신할 수 있기 때문에 훨씬 효율적입니다. 이처럼 클라이언트 영역에서 화면을 제어하는 렌더링 방식을 Client Side Rendering(CSR)이라고 부릅니다.

하지만 SPA 역시 단점은 존재합니다.

애플리케이션의 규모가 커지면 초기에 로딩해야하는 자바스크립트나 CSS 번들 파일의 용량 증가로 초기 로딩 성능이 저하됩니다. → 초기 구동 속도가 느림

검색 엔진의 봇(bot)은 자바스크립트 코드를 실행하지 않고 파싱된 HTML만 대상으로 크롤링합니다. 때문에 SPA 같은 경우 데이터를 크롤링하기 어려워 검색 엔진 최적화(SEO)가 어렵습니다. 최근 구글의 검색 엔진에서는 자바스크립트 코드 처리를 지원하긴 하나 어느 정도의 성능인지 개발자로서는 가늠하기 어려우며 이 외 다른 검색 엔진에서도 지원할 지도 의문입니다.

이러한 단점을 보완하기 위해서 아래의 방법을 시도해볼 수 있습니다.

트리 셰이킹, 코드 스플리팅, chunk 분리과 같은 기법을 사용하여 번들 파일 용량을 줄입니다.

pre-rendering을 통해 SEO개선

Server Side Rendering(SSR), Static Site Generation(SSG) 도입을 통해 초기 로딩 속도 보완 및 SEO 개선

CSR의 동작 과정

CSR의 구체적인 동작 과정을 알아보겠습니다.

1. 유저가 웹사이트에 방문하면, 브라우저가 서버에 콘텐츠를 요청한다.

2. 이에 서버는 빈 뼈대만 있는 HTML을 응답으로 보내준다.

3. 브라우저가 연결된 JS 링크를 통해 서버로부터 다시 JS 파일을 다운로드한다.

4. JS를 이용해 동적으로 페이지를 만들어 브라우저에 띄워준다.

Server Side Rendering(SSR)

Server Side Rendering(SSR)은 서버에서 사용자에게 보일 페이지를 모두 구성해 사용자에게 보여 주는 방식입니다. Multi Page Application(MPA)에서 사용하던 렌더링 방식입니다.

SSR은 서버에서 페이지를 모두 구성해 전달하기 때문에 SEO를 보다 쉽게 처리할 수 있으며 페이지의 전체 콘텐츠가 구성되는 시점이 빠르다는 장점이 있습니다.

초기 페이지를 렌더링하는 시점 자체는 CSR이 SSR보다 빠르지만 CSR은 필요한 콘텐츠를 모두 구성하기 위해 추가적인 자바스크립트의 실행이 필요하므로 SSR보다 느립니다.

그래서 요즘 웹 페이지 개발 방법이 CSR을 사용하되 적재적소에 SSR을 사용해 단점을 보완하는 방법으로 CSR+SSR을 혼합해 사용합니다. 대표적인 라이브러리로 React의 프레임워크 Next.js와 Vue의 프레임워크인 Nuxt.js가 있습니다.

SSR의 동작 과정

SSR의 구체적인 동작 과정을 알보겠습니다.

1. 유저가 웹사이트에 방문하면, 브라우저가 서버에 컨텐츠를 요청한다.

2. 서버에서는 즉시 페이지에 필요한 데이터를 얻어와 모두 삽입하고, CSS까지 모두 적용해 렌더링 준비를 마친 HTML과 JS코드를 브라우저에 응답으로 전달한다.

3. 브라우저에서는 전달받은 HTML을 띄우고, JS코드를 다운로드하고 HTML에 JS로직을 연결한다.

SSR의 경우 서버에서 렌더링 준비를 마친 HTML을 전달하기 때문에 SEO 최적화에 유리합니다. 또한 브라우저가 JS코드를 다운로드 받고 실행하기 전에 사용자가 화면을 볼 수 있습니다. 때문에 CSR 방식보다 빠른 초기 구동 속도를 제공합니다.

하지만 빠른 초기 구동 속도를 가진다는 것은 하나의 장점이 되지만 동시에 단점이 되기도 합니다. JS코드가 다운로드 되기 전이기 때문에 사용자가 버튼을 클릭하거나 이동을 하려고해도 아무런 동작을 하지 않습니다. 상호작용(Interaction)이 가능한 페이지처럼 보이지만 내용과 스타일이 입혀진 껍데기에 불과합니다.

이렇게 SSR에는 Time To View(TTV)와 Time To Interact(TTI)사이의 시간 간극이 존재합니다. 반대로 CSR은 JS 코드를 다운받고 동적으로 페이지가 생성되고 나서야 사용자에게 페이지가 보여지게 되므로 사용자가 보는 시점(TTV)과 사용자가 이용할 수 있는 시점(TTI)가 동일합니다.

Static Site Generation(SSG)

CSR와 SSR 관련 내용에서 높은 빈도수로 출현하는게 SSG입니다. SSG는 Static Site Generation의 약자로 Static Rendering이라고 불리기도 합니다. 서버에서 HTML 파일을 전송해준다는 것은 SSG와 SSR과 동일하지만 언제 만들어두는냐에 차이가 있습니다.

SSR은 요청할 때 즉시 만들어 데이터가 달라지거나 미리 만들기 어려운 페이지에 적합합니다. 반면에 SSG는 미리 다 만들어 두기 때문에 바뀔 일이 거의 없는 페이지에 적합합니다.

CSR와 SSR의 오해

위의 원론적인 개념 설명을 읽으면 SPA === CSR, MPA === SSR 일 것 같지만 SPA !== CSR , MPA !== SSR 입니다. 이 둘의 차이점은 페이지 개수가 몇개냐, 어디서 렌더링이 되느냐의 차이입니다.

ㅤ	SPA	MPA
페이지 몇개?	1	여러개
어디서 렌더링?	클라이언트	서버

CSR과 SSR의 장단점

ㅤ	CSR	SSR
장점	- 화면 깜빡임이 없음 - 초기 로딩 이후 구동속도가 빠름 - TTV와 TTI 사이 간극이 없음 - 서버 부하 분산	- 초기 구동 속도가 빠름 - SEO에 유리함
단점	- 초기 로딩 속도가 느림 - SEO에 불리함	- 화면에 깜빡임이 있음 - TTV와 TTI 사이 간극이 있음 - 서버 부하가 있음