SSR(서버사이드렌더링)과 SPA(클라이언트 사이드 렌더링)

단일 파일 컴포넌트 : 코드를 기능 단위로 분리하여 짤 수 있다.  
장점 : 재사용 편리, 캡슐화 가능, 디버깅 쉬움, 테스트 작성 편리, 협업 편리  
컴포넌트 구성 :  /* templete + script + style */

컴포넌트 활용 :  사용하고자 하는 곳에서 쓰나 ..  
.js파일  
 

*클라이언트 사이드 렌더링 (SPA ) 

모바일의 시대에 등장한 클라이언트사이드렌더링 Single Page Application(SPA)

최초 한 번 페이지 전체를 로딩한 후 데이터만 변경하여 사용할 수 있는 애플리케이션을 말함.

 

 

렌더링 방식은 클라이언트사이드렌더링 방식이다. 기본적으로 페이지 로드가 없고 모든 페이지는 단순히 HTML5 형식에 의해 렌더링 될뿐, 언제 새로운 데이터를 불러와야할지 스스로 정해서 구현해야함. 어플리케이션 생명 주기 중에서 단 한 번만 리소스(HTML, CSS, JavaScript) 를 로딩하고, 그 후에는 데이터를 받아올 때만 서버와 통신합니다. 정리하자면 첫 요청시 딱 한 페이지만 불러오고 페이지 이동시 기존 페이지의 내부를 수정해서 보여주는 방식입니다.

 

반면 서버 사이드 렌더링 방식(SSR)은? 전통적인 웹 대부분이 서버사이드렌더링 방식이었다. 즉, 브라우저에 나타나는 형태 그대로를 HTML로 만들어 제공하고, 브라우저는 HTML을 표시하는 방식이었다. 이런 방식을 사용하다가 일부 HTML과 Script만 브라우저로 전달하고, 브라우저에서 Script를 실행시켜 서버에서 데이터를 조회하여 HTML을 생성하는 방식

 

하지만 요즘은 웹에서 제공되는 정보가 너무 많기 때문에 이 방식은 성능 문제에 이슈가 많다. 요청 시 마다 새로고침이 일어나며 페이지를 로딩할 때 마다 서버로부터 리소스를 전달받아 해석하고 화면에 렌더링하기 때문이다.

 

예를 들어 

예를들어 현재 주소에서 동일한 주소를 가리키는(갖고있는) 버튼을 눌렀을때, 설정페이지에서 필요한 데이터를 다시 가져올 수 없다. 이것은 사용자와 인터랙션이 많은 요즘 웹앱에게 충분하지 않는 방법일 수 있다. 렌더링을 서버쪽에서 하는 것은, 그 만큼 렌더링을 위한 서버 자원이 사용되는 것이고, 불필요한 트래픽도 낭비되는 것이다.

 

클라이언트 사이드 렌더링은 사용자의 행동에 따라 필요한 부분만 다시 읽어들이기 때문에 서버 측에서 렌더링하여 전체 페이지를 다시 읽어들이는 것보다 빠른 인터렉션을 기대할 수 있다. 서버는 단지 JSON파일만 보내주고, html을 그리는 역할은 자바스크립트를 통해 클라이언트 측에서 수행한다.

 

SPA는 한 종류의 화면만 존재하는 것이 아니다!
화면에 따라 다른 주소를 가진다. 주소가 있어야 사용자들이 북마크도 가능하고, 서비스에 구글을 통해 유입될 수 있기 때문이다.(SEO). 각 페이지마다 링크가 필요하다.  Vue-CLI로 만든 앱은 검색엔진최적화(SEO)가 어렵다는 점이 있다.

 웹서비스를 하는 회사 입장에서는 검색엔진에 적절하게 노출되는 것이 아주 중요합니다. 

 

주소에 따라 다른 뷰를 렌더링하는 것을 라우팅이라고 한다. React자체에는 이 기능이 내장되어있지않기 때문에 라이브러리 react-router를 사용해서 설정해야한다.

 

 

클라이언트사이드렌더링의 장점 / 단점

