참고 및 출처
유투브 우아한테크 채널, 2021.10.13
[10분 테코톡] 🎨 신세한탄의 CSR&SSR
https://www.youtube.com/watch?v=YuqB8D6eCKE
SPA와 MPA
CSR과 SSR 개념을 다루기에 앞서
웹 FrontEnd 개발을 한다고 하면 대부분 Javascript 기반 Library, Framework를 이용하여
SPA 형태로 개발하게 된다. (React.js, Angular.js, Vue.js 등)
SPA (Single Page Application)와 MPA (Multi Page Application)
SPA : 웹페이지에서 헤더는 고정되어 있고 메인 화면 또는 클릭한 부분만 바뀌는 하나의 페이지 기반의 어플리케이션
MPA : 탭을 이동할 때마다 서버로부터 새로운 HTML을 받아와서 새로운 페이지를 렌더링. 기존의 전통적인 방식.
CSR과 SSR (부제 : SPA/MPA와의 관계)
일반적으로 SPA -> CSR 로 렌더링, MPA -> SSR 로 렌더링하게 된다.
SPA의 경우 웹 어플리케이션에 필요한 정적 리소스를 초반 한번에 모두 다운로드하고, 그 후 필요한 데이터가 있을 때 데이터만 전달받아서 페이지를 갱신하기 때문에 CSR 방식을 채용한다.
MPA의 경우 새로운 요청이 있을 때마다 서버에서 이미 렌더링된 정적 리소스를 받아오기 때문에 SSR 방식을 사용한다.
이러한 특징 때문에 SPA === CSR, MPA === SSR 이라는 오해가 생기기도 하는데 이는 잘못된 접근이다.
CSR, SSR의 개념 (+SSG)
CSR : Client Side Rendering, 서버에서는 빈 페이지만 전달하고 클라이언트에서 js로 렌더링
SSR : Server Side Rendering, 서버에서 요청받을 때 전체 페이지를 만들어서 전달
말 그대로 어느 쪽에서 렌더링을 준비하느냐에 따라 나뉘는 개념이다
추가적으로 SSG 도 언급되고는 하는데,
SSG : Static Site Generation (Static Rendering)
SSG의 경우 정적 웹페이지를 다 미리 다 만들어놓는 것을 말하고
SSR과의 차이는 서버에서 요청 시에 만드느냐(SSR), 미리 다 만들어놓느냐(SSG)이다.
SSR은 데이터가 달라져서 미리 만들어두기 어려운 페이지에 적합,
SSG는 미리 다 만들어두니까 바뀔 일이 거의 없는, 캐싱해두면 좋은 페이지에 적합.
CSR과 SSR의 동작 과정과 특징
CSR의 동작 과정 및 특징
CSR의 동작 과정을 순서대로 나열해보면 아래와 같다.
1) User의 웹사이트 방문
2) Client -> Server 컨텐츠 요청
3) Server -> Client 빈 뼈대 HTML, 연결된 JS 링크 전달
4) Client 측에서 JS 다운로드 및 동적 DOM 생성
여기서 CSR의 특징을 살펴보면,
1) JS 다운로드 및 동적 DOM 생성
(장, 단점) 초기 로딩 속도가 느릴 수밖에 없음. 하지만 이후 구동 속도 빠름.
2) 빈 뼈대 HTML, 연결된 JS 링크 전달
(장점) 서버 부하가 적고, Client 측에서 연산, 라우팅을 모두 처리하기 때문에 반응속도가 빨라 UX적으로 우수한 측면이 있음.
(단점) 브라우저들이 가진 웹 크롤러 봇은 HTML을 읽어서 검색 가능한 색인을 만들어내는데, 웹 크롤러 봇 입장에서 봤을 때 HTML이 텅텅 비어있으므로 SEO에 불리하다는 치명적인 단점이 있다.
Google의 크롤러 봇은 이러한 CSR 방식의 어플리케이션도 검색 색인을 만들어낸다는데, 아직 완벽하지는 않다고 함.
SSR의 동작 과정 및 특징
SSR의 동작 과정을 순서대로 나열해보면 아래와 같다.
1) User의 웹사이트 방문
2) Client -> Server 컨텐츠 요청
3) Server -> Client 렌더링 준비를 마친 HTML, JS Code 전달
4) Client 측에서 HTML 렌더, 이후 JS code 다운로드하여 HTML에 JS 로직 연결
여기서 SSR의 특징을 살펴보면,
1) 렌더링 준비를 마친 HTML, JS Code 전달
(장점) 모든 데이터가 이미 HTML에 담겨진 상태이므로 SEO에 유리하다.
2) 초기 HTML 렌더, 이후 JS code 다운로드하여 HTML에 JS 로직 연결
(장점) 사용자가 페이지에 접근했을 때 빠르게 페이지를 볼 수 있다. (초기에 HTML 바로 렌더)
(단점) JS 로직이 연결되기 이전에는 페이지는 렌더링 되었지만 그저 내용과 스타일만 존재할 뿐 유저 인터랙션이 가능한 상태는 아니므로 유저가 불편함을 느낄 수 있다. (Time To View !== Time To Interact)
CSR과 SSR의 장단점 정리
현재 대부분의 웹 어플리케이션이 사용하고 있는 방식인 CSR의 단점을 보완할 수 있는 방법은 없을까?
CSR의 단점 보완 방법
1) 초기 로딩속도 보완
Code splitting, tree-shaking, chunk 분리를 통해
JS bundle 크기를 줄여서 초기 DOM 생성 속도를 줄이면 초기 로딩속도를 개선할 수 있다.
2) SEO 개선
웹 라이브러리나 web-pack plug-in 등을 통하여 각 페이지에 대한 html 파일을 미리 생성해둔 뒤, 서버에 요청하는 주체가 만약 크롤러 봇이라면 pre-rendering된 페이지를 응답하는 방식으로 SEO를 개선할 수 있다.
3) SSR, SSG 도입
CSR + SSR/SSG
framework 없이 SSR/SSG를 도입하기는 일반적인 프론트엔드 개발자에겐 상당히 어렵다.
보통 framework를 이용하여 도입하는데, 사용하는 javascript library/framework 마다 다르다.
1) React.js
Next.js : 페이지별로 SSR, SSG 선택 가능
Gatsby : SSG에 최적화. 다양한 플러그인 제공. 페이지가 적은, 작은 서비스라면 좋은 수단이 될 수 있음.
2) Vue.js
NUXT
3) Angular.js
Angular universal : 원래는 framework였으나 Angular에 포함되었다고 함.
이렇게 framework를 통해 SSR/SSG를 도입하더라도 프레임워크를 이용하므로 제어할 수 없는 블랙박스 영역이 존재하고, CSR에 비해 코드 복잡도가 올라간다.
A. 어떤 방식을 사용하는게 가장 좋을까?
Q. 서비스의 성격에 따라 다릅니다.
만약 사용자와의 상호작용이 많고, 대부분의 페이지가 고객 개인 정보로 이루어진 페이지라면
검색 엔진에 노출될 필요가 없고 오히려 보호해야된다면 CSR 이 적합하다.
만약 회사 홈페이지이기 때문에 검색 엔진에 노출되어야하고, 누구에게나 항상 같은 내용을 보여준다면
SSR, SSG가 적합. (업데이트 빈도에 따라 SSR, SSG)
사용자에 따라 페이지 내용이 달라지고, 빠른 인터렉션이 중요하며 검색 엔진에도 상위에 노출되어야 한다면
CSR + SSR이 적합.
항상 서비스의 성격을 고민해보고 적절한 방법을 찾아나가자!😆
