SSR (Server Side Rendering) & CSR (Client Side Rendering)

흠.. 웹 프로젝트에 대한 방향성에 대한 문제로 일말의 공부와

생각의 정리가 필요하였다.

Node.js 를 보다가 Node / Express 등을 보다가 Nuxt.js 라고 서버사이드 렌더링 프레임워크를

알게 되어서 공부하다 보니 놓칠뻔 했던 중요한 내용이었다.

요새는 바로 사용할 수 있는 실용화, 생산성 위주로 살아가다 보니

전혀 공부할 생각과 시간이 없었는데 이건 중요한 계기였듯.

먼저 Vue.js 에서 보면 다음과 같이 서버사이드 렌더링에 대하여 언급되어 있다.

URL : https://ssr.vuejs.org/ko/

왜 SSR을 사용하나요?

전통적인 SPA(싱글 페이지 애플리케이션)에 비해 SSR의 장점은 주로 아래에 있는 내용과 같습니다.

• 검색 엔진 크롤러는 완전히 렌더링 된 페이지를 직접 볼 수 있으므로 검색 엔진 최적화가 개선됩니다.

  현재 Google과 Bing은 동기식 자바스크립트 애플리케이션의 인덱싱을 할 수 있습니다. 여기서 동기식이 핵심 단어입니다. 앱이 로딩 스피너로 시작한 다음 Ajax를 이용해 컨텐츠를 가져오는 경우 크롤러가 완료될 때까지 기다리지 않습니다. 즉, SEO가 중요한 페이지에서 비동기적으로 콘텐츠를 가져오는 경우 SSR이 필요합니다.

• 컨텐츠 도달 시간 단축, 특히 느린 인터넷 또는 느린 장치의 경우에 서버 렌더링 마크업은 모든 자바 스크립트가 다운로드되어 실행될 때까지 기다릴 필요가 없으므로 사용자는 완전히 렌더링 된 페이지를 더 빨리 볼 수 있습니다. 일반적으로 사용자 경험이 향상되고 전환율과 직접적인 관련성이있는 애플리케이션의 경우 중요해질 수 있습니다.

하지만 SSR을 사용할 때 고려해야할 몇가지 단점이 있습니다.

• 개발 제약 사항이 있습니다. 브라우저의 특정 코드는 특정한 라이프사이클에서만 사용할 수 있습니다. 일부 외부 라이브러리는 서버에서 렌더링 된 애플리케이션에서 실행할 수 있도록 추가적인 처리가 필요할 수 있습니다.
• 설치 및 배포 요구사항을 보다 복잡하게 만들 수 있습니다. 정적 파일 서버에 배포할 수 있는 완전히 정적인 SPA와 달리 서버 사이드 렌더링 애플리케이션에서는 Node.js 서버를 실행할 수 있는 환경이 필요합니다.
• 더 많은 서버측 부하가 생깁니다. Node.js의 전체 애플리케이션 렌더링은 정적 파일을 제공하는 것 보다 CPU를 많이 사용하므로 트래픽이 많을 것으로 예상되면 서버 부하에 대비하고 캐싱 전략을 잘 짜야합니다.

앱에 SSR을 사용하기 전에 먼저 실제 필요한지 고민해야합니다. 보통 앱의 컨텐츠가 얼마나 빨리 도달해야 하는지에 달려 있습니다. 예를 들어, 초기 로드 시 추가적인 수백 밀리 초가 그다지 중요하지 않은 내부 대시 보드를 구축하는 경우 SSR은 불필요합니다. 그러나 시간에 따른 컨텐츠가 절대적으로 중요한 경우 SSR을 사용하면 최상의 초기 로드 성능을 얻을 수 있습니다.