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

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


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

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


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

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


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


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

왜 SSR을 사용하나요?

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

  • 더보기

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

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

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

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

그리고 관련내용을 또 찾다보니 

굉장히 이해하기 쉽게 깔끔하게 정리해주신 블로거(jaroinside) 님이 있었음. 링크

그래서 많은 생각을 하게됨.


결과적으로는 아수 단순하게 정리.


SEO 에 반영되어 유입률을 늘리려면 서버사이드 렌더링.

굳이 그러한 목적이 없다면 클라이언트 사이드 렌더링 처럼 목적과 용도에 맞게 사용해야겠다는 들었다.




+ Recent posts