CSR과 SSR을 알아보기 전에 SPA와 MAP에 대한 개념부터 집고 넘어가려고 한다.
SPA / MPA
오늘날 웹 애플리케이션 개발을 한다고 하면 대부분 리액트, 뷰, 앵귤러 같은 JS기반 프레임워크를 사용해서 SPA(Single Page Application)를 개발한다.
SPA는 말 그대로 한개의 페이지를 가진 어플리케이션이다.
예를들어, 어플리케이션을 이용할때 헤더는 고정되어 있고, 메뉴를 선택하면 메인 화면 부분 혹은 클릭한 부분만 바뀌는 사이트들을 많이 보았을 텐데 이러한 웹사이트들이 SPA이다.
반면 MPA란 Multi Page Application의 약자이다. 예를들어 탭을 이동할 때마다 서버로부터 새로운 html을 새로 받아와서 페이지 전체를 새로 렌더링 하는 전통적인 웹 페이지 구성 방식이다.
아직도 MPA로 구성된 페이지들이 있지만 서버로부터 HTML파일을 받아오거나 페이지 이동시 화면이 깜빡거림이 발생하기 때문에 AJAX가 등장하면서 부터 필요한 부분만 클라이언트에서 랜더링이 가능하고, 좋은 사용자 경험을 전달하는 SPA를 사용하게 되었다.
기본적으로 SPA는 CSR(Client Side Rendering) 이고, MAP는 SSR(Server Side Rendering) 방식을 사용한다.
SPA(Single Page Application)은 웹 어플리케이션에 필요한 정적 리소스를 서버에서 한번에 불러온 후 새로운 요청이 있을때만 클라이언트에서 페이지를 갱신하기 때문에 자연스럽게 랜더링 하는 방식인 CSR을 사용하게 되었고, MAP(Multi Page Application)은 새로운 요청이 있을 때마다 서버에서 이미 랜더링 된 정적 리소스를 받아오는 랜더링 방식으로 SSR을 사용하게 되었다.
하지만 SPA === CSR, MPA === SSR 은 아니다.
CSR(Client Side Rendering)
CSR은 모바일 웹에 대한 요구가 커지면서 등장했다.
클라이언트 사이드 랜더링은 클라이언트인 브라우저가 랜더링을 처리하는 방식이다.
즉, 서버에서 받은 데이터를 통해 클라이언트인 브라우저가 View를 그리는 주체가 된다.
사용자가 웹사이트를 방문하면 서버에 콘텐츠를 요청하고, 서버는 빈 뼈대만 있는 HTML 파일을 응답으로 내려준다.
그리고 브라우저가 연결된 JS 링크를 통해 서버로 부터 다시 JS 파일을 다운받고, JS를 이용해 동적으로 페이지를 만들어서 브라우저에 띄어준다.
특징적인 부분은 JS파일을 다운로드 받아 동적으로 페이지를 만들어서 띄어준다는 부분이다. CSR은 브라우저가 JS파일을 다운 받고, 동적으로 DOM을 생성하는 시간까지 모두 마쳐야 하기 때문에 초기 구동속도가 느리다.
하지만 사용자가 요청이 있을때만 부분적으로 서버에 요청해서 클라이언트에서 변경하기 때문에 초기 로딩 이후에는 빠르게 랜더링 된다는 특징이 있다.
서버는 빈 HTML을 넘겨주는 역할만 수행하기 때문에 서버 부담이 줄어든다.
클라이언트 측에서 연산, 라우팅 등을 모두 직접 처리하기 때문에 반응 속도가 빠르고, UX도 우수하다는 장점이 있다.
하지만 구글과 네이버 같은 검색엔진에서 HTML 파일을 빈 파일로 인식하기 때문에 검색엔진이 색인할 만한 컨텐츠가 존재하지 않아서 검색엔진최적화(SEO)에 적합하지 않다.
CSR은 JS가 동적으로 DOM을 생성하기 때문에 HTML은 JS로직이 모두 완전히 연결된 상태라 사용자가 보는 시점과 인터렉션할 수 있는 시점이 동일하다. 즉, CSR은 TTV(Time To View)와 TTI(Time To Interact)의 간극이 거의 없다.
SSR(Server Side Rendering)
SSR(Server Side Rendering)은 전통적인 랜더링 방식이다.
SSR 단어 그대로 서버에서 렌더링 작업을 하는 것이다. 클라이언트측 (브라우저)에서 서버에 매번 데이터를 요청하여 서버에서 처리한다. 사용자가 웹페이지에 접근할 때 서버에서 페이지에 대한 요청을 하며, html, view와 같은 새로운 리소스들을 랜더링해서 사용자에게 반환한다.
즉, 서버가 View를 그리는 주체가 된다.
특징
-
서버에서 랜더링 준비를 마친 HTML을 브라우저에 전달하는 부분이다. 모든 데이터가 이미 HTML에 담겨진채로 브라우저에 전달되기 때문에
검색엔진최적화(SEO)에 유리하다. 이는 검색엔진의 크롤러 봇이 문제 없이 HTML을 읽을수 있기 때문이다. CSR은 HTML의 바디 부분이 텅텅 비어있기 때문에 검색엔진들이 분석하는데 어려움이 있다. -
JS 코드를 다운받고, 실행되기 전에 서버에서 View를 그리기 때문에 사용자가 화면을 빠르게 볼 수 있다. 초기 구동속도가 빠르다는 의미이다. 하지만 이것이 치명적인 단점이 된다. JS코드를 다운받기 전에 뷰가 먼저 보여지는 이 시점에 사용자가 버튼을 클릭하거나 페이지를 이동하는 등 어떤 동적인 이벤트에 반응을 하지 않는 다는 점이다. 인터렉션이 불가능한 껍데기에 불가하다.
클라이언트 측에 JS가 실행되고 이벤트 핸들러가 첨부되어서 JS 로직이 모두 연결 이후에 인터렉션이 가능하다.
이렇게 때문에 SSR은 TTV(Time To View)와 TTI(Time To Interact)간에 간극이 존재한다.
웹서버에 요청할때마다 브라우저 새로고침이 일어나고 서버에 새 페이지 요청을함
SSG(Static Site Generation)
CSR과 SSR을 공부할 떄 SSG도 함께 언급된다.
Static Rendering이라고도 불리는 방식이다. 서버에서 HTML을 보내준다는 측변에서 SSR과 비슷하지만 HTML 파일을 언제 만들어 주냐에 차이가 있다.
SSR은 요청시 서버에서 즉시 HTML 파일을 만들어서 응답하기 때문에 데이터가 달라지거나 자주 바뀌어서 미리 만들어 두기 어려운 페이지에 적합하다.
SSG는 페이지들을 서버에서 모두 만들어 둔 뒤에 요청시에 해당 페이지를 응답하는 것이기 때문에 바뀔일이 거의 없어서 캐싱해 두면 좋은 페이지에 사용하면 적합하다.
TTV (Time To View) : 사용자가 웹브라우저에서 내용을 볼 수 있는 시점
TTI(Time To Interact) : 사용자가 웹브라우저에서 인터랙션 할 수 있는 시점
검색엔진최적화(SEO) : 사용자가 특정 키워드를 검색했을 때, 해당 웹사이트나 콘텐츠가 상단에 위치할 수 있도록 작업하는 것을 말한다. 사용자가 어떤 키워드를 중심으로 웹사이트를 이용하는지 알 수 있다. 이는 구글과 네이버 같은 검색엔진의 크롤러 봇들이 서버에 등록된 웹페이지의 HTML 파일에 접근해서 타이틀이나 디스크립션 혹은 링크 등을 파학 한 후 어떤 검색어로 검색해야 할지 검색엔진에 등록한다.
장단점
CSR(Client Side Rendering)
장점
- 새로고침이 발생하지 않고, 화면 깜박임이 없다.(랜더링을 클라이언트에서 하기 때문)
- 네이티브 앱과 비슷한 빠른 인터렉션을 구현할수 있다.
- 초기 로딩 이후 구독 속도가 빠르다.
- TTV와 TTI사이 간극이 없다. 즉, 전체적으로 매끄러운 사용자 경험이 특징
- 서버 부하가 분산된다.
단점
- 초기 로딩 속도가 느리다.
- 검색엔진최적화(SEO)에 불리하다.
- 검색엔진 크롤러가 해당 웹사이트의 초기 html파일을 빈 파일로 인식하기 때문이다.
CSR 단점 보완하는 방법
- code splitting, tree-shaking, chunk 분리를 통해 JS 번들 크기를 중리고, 초기 DOM 생성 속도를 줄이면 초기 구동 속도를 보완할 수 있다.
- pre-rendering을 통해 seo를 개선할 수 있다. 라이브러리나 웹팩 플러그인을 통해 각 페이지에 대한 HTML 파일을 미리 생성해 두는 방식을 개선 할 수 있다.
- SSR, SSG를 CSR앱에 도입해서 단점을 보완할 수 있다. 대표적인 방법으로 Next.js(react), Nuxt.js(vue)같이 SSR을 구현할 수 있도록 도와주는 프레임워크를 사용하는 것이다.
SSR(Server Side Rendering)
장점
- 초기 구동속도가 빠르다.
- 검색엔진최적화(SEO)에 유리하다.
단점
- 페이지 이동시마다 화면 깜박임이 발생해서 좋은 사용자 경험을 전달하기에 무리가 있다.
- TTV와 TTI 사이 간극이 있어 사용자 경험이 안좋다.
- 부분 랜더링이 아니라, 매 페이지 로딩시 서버에 요청하기 때문에 서버 부하가 있다.
참고
