랜더링 방식의 종류 SSR vs CSR, SSG

SSR과 CSR의 차이는 컨텐츠를 어디에서 만드냐가 핵심이다.

컨텐츠를 클라이언트에서 만들면 CSR, 브라우저에서 랜더링

컨텐츠를 서버에서 만들면 SSR, HTML을 서버를 통해 랜더링.

 

클라이언트 사이드 랜더링(CSR)

기본 브라우저 렌더링과정(HTML을 파싱하면서 DOM이 나옴)과 다르게

CSR은 JS에서 직접 DOM을만든다.

참고로 리액트에서는 DOM을 직접조작하지않고 컴포넌트에서 jsx문법을 사용해 JS element를 만듬)

장점 : HTML의 용량이 적어진다 -> 최초 접근시 다운속도가빠름 -> 로딩 접근이 빠르다.

단점 : JS의 번들 용량이 커진다, 브라우저 컴퓨팅파워를 많이쓴다 -> 렌더링 퍼포먼스 저하

* CSR 하는 방법: HistoryAPI를 통해 Route(라우팅)처리를 함, DOM을 통해 랜더링

ex)리액트,앵귤러,뷰 - 브라우저에서 컴포넌트를 만들어 그 컴포넌트를 랜더링시키는 것을 목표로함 

 

왜 CSR이 나왔을까?

전통웹 - 이동시 로딩하는 와중에 흰색화면이 노출, 데이터를 갱신할때마다 새로고침, UX가 안좋음

실시간성이 높은 사이트에 유리 - 페이스북, 인스타그램, 트위터, gmail 등

 

서버사이드 렌더링(SSR)

DB에서 API를 받아와서

API에서 DATA를 받아와서

DATA를 통해 다시 HTML을 만든다.

 

장점 : 서버가 클라이언트보다 훨씬 빠르다. 크롬브라우저와 다르게 HTML을 그려서 내려주기때문에

컴퓨팅파워가 빠름(성능 갑)

검색엔진은 언제나 빠르게 뜨는 사이트를 우선적으로 노출시키기때문에 검색엔진최적화(SEO)

단점: 클라이언트가 서버에 데이터를 요청할때 HTML을 생성하므로 로딩속도가 느리고 UX가 느려질수있음

* SSR하는 방법 : NEXT JS, NODE js에서 템플릿엔진활용, 리액트도 있긴함

요새는 기존화면을 유지시켜놨다가 1초안에 새로고침이이루어지고 순차적으로 렌더링해서 보완됨

 

SSG 정적사이트생성

쓱닷컴 아님 주의ㅋㅋ

SSR과 CSR은 유저가 리퀘스트를 날리는 타이밍에 연관
뉴스기사나 상품페이지는 자주업데이트되지않는데 100만명의 유저가 리퀘스트를 날릴때마다 응답해주는것은 매우 비효율적
SSG는 사이트를 빌드하는 시점에 미리 HTML을 생성한다. 미리 정적사이트를 만들어서(빌드) 유저에게 보여주고 하루 혹은 일주일마다 다시 정적사이트를 빌드하면됨
API서버 부하가 확준다.

동작방법
빌드된 결과물이 HTML, CSS, JS -> CDN에 올리고 그 경로를 유저에게 보여줌(STATIC)
대용량 트래픽에 최적화되어있음. 유저가 엄청 방문해 트레픽이 아무리 튀더라도 어지간하면 안죽는다고 함

 

어떨때 SSR을 하고 CSR, SSG를 하지?? 각각의 특징을 알고 섞어서 쓰자.

화면의 프레임은 SSR 내부 콘텐츠는 CSR로 해도되고

일부 콘텐츠중에 실시간성을 보장해주지않아도될때는 SSR 그외는 CSR

실시간성이 요구될때 CSR

콘텐츠가 많을때 SSR

NEXTJS는 SSG(상세페이지), SSR(목록페이지)을 둘다 지원한다! SSG는 게츠비에서 좀더 최적화된 모델을 사용할 수 있다.

 

1.장바구니를 만든다면 어떻게 아키텍처를 구성할까?
실시간보장성이 중요하다(그사이에 품절 혹은 금액이 바뀔수있음) -> CSR
2. 상품상세 -> 데이터가 자주바뀌지않음 SSR, SSG 다만 금액, 옵션, 품절내용은 CSR이면 좋다.
3. 블로그글, 기사는 실시간성이 안중요할수도 -> SSG