CSR
간단하게 비유하면 "비조리형 배달음식"으로 볼 수 있다.
식당에서 재료만 손질해서 전달 주면 고객이(client) 알아서 음식을 완성해서 식사하는게 최종 형태를 브라우저에서 완성하는 CSR과 비슷하다고 할 수 있다.
조금 더 사전적으로 정의하여보면, "웹 페이지의 렌더링이 클라이언트 측에서 이루어지는 것"을 의미한다.
브라우저가 최초로 서버에 Request를 보내면, html, css, js파일을 차례로 다운로드 한다.
React를 사용하여 페이지를 구현하였을 경우, html만 받아졌을 때는 페이지가 비어져있다가 javascript가 모두 다운로드 완료되어야 그제서야 화면에 컨텐츠가 그려진다.
우리가 React를 CRA를 사용해서 생성할 경우 렌더링이 CSR방식으로 일어나게 된다.
특징
- 처음 request를 보낼 때만 서버와 통신이 이루어지기에 서버 호출을 최소화 할 수 있다.
- 새로운 페이지로 이동하더라도 html자체가 바뀌는 게 아니라 Javascript 차원에서 새로운 화면을 그려낸다
- SPA를 구현할 때 많이 사용한다(CRA)
- 마지막에 javascript가 다운로드되면서 화면이 나타나기에 TTI와 TTV가 동시에 일어난다
단점
- SEO에 불리하다
첫 페이지가 비어있기에 검색 엔진이 페이지 내용을 크롤링 하지 못한다. 구글은 조금 개선되었다고는 하지만 아직까지는 SSR 대비 전반적으로 불리한 편이다. - UX도 SSR에 비하면 불리하다
TTV와 TTI가 동시에 나타난다는 것은 view가 완성되기까지도 시간이 걸린다는 것이기에 사용자 경험 입장에서 약간 불리한 면이 있다.
SSR
CSR과 반대로 "완조리형 배달음식"을 떠올리면 된다.
식당에서 음식을 완성해서 배달하면 고객은 먹기만 하면 되는거다.
일일이 조리를 다 해야하기에 주방이(서버가) 바쁘다는 특징이 있다.
이것도 사전적으로 정의해보면, "첫 페이지 렌더링을 클라이언트가 아닌 서버에서 진행하는 것"이라고 볼 수 있다.
서버에서 먼저 HTML,CSS를 렌더링 해서 정적인 화면을 먼저 client측에 전달해주고 나중에 동적인 요소가 필요한 경우에 client로 JS를 가져와서 활용하는 형태이다.
특징
- SEO에 유리하다
서버에서 사용자에게 보여줄 페이지를 모두 구성하여 사용자에게 보여주는 방식이기 때문에 CSR의 단점인 "첫 페이지 깡통" 상태를 극복할 수 있다. - UX가 좋다
구성하는 속도는 느리지만, 전체적으로 사용자에게 보여주는 콘텐츠 구성이 완료되는 시점이 빠르다 - HTML, CSS가 1차례 들어오고, 그 다음에 JS가 처리되기에 TTV와 TTI간 시차가 있다.
단점
- 서버의 부하가 커진다
아무래도 서버에서 다 처리하는 형태이기 때문에 request가 많이 들어올 경우 부담스러워진다 - 용량이 너무 큰 경우 첫 페이지 로딩이 너~무 오래 걸릴 수 있다.
SPA for SSR
SEO 최적화를 이루어내면서 동시에 SPA를 활용하여 쾌적한 사용환경을 만들 수 없을지 여러 사람들이 고민하였고, 그 결과로 SPA for SSR이 등장하게 되었다.
그 방법인 즉슨 1. 첫 렌더는 SSR방식으로 진행하고, 2. 두번째 렌더부터는 CSR로 진행하는 것이다.
방법론들
React hydrate
SSR로 렌더링 된 화면(기존 마크업)에 이벤트 리스너를 연결시킨다.
기존에 CSR로 작업할떄는 render콜백을 사용하였지만, SSR로 작업 시 HTML과 React를 연결하려면 hydrate를 사용해야한다.
// csr
ReactDOM.render(element, container[, callback])
// ssr
ReactDOM.hydrate(element, container[, callback])Next.js
Next.js는 React의 SSR을 쉽게 구현할 수 있도록 해주는 프레임워크이다.
사용 방법이 간단하기에 FE 개발자가 Next.js를 활용하여 SSR 구축을 용이하게 만들어, FE-BE간 업무를 보다 깔끔하게 분리되도록 한다.
더 알아보기
