SSR, CSR, SPA, MPA 그 차이에 대하여
1. SPA 란?
: Single Page Application
- 한 개의 싱글 페이지로 구성된 어플리케이션
- 브라우저에 최초에 한번 페이지 전체를 로드하고, 이후부터는 특정 부분만 Ajax 를 통해 데이터를 바인딩하는 방식
여기서 Binding이란 ?
: 비동기 통신 기술을 이용해서 DB에 데이터를 요청하고 이를 받아서 HTML 태그에 결합하는 것
- 대표적인 라이브러리/프레임워크 : React, Vue(라이브러리), Angular(프레임워크)
↔ MPA
: Multi Page Application
- 여러개의 페이지로 구성된 application
- SSR 방식으로 렌더링
- 서버로부터 완전한 페이지를 받아오고 이후에 데이터를 수정, 조회할때 다른 완전한 페이지로 이동함 (URI 가 바뀌기도함)
- 새로운 페이지를 요청할 때마다 페이지 리소스가 다운로드 되고, 그에 맞춰 전체 페이지를 다시 랜더링한다.
▶ 그렇다면 SPA 와 CSR 은 같을까?
NO
SPA, MPA는 페이지를 하나만 쓰는지, 여러개 쓰는지의 차이이고 CSR, SSR은 렌더링을 어디서 하냐의 차이로 비교 대상이 아니다.
SPA에서는 첫 페이지만 받아오고 이후에 데이터의 수정, 조회를 하고 싶기 때문에 CSR이란 방식을 채택한 반면,
MPA는 동적이지 않은 페이지를 상황에 맞게 클라이언트에 뿌려주기 때문에 SSR이란 방식을 채택한 것
- [참고] SPA
- SPA’ 싱글페이지라고 해서, 한 종류의 화면만 있는 것이 아니라 여러 종류의 화면이 있고 이에 따른 주소도 있다. 다른 주소에 따라 다른 뷰를 보여주는 것을 라우팅이라고 한다.
- React 에서는 React Router Dom을 사용하여 라우팅을 하는데, 이 패키지를 이용하면 코드의 분할을 도와줌
- 어떤 경로로 들어오던 똑같은 html 파일과 자바스크립트 파일을 제공한다
- SPA’ 싱글페이지라고 해서, 한 종류의 화면만 있는 것이 아니라 여러 종류의 화면이 있고 이에 따른 주소도 있다. 다른 주소에 따라 다른 뷰를 보여주는 것을 라우팅이라고 한다.
2. SPA 등장배경
1. 1990년대 중반 - 정적 웹사이트
사용자가 브라우저에서 해당 사이트에 접속하면 이미 잘 만들어진 HTML 문서를 받아와서 보여주는 방식.
예를 들어 페이지 내에서 다른 링크를 클릭하면, 다시 서버에서 해당 페이지의 HTML 문서를 받아온 후 페이지 전체가 업데이트 되어야 한다. 사용성이 떨어지고 페이지마다 전체가 업데이트 되어야하는 단점이 있다.
2. 1996년 - iframe 태그
문서 내에서 또 다른 문서를 담을 수 있는 iframe 태그가 도입이 되었고 이후 페이지 내에서 부분적으로 문서를 받아와서 업데이트 할 수가 있게 된다
3. 1998년 ~ - XMLHttpRequest
Fetch API의 원조 XHR Web API가 개발이 되어 이제는 HTML 문서 전체가 아니라 JSON과 같은 포맷으로 서버에서 가볍게 필요한 데이터만 받아올 수 있게 된다.
해당 데이터를 자바스크립트를 이용해서 동적으로 HTML 요소를 생성한 후 페이지에 업데이트 하는 방식.
- [참고] XHR(XMLHttpRequest), Fetch API
- XHR
- AJAX의 가장 핵심적인 구성 요소
- 웹 브라우저가 백그라운드에서 계속해서 서버와 통신할 수 있도록 도와주는 역할
- Fetch API
- XMLHttpRequest을 대체하며 비동기 http 요청을 좀 더 쓰기 편하게 해주는 API
- fetch() 함수는 첫번째 인자로 URL, 두번째 인자로 옵션 객체를 받는다
- Promise 기반으로 async, await의 사용이 가능하며 직관적이고 가독성이 좋다
- XHR
- [참고] JSON vs XML
- 여기서 XML의 특징을 엿볼 수 있는데, 태그의 이름이 HTML에서는 볼 수 없는 사용자 임의 태그로 구성되어있다.반면 JSON의 경우 각 객체마다 Key와 Value로 구성된 세트가 여럿 존재함을 알 수 있다.
- 태그의 이름이 태그 내부의 문자열과 연관성이 있기에 데이터를 구조적이고 체계적으로 나타내는데 좋다.
- XML과 JSON형식의 데이터의 차이는 태그 형식으로 구성되어있느냐 배열 객체처럼 구성되어있느냐의 차이다.
4. 2005년 - AJAX
XHR과 같은 방식이 공식적인 AJAX라는 이름을 가지게 되고 AJAX를 이용해서 Gmail, Google Map 같은 웹 어플리케이션들이 만들어지기 시작한다.
이것이 현재 널리 쓰이고 있는 SPA(Single Page Application)이다. 사용자가 한 페이지 내에 머무르면서 필요한 데이터만 서버에서 받아와 부분적으로 업데이트 된다.
이런 SPA가 트렌드가 되고, 자바스크립트가 표준화과 되어가며 React, Angular, Vue 와 같은 프레임워크, 라이브러리가 생겨 CSR의 시대가 오게된다
- [참고] AJAX (Asynchronous Javascript And XML)
- 자바스크립트를 이용해 서버와 브라우저가 비동기 방식으로 데이터를 교환할 수 있는 통신 기능
- 비동기 방식 : Ajax를 통해서 서버에 요청을 한 후 멈추어 있는 것이 아니라 그 프로그램은 계속 돌아간다는 의미를 내포
- 브라우저가 가지고있는 XMLHttpRequest 객체를 이용해서 전체 페이지를 새로 고치지 않고도 페이지의 일부만을 위한 데이터를 로드하는 기법
- 자바스크립트를 이용해 서버와 브라우저가 비동기 방식으로 데이터를 교환할 수 있는 통신 기능
- [참고] AJAX의 장단점
따라서! SSR과 CSR의 가장 큰 차이는 언제 viewable 하느냐!
3. CSR
1. 정의
: Client Side Rendering ; 모든 랜더링을 브라우저에 맡긴다!
2. 과정
서버로부터 css,js 링크만 있는 빈 HTML파일을 전송받아 클라이언트 사이드에서 렌더링하는 방식
- 브라우저가 서버로 요청을 보냄
- 서버는 요청에 따른 css,js 링크만 있는 빈 HTML 파일을 응답
- 스크립트 태그를 통해 자바스크립트 파일을 한줄한줄 읽으며 바로 실행
- 이때, UI가 미완성이 되어 있으므로 JS에서 UI 요소를 하나하나 동적으로 생성하며 그려줌
- UI를 그려줌과 동시에 이벤트 등록, 화면을 다크모드로 전환 등 동적인 화면 구현을 위한 기능을 붙여줌
<!DOCTYPE html>
<html lang="ko">
<head>
<meta charset="utf-8" />
<title>CSR</title>
</head>
<body>
<div id="root"></div>
<script src="app.js"></script>
</body>
</html>
- body 안에는 root 만 달랑 하나 있고, 스크립트 링크만 작성되어있는 것을 확인할 수 있음→ 추가로 필요한 데이터가 있다면 서버에 요청해 받아온 데이터를 기반으로 동적인 HTML 을 생성하고 사용자에게 최종적으로 어플리케이션이 보여짐
- → html 은 텅텅 비어있고 링크된 자바스크립트(app.js)를 서버로부터 다운받는 형식
3. 장점
- 서버를 호출할 때마다 전체 UI를 다시 로드할 필요가 없음 → 빠른 속도
- 변경된 부분만 요청함으로써 서버 부하를 줄임
- 페이지 안에 컨텐츠를 클릭하여 다음단계로 전환하는 과정에서 깜빡임 없이 부드럽게 이동하는 사용자 친화성 有
- lazy loading 을 지원
- (페이지 로딩시 중요하지 않은 리소스의 로딩을 늦추는 기술; 즉, 사용자가 보지 않는 것들을 당장 로딩하지 않는다. 그러다가 나중에 사용자가 필요로 하는 시점에 로딩하는 것)
4. 단점
- 사용자가 첫 화면을 보기까지 시간이 오래걸릴수있다
- ∵ 어플리케이션을 구동하는 프레임워크, 라이브러리 소스, 어플리케이션 로직들 등등 → 굉장히 사이즈가 커서 다운로드에 시간이 소요될수있음
- [해결법] 리소스를 chunk단위로 묶어 요청할 때만 다운받게하는 방식으로 해결
- code splitting - url 마다 각각의 번들링된 js파일을 만들 수 있기때문에 로드시간을 줄일수있음
- 좋지않은 SEO
- CSR에서는 앞서 언급한대로 html 안에 내용이 존재하지 않고 자바스크립트를 이용해 사용자와 상호작용 후 페이지 내용을 로드함 → 검색엔진이 파악할 수 없음
- [해결법]
- pre-render - 사전에 HTML 파일들을 만든다
- 자세한 내용 by react
- [출처] https://velog.io/@ony/html-기본-SEO
- 검색 엔진이 크롤링하러 사이트에 들어왔을 때, 빈 html 대신 내용을 가져 갈 수 있게
- pre-render - 사전에 HTML 파일들을 만든다
4. SEO(검색엔진최적화)
: Search Engine Optimization ; 검색엔진최적화
우리가 무엇을 검색할때 검색하는 내용이 들어가는 컨텐츠를 노출시켜준다
검색엔진이 웹을 크롤링하며 페이지의 컨텐츠 색인을 생성하는 과정
5. SSR
1. 정의
: Server Side Rendering ; 서버쪽에서 랜더링한다!
준비된 HTML 을 보내준다
2. 과정
서버로부터 어느정도 완성된 HTML 파일을 받은 후 렌더링 하는 방식
- 브라우저가 서버로 요청 보냄
- 서버는 요청에 따른 어느정도 완성된 HTML 파일 응답
서버에서 필요한 데이터를 모두 가져와 완전한 HTML 파일을 만든다
→ 동적으로 제어가 가능한 약간의 자바스크립트 소스코드와 함께 클라이언트에 전송
→ 잘 만들어진 HTML 문서를 받아와 바로 사용자에게 보여줌
3. 장점
- CSR 보다 첫 페이지 로딩이 빨라짐 → 사용자가 기다리는 시간이 적다
- SEO 에서의 두각
- 모든 데이터가 이미 HTML에 담겨진채로 브라우저에 전달되어 검색엔진최적화에 유리
4. 단점
- 블링킹 이슈
- 사용자가 클릭하면 전체적인 웹사이트를 다시 서버에서 받아오는것과 같아 썩 좋지않은 사용자경험을 얻을 수 있음
- 서버 과부하 생길 수 있음
- 사용자가 많을수록 사용자가 요청할때마다 html 만들어야하고, 바뀌지 않아도 될 부분까지도 랜더링됨
- 동적으로 처리하는 자바스크립트를 아직 마저 다운로드하지못해, 사용자가 클릭해도 반응하지 않는 경우가 있음
- TTV , TTI 사이의 공백
6. TTV & TTI
1. TTV (Time to View)
: 사용자가 웹브라우저에서 내용을 볼 수 있는 시점
2. TTI (Time to Interact)
: 사용자가 웹브라우저에서 인터랙션 할 수 있는 시점
3. CSR, SSR에서의 TTV, TTI 비교
- CSR은 웹 사이트가 사용자에게 보여짐과 동시에 사용자와의 상호작용이 가능해짐→ 최종적으로 번들링해서 클라이언트에게 보내주는 JS파일을 어떻게 하면 효율적으로 분할해서 사용자가 첫화면을 볼 때 필수적인 것들만 보낼 수 있을지 고민해봐야함 ⇒ TTV 와 TTI 가 동시에 이뤄짐
- SSR 은 TTV는 미리 이뤄지지만, 사용자가 웹 사이트를 볼 수 있는 시간과 상호작용 할 수 있는 공백 시간이 꽤 있는편이라 TTI 사이의 공백시간이 존재함
→ 사용자가 보고 상호작용 할 수 있는 이 시간의 차이를 줄일 수 있는 방법에 대해 고민하거나
어떻게 하면 매끄러운 UI/UX를 제공할 수 있을지 고민해봐야할 것이다.
7. SSG
; Static Site Generator
- 정적인 정보를 다루는데 적합하므로, 바뀔일이 거의 없는 사이트, 캐싱해두면 좋은 사이트에 유용
- SSG의 정적(Static)은 SSR 처럼 전체 프로세스가 각 사용자 요청에 수행되는 것이 아닌 빌드 시간에 수행 → SSG가 서버 사이드 렌더링보다 훨씬 더 빠름
- Ex) Gatsby, Next.js (원래는 강력한 SSR을 제공하는 라이브러리였지만, 요즘은 SSG도 지원)
- 리액트는 CSR이지만 Gatsby라는 Static Site Generator를 함께 사용하면 리액트로 만든 웹어플리케이션도 정적으로 웹페이지를 미리 생성해서 서버에 배포할 수 있게 → 모두 다 정적X, 동적 요소 추가가능(js이용)
- SSG 의 장점
- SEO: 검색 엔진 최적화는 크롤러가 페이지를 쉽게 인덱싱 할 수 있도록 하기 때문에 SSG를 수행하는 최고의 이점 중 하나
- 속도: 짐작할 수 있듯이 브라우저가 사전에 많은 처리를 하지 않아도 되기 때문에 HTML 페이지를 제공하는 것이 사용자에게 훨씬 더 빠른 속도를 제공,
- 사전 렌더링을 통해 브라우저는 HTML을 쉽게 가져와 바로 렌더링 할 수 있다
8. Universal Rendering
- CSR + SSR/SSG
- Isomorphic App (Universal rendering) (동일한 어플리케이션) : 클라이언트가 서버가 동일한코드가 동작하는 어플리케이션
- 예상과는 다른 결과를 마주할순있지만 초기로딩속도 보완, SEO 개선에 기존 CSR의 장점을 살릴수있음
- node js express, nest js → 프레임워크 없이 구현되도록
- [React] next..js (ssr, ssg 선택가능), gatsby (ssg에 최적화) → 프레임워크 이용
- 리액트 + Next.js
- 첫페이지는 서버에서 렌더링하여 빈 html이 아닌 준비된 html을 보내 검색 최적화 문제를 해결하고, 그 다음 페이지부터는 CSR 방식을 적용하여 필요한 데이터부분만 갱신해 서버의 부하를 줄이게 함
- 사용이유 : pages 폴더 밑에 폴더 및 파일을 구성하면 자동으로 라우팅 처리가 되어 개발에 편리하고, 처음 웹페이지 로드 시 SSR로 SEO를 최적화하며 클라이언트와 상호작용 할 때는 CSR을 사용하여 필요한 데이터만 요청 할 수 있기 때문에 SSR과 CSR의 장점을 다 적용 할 수 있음
- 리액트 + Next.js
🎈 [참고출처]
서버사이드 렌더링 (개발자라면 상식으로 알고 있어야 하는 개념 정리 ⭐️)
SSR과 CSR 이 영상 하나로 끝내기! (SEO 해결 포함)
댓글