[개념 정리] SSR과 CSR의 차이점 및 장단점 (SPA, MPA)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

그림 1-1. SSR vs CSR

 

 

SPA vs MPA

오늘날 웹 애플리케이션을 개발한다고 하면 대부분 React, Angular, Vue와 같은 JS 기반 프레임워크를 사용해 SPA를 개발한다.

 

SPA

SPA란, Single Page Application의 약자로, 하나의 페이지로 구성된 애플리케이션이다.

SPA로 개발된 웹 사이트에서는 카테고리에 있는 메뉴를 선택하면 보통 헤더는 고정되어 있는 상태로 메인 화면만 바뀐다.

MPA

MPA란, Multi Page Application의 약자로, 여러 개의 페이지로 구성된 애플리케이션이다.

서버로부터 새로운 HTML을 받아와서 페이지 전체를 렌더링하는 전통적인 웹 페이지 구성 방식이다.

 

 

CSR vs SSR

SPA vs MPA

일반적으로는 SPA에서는 CSR로 렌더링하고, MPA에서는 SSR로 렌더링한다.

 

SPA는 웹 애플리케이션에 필요한 정적 리소스를 한 번에 모두 다운로드하고, 이후 새로운 페이지 요청이 왔을 때 필요한 데이터만 전달받아서  클라이언트에서 필요한 페이지를 갱신하기 때문에 CSR로 렌더링한다.

 

반면 MPA는 새로운 요청이 있을 때마다 서버에서 이미 렌더링된 정적 리소스를 받아오기 때문에 SSR로 렌더링한다.

 

다만, 이러한 특징 때문에 SPA == CSR, MPA == SSR 이라는 오해가 생긴다.

 

하지만 이 두 개념은 페이지의 개수와 렌더링을 어디서 하는지 등에 따라 다른 개념이기 때문에 혼동하지 않도록 하자.

 

CSR과 SSR의 차이점

CSR은 Client Side Rendering의 약자로, 클라이언트 측에서 렌더링 하는 방식이다.

 

SSR은 Server Side Rendering의 약자로, 서버측에서 렌더링 하는 방식이다.

 

말 그대로 어느 Side에서 렌더링을 준비하느냐에 따라 나뉘는 개념이다.

 

SSR과 SSG의 차이점

CSR과 SSR을 공부할 때 자주 언급되는 SSG라는 것도 있다.

 

SSG는 Static Site Generation의 약자로, Static Rendering이라고도 불리는 방식이다.

 

서버에 HTML을 보내준다는 차원에서는 SSR과 유사하나, '언제' 만들어주는지에 따라 다른 개념이다.

 

 

SSR은 요청 시 서버에서 즉시 HTML을 만들어 응답한다.

 

그래서 데이터가 달라지거나 자주 바뀌어서 미리 만들어두기 어려운 페이지에 적합하다.

 

SSG는 페이지들을 서버에 모두 만들어 둔 후에 요청 시 해당 페이지를 응답한다.

 

그래서 바뀔 일이 거의 없어 캐싱해 두면 좋을 페이지에 사용하기 적합하다.

 

CSR

CSR의 동작 과정

그림 2-1. CSR의 동작 과정

 

CSR의 동작 과정은 다음과 같다.

1. 유저가 웹 사이트에 방문하면 브라우저가 서버에 콘텐츠를 요청한다.
2. 이에 서버는 빈 뼈대만 있는 HTML을 응답으로 보내준다.
3. 브라우저가 연결된 JavaScript 링크를 통해 서버로부터 다시 JavaScript 파일을 다운로드한다.
4. JavaScript를 통해 동적으로 페이지를 만들어 브라우저에 띄워준다.

 

CSR의 장단점

4번을 보면 CSR은 브라우저가 JavaScript 파일을 다운로드하고, 동적으로 DOM을 생성하는 시간을 기다려야 한다.

 

따라서 초기 로딩 속도가 느리다는 단점이 있다.

 

하지만 초기 로딩 이후에 페이지 일부를 변경할 때, 서버에 해당 데이터만 요청하면 되기 때문에 이후 구동 속도는 빠르다.

 

더불어, 서버는 빈 뼈대만 있는 HTML을 넘겨주는 역할만 수행하기 때문에 서버 측의 부하가 적다.

 

뿐만 아니라, 클라이언트 측에서 연산, 라우팅 등을 모두 직접 처리하기 때문에 반응속도가 빠르고 UX도 우수하다는 장점이 있다.

 

 

브라우저들이 가지는 웹 크롤러는 HTML을 읽어 검색 가능한 색인을 만들어 낸다.

 

