Server Side Rendering, Client Side Rendering, Static Site Generation 의 장단점을 설명해주실 수 있을까요?
먼저 CSR(Client Side Rendering)과 SSR(Server Side Rendering)은
클라이언트 사이드에서 HTML문서 렌더링을 할 것이냐(CSR)
아니면 서버 사이드에서 HTML문서를 렌더링 할 것이냐(SSR)로 구분할 수 있다.
🔅 CSR 방식
CSR 방식은 다음과 같은 장점이 있다.
초기 로딩 속도를 제외하면 나머지 부분은 매우 빠른 사용자 인터랙션 속도를 보여준다.
이미 다운받은 번들링 된 js 파일에 렌더링에 필요한 모든 로직이 들어있기 때문이다.
따라서 새로고침이나 화면 깜빡임 등이(의도한 상황이 아닌 이상) 발생하지 않는다.
이는 UX에 엄청난 이점을 가져다 준다.
그리고 서버가 클라이언트 뷰(View)단에서 처리할 일을 더이상 신경쓰지 않아도 된다.
하지만 SPA 개념과 함께 등장한 CSR 방식의 작동원리를 보면 단점이 크게 보이는데,
하나의 페이지에서 여러 페이지를 보여준다는 것은 결국엔
자바스크립트를 이용해서 페이지의 일부분이나 전체를 갈아치우는 것으로 생각해볼 수 있다.
리액트 라이브러리를 이용해 링크 이동과 같은 기능을 내부적으로 구현 시
Router를 설치하여 사용하지만 결국 이러한 파일(jsx 및 js)들은
Webpack과 같은 번들링 도구를 거쳐 하나의 (또는 여러개의 chunk파일로)
거대한 js파일로 번들링되게 될 것이다.
SPA에서는 이처럼 번들링 된 js를 전달받아 SPA을 구축하게 되는 것이다.
즉 이 말은 CSR 방식에서는 이 번들링이 완료된 js 파일을 모두 로드하기 전에는
첫 페이지를 로드할 수가 없다.
엄연히 말해서 첫 페이지는 이미 로드가 되었지만, 로드된 페이지는 빈 HTML 파일이다.
사실 상 유저는 로딩이 완료되기까지 그저 빈 화면을 보고 있을 수 밖에 없다.
또한 첫 페이지가 빈 화면이라는 말은 검색 엔진이 해당 문서를 바라볼 때
기입된 내용이 없기 때문에 SEO 최적화에도 많은 어려움이 따른다.
(또한 CSR에서는 meta tag 수정 등의 어려움 등도 존재하기에 더욱 어렵다)
물론 Code Splitting 등의 기법으로 로딩 시간을 줄일 수 있는 기법들이 있다!
🔆 SSR 방식
SSR 방식의 장점을 보자면,
우선 첫 페이지 로딩 시간이 CSR 방식과 비교해 매우 짧다.
(하지만 JS 파일 등을 다운받아 적용하기까지는 시간이 좀 더 소요되어
사용자의 인터랙션에 정상적인 반응을 보일때까지 기다리는 시간이 어느정도 발생할 수 있다)
그리고 이미 렌더링 된 HTML 문서가 전달되므로
SEO(Search Engine Optimazation)이 CSR 방식에 비해 적용하기 더 우수하다.
또한 사용자 정보를 서버측 세션으로 관리하기 용이하므로 CSR 방식에 비해 보안이 우수하다.
반면 단점으로는 각 페이지별로 매번 로딩시간 및 새로고침 현상이 발생한다는 점은
UX및 UI에 심각한 영향을 초래할 수 있다.
또한 서버에서 렌더링을 마친다는 것은 서버가 담당하는 일이 더욱 많아지는 것이므로
부하에 걸릴 위험도 존재한다.
CSR 방식의 초기 로딩 속도가 SSR에 비해 느리다고 하지만,
코딩한 파일이 대용량의 데이터가 아니라면 크게 지장이 되는 지연시간이 아닐 수도 있다.
또한 이런 로딩 지연 시간은 SSR을 채택하지 않더라도 개선할 수 있는 기법 등이 다양하다.
반면 개발할 페이지가 검색 엔진에 노출이 되어야 하는 것이 우선일 수 있는데
이 경우에는 SSR 적용이 우선시 되어야 할 것이다.
CSR과 SSR의 단점 극복
그래서 CSR과 SSR의 장단점을 적절히 합쳐
SPA형태에 SSR을 지원하도록 설정하면 좋을 거라 생각되는데,
첫 페이지 로딩은 SSR 방식으로 기존 CSR 방식보다 빠르게 문서를 받아옴과 동시에
해당 문서는 서버측에서 렌더링이 완료되었으므로 SEO 적용 또한 가능할 것이다.
그 이후에 렌더링 될 페이지는 그 사이 번들링 된 js 파일을 받아서 CSR 방식으로 수행한다면
두 가지 렌더링 방식들이 가지고 있던 단점들을 어느정도 극복할 수 있다.
SPA 형태에서 두 가지 렌더링 방식을 적절히 혼합해 사용함으로써
기존 방식들이 가지고 있던 단점을 극복하는 것이다.
💛SSG (Static Site Generation)
그리고, SSG(Static Site Generation)가 무엇인가 하면
정적사이트 생성으로 빌드 시 리액트 앱을 HTML로 미리 렌더링하는 것이다.
이상적으로 리액트 앱은 클라이언트 측에서 렌더링된다.
사용자의 브라우저는 먼저 자바스크립트 번들을 다운로드 한 다음
사용자가 컨텐츠를 보기도 전에 다운로드한 자바스크립트 번들을 실행한다. 꽤 느리다.
HTML로 사전 렌더링을 한다는 것은 리액트 컴포넌트를 HTML 파일로 변환하고
HTML 파일을 클라이언트에 전송하여 많은 처리나 대역폭 사용 없이
사용자에게 빠르게 표시할 수 있음을 의미한다.
그래서 사실 이건 서버사이드렌더링(SSR)이라고 할 수 있다.
SSG의 정적(Static)은 SSR 처럼 전체 프로세스가 각 사용자 요청에 수행되는 것이 아닌
빌드 시간에 수행된다. 그렇기 때문에 SSG가 서버 사이드 렌더링보다 훨씬 더 빠르다.
즉, SSG는 빌드 시 리액트 앱에서 HTML 페이지를 만들기 때문에
모든 요청에 대해 HTML 페이지를 작성할 필요가 없으며 클라이언트 사이드의 브라우저에서도
HTML 페이지를 작성할 필요가 없다.
SSG는 특정 사용 사례를 제공하기 위해 존재하는데,
인기있는 사용 사례로는 마케팅 웹사이트나 블로그, 포트폴리오 웹사이트 등이 있다.
SSG를 사용해야 하는지 여부를 쉽게 알 수 있는 방법은
"사용자 요청 전에 페이지를 미리 렌더링 할 수 있습니까?"라고 질문 하는 것이다.
만약 답이 "예"인 경우 "Static Generation"을 선택할 수 있다.
참고 글
[FE] CSR(Client-Side-Rendering) vs SSR(Server-Side-Rendering) (feat. React를 중점으로)
(번역)도대체 SSG가 뭘까요? Next.js로 설명하는 정적 사이트 생성
