CSR / SSR (+ SPA / MPA)

SPA

SPA란 Single Page Applicaion으로 하나의 페이지로 구성된 애플리케이션을 말한다.최근 웹 애플리케이션은 리액트, 앵귤러, 뷰와 같은 자바스크립트기반 프레임워크를 사용해서 SPA로 개발되고 있다. 헤더는 고정되어 있고 헤더의 링크를 클릭하면 특정 영역만 바뀌는 웹페이지가 그 예시이다.

 

MPA

MPA란 Multi Page Application으로 탭을 이동할 때마다 새로운 html 페이지를 받아와서 페이지를 새로 렌더링하는 전통적인 웹페이지 구성 방식이다. 매번 새로운 HTML을 서버로부터 받아오기 때문에 전환 시 매번 화면이 깜빡인다는 단점이 있다. 이를 보완하기 위해 화면의 원하는 부분만 동적으로 받아오는 AJAX를 사용할 수 있다.

 

CSR/SSR과 SPA/MPA와의 관계

일반적으로 SPA에서는 CSR 방식을 사용하고, MPA는 SSR 방식을 사용한다. SPA는 웹 애플리케이션에 필요한 정적 리소스를 초기에 모두 다운로드하고, 그 이후 새로운 페이지 요청이 있을 때 페이지 갱신에 필요한 데이터만 전달받아서 클라이언트에서 페이지를 갱신하기 때문에 자연스러운 렌더링을 할 수 있다. MPA는 새로운 요청이 있을 때마다 서버에서 렌더링된 정적 리소스를 받아오기 때문에 SSR 방식을 사용한다. 예시로 php나 jsp 등이 있다.

 

CSR/SSR의 개념

CSR은 Client Side Rendering으로 클라이언트에서 렌더링을 하고, SSR은 Server Side Rendering으로 서버에서 렌더링을 하는 방식이다. Client와 Server 중 어느 쪽에서 렌더링을 준비하는지에서 차이가 있다.

추가로 SSG는 Static Site Generation으로 Static Rendering이라고도 불리는 방식이다. 서버에서 html을 보내주는 것은 SSR과 비슷하지만, 차이점은 서버에서 html을 만드는 타이밍이 다르다. SSR은 요청할 때 즉시 만들기 때문에 데이터가 변하는 페이지에 적합하다. 반대로 SSG는 미리 다 만들어두기 때문에 바뀔 일이 거의 없는 페이지에 적합하다. 

 

CSR의 동작 과정

CSR은 유저가 웹사이트에 방문하면 브라우저가 서버에 콘텐츠를 요청하고 서버는 빈 뼈대만 있는 html을 응답으로 보내준다. 브라우저는 연결된 js 링크를 통해 서버로부터 다시 js 파일을 다운로드받고, 이를 이용해 동적으로 페이지를 만들어 띄워준다. js 파일을 다운로드 받고 동적으로 dom을 생성하는 시간을 기다려야 하기 때문에 초기 속도는 느리지만, 이후에는 필요한 데이터만 서버에 요청하기 때문에 구동 속도는 빠르다는 특징이 있다. 또한 서버는 뼈대만 있는 html을 보내주면 되기 때문에 부하가 적다는 장점이 있다. 이외에 클라이언트에서 연산, 라우팅 등을 직접 처리하기 때문에 반응 속도도 빠르고 ux도 우수하다는 장점이 있다.

하지만 html에 내용이 텅 비어있기 때문에 검색 엔진이 색인을 할 만한 컨텐츠가 없다. 따라서 검색 엔진 최적화에 불리하다는 치명적인 단점이 있다. Googlebot은 자바스크립트를 실행할 수 있지만 완벽한 단계가 아니기도 하고 이를 제외한 나머지 검색 엔진(ex. Bingbot, SlurBot, BaidusSpider 등)은 실행이 불가능하다.

 

SSR의 동작 과정

SSR은 유저가 웹사이트에 방문하면 브라우저가 서버에 콘텐츠를 요청한다. 서버에서는 즉시 페이지에 필요한 데이터를 넣어 모두 삽입하고, css까지 적용해서 렌더링 준비를 마친 html과 js를 전달한다. 브라우저에서는 바로 전달받는 페이지를 띄우고 js code를 다운로드하고 로직을 연결한다. 따라서 CSR과 반대로 모든 콘텐츠가 담겨져있기 때문에 검색 엔진 최적화에 유리하다. 또한, js를 다운로드받고 실행하기 전에 사용자가 화면을 볼 수 있어 초기 구동 속도가 빠르다는 특징이 있다. 하지만 js 로직이 연결될 때까지 사용자의 입력에 응답할 수 없다는 치명적인 단점이 있다. 즉, Time To View와 Time To Interact간 시간차가 있다는 단점이 존재한다.

 

CSR과 SSR의 장단점

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

 

CSR 단점 보완 방법

1. 초기 로딩 속도

• code splitting
• tree-shaking
• chunk 분리

 

2. SEO 개선

• pre-rendering

 

+ CSR을 사용하고 있는 SPA에 SSR이나 SSG를 도입하는 것도 방법이 될 수 있다. 

 

CSR에 SSR/SSG을 도입하는 방법

without 프레임워크

express.js로 별도의 서버를 직접 운영하거나 nest.js를 활용하는 방법이 있다. 하지만 서버 환경이나 빌드가 생소하다면 복잡할 수 있다.

 

with 프레임워크

Next.js는 리액트에서 SSR이나 SSG를 사용할 수 있게 지원하는 프레임워크로, 페이지별로 SSR이나 SSG를 선택 가능하다. Gatsby.js는 SSG에 최적화된 리액트 기반 정적 페이지 생성 프레임워크이고, SSG 이외에도 CSR, SSR, 레이지 로딩도 지원한다. Nuxt.js는 뷰를 위한 프레임워크이다. Angular Universal은 앵귤러에서 SSR을 가능하게 해준다.(Angular4부터는 아예 코어 모듈에 포함되어 있다)

이러한 프레임워크들이 CSR에 SSR이나 SSG 도입을 편리하게 해주지만, CSR에 비해 코드 복잡도는 증가한다. 또한, 프레임워크를 사용하기 때문에 직접 제어할 수 없는 블랙박스 영역이 생기게 된다.

 

Isomorphic App, Universal Rendering

위 용어는 초기 렌더링은 SSR을 사용하고 이후에는 CSR을 사용하는 앱이나 렌더링을 부르는 방식이다. Isomorphic App은 서버와 클라이언트에서 동일한 코드가 동작하는 앱이라는 의미로 해석할 수 있다. 서버와 클라이언트가 같은 코드를 사용하기 때문에 예상과는 다른 결과를 마주할 가능성도 있지만, 초기 로딩 속도 보완 / SEO 개선 / CSR의 장점을 가져갈 수 있다는 특징이 있다.

 

참고

https://youtu.be/YuqB8D6eCKE