1. 장점
   1-1. 트래픽감소
   필요한, 변경된 데이터만 받아서 그림
   1-2. 사용자경험
   새로고침이 발생하지 않아 사용자가 네이티브 앱과 비슷한 경험을 할 수 있다.
2. 단점
   2-1. 검색엔진
   자바스크립트 위주로 돌아가는 프로젝트는 자바스크립트 엔진이 돌아가지 않으면 원하는 정보를 표시해주지 못함. 크롬에서 react로 만든 웹앱의 소스를 확인하면, 내용이 비어있다. 그렇기 때문에 검색엔진 크롤러가 데이터들을 제대로 수집하지 못한다. 하지만 짱짱맨 구글의 검색엔진은 자바스크립트 엔진이 내장되어있다. 하지만 네이버, 다음 등의 검색엔진은 제대로 크롤링하지 못하기때문에 서버사이드렌더링을 따로 구현해야한다.

요약 

 JavaScript 코드가 동작하기 전에도 완성된 형태의 탬플릿(HTML에 데이터가 삽입된 상태)을 서버로 부터 전달받습니다. 이 때문에 JavaScript 를 구동하지 않는 모르는 검색 로봇이 페이지를 크롤링하기에 매우매우 적합

단점으로는 매 페이지 요청마다 페이지 리로딩(새로고침)이 발생하며,  SPA  와는 정반대로 서버의 리스폰스에 의존해서 페이지를 이동해야하기 때문에 퍼포먼스, 사용자 경험(UX) 측면에서  SPA 에 비해 떨어진다고 볼 수 있습니다.

 

참고자료 

https://medium.com/aha-official/%EC%95%84%ED%95%98-%ED%94%84%EB%A1%A0%ED%8A%B8-%EA%B0%9C%EB%B0%9C%EA%B8%B0-1-spa%EC%99%80-ssr%EC%9D%98-%EC%9E%A5%EB%8B%A8%EC%A0%90-%EA%B7%B8%EB%A6%AC%EA%B3%A0-nuxt-js-cafdc3ac2053

아하 프론트 개발기(1) — SPA와 SSR의 장단점 그리고 Nuxt.js

Vue.js 에서 SSR 적용하기

서버 환경이 node.js 일 때, Vue.js 에서 SSR하는 방법으로 세 가지 옵션이 있습니다.

1. Prerendering (webpack 의 prerender-spa-plugin 사용)
2. Vue SSR Guide를 참조해서 직접 구현 (vue-server-renderer사용)
3. Nuxt.js 프레임워크를 사용

첫 번째, Prerendering 은 검색엔진 노출이 필요한 페이지들을 배포시점에서 렌더링해서 정적인 파일(.html)을 생성해 두는 방식입니다. 가장 손쉽게 SSR을 적용하는 방법이지만, 동적인 페이지에는 적용이 불가능하다는 단점이 있습니다.

두 번째, Vue SSR은 vue-server-renderer 를 활용해서 SSR하는 방식입니다. 서버와 클라이언트에서 모두 안정적으로 동작하는 JavaScript 코드 작성(window , document 등 브라우저 전용 전역변수 사용 주의 등) 해야하고 데이터 프리 패칭, css, font, image 등의 assets 를 관리하기 위한 webpack 설정 등을 한 땀 한 땀 해줘야 합니다. 신경써줘야할 것이 굉장히 많고 시행착오도 많이 겪어야 했습니다. 다만 이미 Vue.js 로 동적인 앱을 운영하고 계시다면 고려할 만한 거의 유일한 옵션인 듯 합니다.

세 번째, Nuxt.js 는 Vue.js 기반의 애플리케이션을 새로 작성하신다면, 그리고 SSR이 필요하시다면 무조건 추천드리고 싶습니다. 위에 서술한 많은 작업들을 시행착오를 줄이고, 일관된 스타일로 코드를 작성할 수 있도록 도와줍니다. 새로운 프로젝트를 시작하신다면 꼭꼭!! Nuxt.js 를 고려해보시기 바랍니다!