web/Vue

SPA 와 SSR vs CSR

뽀리님 2024. 2. 13. 11:00

프론트엔드쪽을 공부하다가 헷갈리는 개념을 정리해 보았다.

 

✔️ SPA(Single Page Application)

SPA 란 말 그대로 한개의 페이지를 가진 어플리케이션이다.
왜 SPA 로 개발하느냐고 묻는다면,

 

  • 사용자 친화적
  • 초기 렌더링 후 데이터만 받아오기 때문에, 상대적으로 서버 요청이 적음
  • Virtual Dom(가상 돔)
  • 프론트 엔드와 백엔드 분리로 개발업무 분업화 및 협업이 용이
  • 개발이 상대적으로 효율적
  • 페이지 전환 시에 서버로부터 새로운 페이지를 받아오지 않고, 클라이언트 측에서 필요한 데이터만 동적으로 로드하여 화면을 갱신

정도를 말할 수 있겠다.

기본적으로 SPA 는 클라이언트 사이드 렌더링이지만 그렇다고 SPA == CSR 은 아니다. 이제 아래에서 SPA 에서의 SSR 과 CSR 에 대해 알아보자

 

✔️ SSR(Server Side Rendering)

과거 그리고 현재도 그렇지만, 많은 웹사이트들은 페이지를 이동할 때마다 서버에 새로운 페이지에 대한 요청을 하는 방식을 택하고 있다.

이 방식이 SSR이다.

서버에서 렌더링을 마치고, Data가 결합된 HTML파일을 내려주는 방식이다. 새로운 페이지로 이동할 때마다 서버에 요청하여 페이지를 받아야 하기 때문에, 받아오는 시간동안 깜빡거리는 현상을 마주할 수 있다.

 

✔️ CSR(Client Side Rendering)

CSR 방식은 최초 요청시에 HTML을 비롯해 CSS, Javascript 등 각종 리소스를 받아온다. 이후에는 서버에 데이터만 요청하고, 자바스크립트로 뷰를 컨트롤 한다.
당연히 초기 요청 때 SSR 보다 많은 리소스를 요청하기 때문에, 렌더링은 속도는 SSR이 더 빠르다.
하지만 이후 다른 페이지로의 이동시에는 SSR 보다 빠른 페이지 전환 속도와 더 나은 사용자 경험을 제공한다.

만약 인터넷 속도가 어어엄청 느리다면, 유저는 제대로된 화면을 한참 후에나 만나볼 수 있을 것이다.

일단 처음 받게될 HTML은 빈페이지일 테니까...

 

 

✅ SEO(Search Engine Optimization) 문제

아무래도 리액트나 뷰를 사용하면서, CSR을 할 지 SSR을 할 지 고민하게 되는 이유는 SEO 때문이다.

물론 회사내에서만 사용하는 CMS라면 신경쓸 필요가 없지만 공식 홈페이지와 같이 일반 사용자에게 검색되어야 하는 사이트라면 SEO 때문에 SSR에 대해 생각하게 된다.

사실 구글은 크롤러 안에 자바스크립트 엔진이 들어있어서 크게 문제될게 없지만, 네이버나 다음은 다르다. 왜냐면...그들은 자바스크립트를 해석할 수 있는 엔진이 없어서 빈 페이지로 인식할테니까! (역시 갓구글..!!)

 

렌더링 퍼포먼스 외적인 측면도 다루었다. 흔히 많이들 하는 오해가 CSR은 SEO가 잘 되지 않는다라는 것인데, 많은 크롤러들이 JavaScript를 지원하지 않기 때문에 발생한 오해다.
Google Bot(크롤러)은 JavaScript를 지원하기 때문에 CSR 사이트도 SEO가 잘 된다.
특히, 최신 버전의 Google Bot은 ES2015 이상의 최신 JavaScript도 지원한다. 또한 Full SSR 없이도 메타 태그들을 잘 활용하면 SEO를 잘 지원할 수 있다.
https://hyunseob.github.io/2019/05/26/google-io-2019-day-3/

 

 

이를 해결하기 위해 SSR with Hydration 기법이 나왔는데, 대표적으로 React 진영의 Next.js와 Vue 진영의 Nuxt.js가 위 기법을 구현한 프레임 워크다.

즉, 처음엔 서버사이드 렌더링을 하고, 그 후 다른 페이지들에선 클라이언트 사이드 렌더링을 이용하는 방식이다.

 

 

 

참조 :

https://velog.io/@ru_bryunak/SPA-%EC%82%AC%EC%9A%A9%EC%97%90%EC%84%9C%EC%9D%98-SSR%EA%B3%BC-CSR