웹 크롤러 봇 입장에서는 HTML이 텅텅 빈 것처럼 보여서 색인할만한 콘텐츠가 존재하지 않는다고 판단한다.

 

따라서 SEO(검색엔진 최적화)에 불리하다는 단점이 있다.

 

열심히 서비스를 만들었는데 검색 사이트에 노출이 잘 되지 않는 일이 있을 수도 있다는 것이다.

 

물론 구글의 크롤러 봇은 자바스크립트를 실행할 줄 알기에 CSR 웹 크롤링도 가능하다.

 

하지만 아직 완벽한 단계가 아니기에 구글 측에서도 여전히 SSR을 고려하라는 말을 덧붙이고 있다고 한다.

	CSR
장점	1. 초기 로딩 이후의 구동 속도가 빠르다. 2. 서버 측의 부하가 적다. 3. 반응속도가 빠르다.
단점	1. 초기 로딩 속도가 느리다. 2. HTML이 빈 것처럼 보여져서 SEO에 불리하다.

 

SSR

SSR의 동작 과정

그림 2-2. SSR의 동작 과정

 

SSR의 동작 과정은 다음과 같다.

1. 유저가 웹 사이트에 방문하면 브라우저 서버에 콘텐츠를 요청한다.
2. 서버는 페이지에 필요한 데이터를 즉시 얻어와 모두 삽입하고, 
   CSS까지 모두 적용해 렌더링 준비를 마친 HTML과 JavaScript 코드를 브라우저에 응답으로 전달한다.
3. 브라우저에서는 JavaScript 코드를 다운로드하고 HTML에 JavaScript 로직을 연결한다.

 

SSR의 장단점

2번을 보면 SSR은 모든 데이터가 이미 HTML에 담긴 채로 브라우저에 전달된다.

 

따라서 CSR과는 다르게 크롤러 봇이 HTML을 무리 없이 읽을 수 있기 때문에 SEO에 유리하다.

 

더불어 JavaScript 코드를 다운로드하고 실행하기 전에 사용자가 이미 HTML이 렌더링 된 화면을 볼 수 있다.

 

이렇듯 JavaScript 다운로드를 기다려야 했던 CSR보다 초기 구동 속도가 빠르다.

 

하지만 해당 시점에서는 사용자가 버튼을 클릭하거나 이동하려고 할 때 아무 반응이 없을 수 있다.

 

interaction이 가능한 페이지처럼 보이지만 실제로는 내용과 스타일이 입혀진 껍데기에 불과하다.

 

클라이언트 측 JavaScript가 실행되고 이벤트 핸들러가 첨부된 JavaScript 로직이 모두 연결될 때까지 사용자의 입력에 응답할 수 없기 때문이다.

 

이렇듯 SSR에는 TTV(Time to View)와 TTI(Time to Interact) 간의 시간 간격이 존재한다는 단점이 있다.

 

반면에 CSR은 JavaScript가 동적으로 DOM을 생성한다.

 

그래서 HTML은 JavaScript 로직이 모두 완전히 연결된 상태라 사용자가 보는 시점과 이용할 수 있는 시점이 동일하다.

	SSR
장점	1. 초기 구동 속도가 빠르다. 2. SEO에 유리하다.
단점	1. 화면 깜빡임이 있다. 2. TTV와 TTI 사이 간극이 있다. 3. 서버 부하가 있다.

 

 

CSR ? SSR ? 선택은?

CSR

유저와 상호작용이 많은 사이트에 적합하다.

 

검색 엔진에 노출될 필요가 없는 사이트에 적합하다.

 

SSR

홍보나 상위노출이 필요한 사이트에 적합하다.

 

누구에게나 같은 내용을 보여주지만 업데이트가 빈번해 페이지의 데이터가 자주 바뀌는 사이트에 적합하다.

 

SSG

홍보나 상위노출이 필요한 사이트에 적합하다.

 

누구에게나 같은 내용을 보여주지만 데이터의 업데이트가 거의 없는 사이트에 적합하다.

 

Universal Rendering (초기 렌더링으로는 CSR + 이후 SSR)

사용자에 따라 페이지 내용이 달라지는 사이트에 적합하다.

 

빠른 interaction과 화면 깜빡임이 없어야 하며 SEO를 포기할 수 없어 상위 노출이 필요한 사이트에 적합하다.

 

 

결론

가능하다면 CSR, SSR의 단점을 보완하고 장점을 살린 Universal Rendering을 사용하면 좋을 듯하다.

 

 

참고 사이트

https://dev-ellachoi.tistory.com/28

이제는 알아야겠다! CSR과 SSR의 차이점과 장단점 (SPA, MPA, SSG, Universal Rendering 까지)