CSR: 클라이언트 사이드 렌더링
SSR: 서버 사이드 렌더링
CSR = 클라이언트측에서 렌더링 하는 방식
SSR = 서버측에서 렌더링 하는 방식
+)SSG 라는것도 있음: Static Side Generation
SSR이랑 SSG 둘다 서버측에서 HTML을 보내는거라 비슷한데..
SSR은 요청이 들어오면 만들어서 보냄 (미리 만들어두기 어려운 경우)
SSG는 미리 다 만들어둔거 (캐싱해두기 좋은 경우)
CSR의 동작 과정과 특징
동작 과정
1. 유저가 웹사이트 방문한다.
2. 브라우저가 서버에 콘텐츠를 요청한다.
3. 서버는 빈 뼈대 HTML만 보내준다.
4. 브라우저가 연결된 JS링크를 통해 서버를 통해 JS를 다운받는다.
5. JS를 이용해 동적으로 페이지를 만들어서 브라우저에 띄운다.
특징
1. CSR은 브라우저가 JS파일을 다운받고, 동적으로 DOM을 생성하는 시간을 기다려야해서 초기 로딩속도가 느리다.
2. 초기 로딩이후에 페이지 일부를 변경할때는 서버에 해당데이터만 요청하면 되기때문에 이후 구동속도가 빠르다.
3. 서버는 빈 뼈대 HTML만 주면 되기때문에 서버 부하가 적다.
4. 클라이언트 측에서 연산 라우팅을 직접 처리하기때문에 반응속도가 빠르고, UX도 우수함 => 사용자경험↑
5. 웹 크롤러가 HTML을 읽는데.. 웹 크롤러 입장에선 빈 뼈대 HTML만 있어서 SEO(검색엔진 최적화)에 불리하다.
SSR의 동작 과정과 특징
동작과정
1.유저가 웹사이트에 방문한다.
2. 브라우저에서 콘텐츠를 요청한다.
3. 서버에서 즉시 필요한 데이터를 삽입하고 CSS까지 적용해서 렌더링 준비를 마친
HTML과 JS 코드를 브라우저로 전달한다.
4. 브라우저에서 전달받은 페이지를 띄운다.
5. 브라우저가 JS코드를 다운로드하고 HTML에 JS로직을 연결한다
특징
1. 서버에서 렌더링 준비를 마친 HTML을 응답으로 전달함 =>덕분에 SEO에 유리하다.
2. JS코드를 다운받고 실행하기전에 사용자가 화면을 볼수있음 => 초기 구동 속도가 빠름.
but JS연결이 모두 연결될때까진 사용자가 버튼을 클릭하거나 이동하려해도 반응이 안됨 (렉인줄 앎)
이걸 TTV !== TTI 이라고함 Time To View !== Time To Interact
정리
| CSR | SSR | |
| 장점 | 화면 깜빡임 X 초기 로딩이후 구동속도가 빠름 TTV와 TTI 사이 간극 X 서버 부하 분산 |
초기 구동속도가 빠름 SEO에 유리함 |
| 단점 | 초기 로딩속도가 느림 SEO에 불리함 |
화면 깜빡임이 있음 TTV와 TTI 사이 간극이 있음 서버 부하가 있음 |
SPA(싱글 페이지 어플리케이션) -> React, Vue, Anguler
: 페이지 하나에서 다 해결됨 => 원하는 부분만 클라이언트에서 동적으로 갈아끼움, 화면 깜빡임없음
MPA(멀티 페이지 어플리케이션)
: 새로운 탭으로 이동할때마다 서버로부터 새로운 HTML을 받아와서 페이지 전체를 새로 렌더링함
일반적으로 SPA(싱글페이지)는 CSR /// MPA(멀티페이지)는 SSR을 차용함
SPA는 웹 어플리케이션에서 필요한 정적 리소스를 초반 한번에 다운로드하고, 그 이후 새로운 요청이있을떄 페이지 갱신에 필요한 데이터만 전달받아서 클라이언트에서 페이지를 갱신함. => 주로 CSR 사용
MPA는 새로운 요청이 있을때마다 서버에서 이미 렌더링 된 정적 리소스를 받아오기떄문에 => 주로 SSR을 사용함
하지만 페이지가 몇개 렌더링을 어디에서 하냐에 따라서 달라지기도 함
요즘 대부분 SPA를 사용하는데.. CSR의 단점보완 방법은 없을까?
code splitting , tree-shaking , chunk 분리를 통해서 JS 번들 크기를 줄여서
초기 DOM 생성속도를 줄이기때문에 초기 로딩속도를 보완할수있다.
pre-rendering : 웹 라이브러리나 웹팩 플러그인을 통해 각 페이지에 대한 HTML파일을 미리 생성해둔뒤
서버에 요청하는게 크롤러라면 사전에 렌더링된 HTML버전을 보여주는 방식으로 개선가능함.
SSR 또는 SSG, ISR를 도입하는 방법도 있다.
SSG는 수정할수 없는 페이지, 그냥 거의 관상용으로 보기만 하는페이지에서 사용할수있다.
ISR은 SSG를 살짝 보완한 것으로, 약 5분마다 서버에서 새로운데이터를 받아온다. 하지만 여전히 사용자가 실시간 데이터는 사용할수 없다는 단점이 있다.
어떻게 CSR에 SSR과 SSG를 도입할까?
방법 1.
프레임워크 없이 도입하는 방법이다.
expressJS로 별도의 서버를 운영하는 방법, 타입스크립트가 걱정된다면 nest를 사용할수있다.
하지만 프론트엔드 개발자에겐 어려울수있다. (진입장벽)
방법 2.
SPA에서 SSR/SSG를 쉽게 적용할수있도록 도와주는 프레임워크가 있다.
리액트
NEXT : 페이지의 성격별로 SSR, SSG 사용을 정할수있다.
Gastsby: SSG에 최적화된 리액트 기반 정적페이지 생성 프레임워크. SSG에 최적화이긴 하지만 CSR, SSR, 레이지로딩도 지원함. 무엇보다 다양한 플러그인이 장점임 // 페이지가 적고 작은 서비스가 사용하기 좋음
뷰
NUXT : NEXT에 영감을 받아 만들어짐
앵귤러
UNIVERSAL : Angular4부터 코어 모듈에 포함됨. (더이상 프레임워크는 아님)
이런 프레임 워크들은 CSR에 비해 코드 복잡도가 올라간다.
또, 직접 제어할수없는 블랙박스 영역이 존재함
초기 렌더링 방식으로 SSR을 사용하고 이후엔 CSR을 사용하는 방식을
Isomorphic App, Universal Rendering 이라고 함
초기 로딩 속도 보완, SEO 개선, CSR의 장점을 모두 흡수!!
근데 이렇게 해도 모두 다 단점이 있는데 무엇을 써야할까?
서비스 성격마다 다르다.
개인정보가 많고 검색엔진 노출필요 X , 유저랑 상호작용이 많다 => CSR
회사 홈페이지, 누구에게나 같은 내용을, 매주 업데이트 한다 => SSR
근데 업데이트가 거의 없다 => SSG
사용자에 따라 페이지 내용이 달라짐, 빠른 인터랙션, 검색엔진 노출필요 => CSR + SSR (Universal Rendering)
참고자료:
'CS지식' 카테고리의 다른 글
| 브라우저 렌더링을.araboja (0) | 2023.02.01 |
|---|