CSR vs SSR (SPA와 MPA)

스터디2024.08.07

JavaScript
React

📖 Reference 📎 https://codingapple.com/unit/nextjs-0-ot/ 📎 https://dev-ellachoi.tistory.com/28 📎 https://www.youtube.com/watch?v=YuqB8D6eCKE

🤔 SPA와 MPA란 뭘까?

오늘날 웹 애플리케이션을 개발할때 대부분 React , Angular , Vue 와 같은 JS 기반 프레임워크를 사용해 SPA 를 개발한다.

💡 MPA(Multi Page Application)

페이지 전체를 렌더링하는 전통적인 웹 페이지 구성 방식.
탭을 이동하거나 이벤트가 발생할 때마다 서버로부터 새로운 HTML를 응답받아 다시 그린다.

💡 SPA(Single Page Application)

하나의 페이지로 구성된 웹 애플리케이션.
SPA로 개발된 웹 사이트는 컴포넌트(Component) 기반이다.

→ 예를 들어, 카테고리에 있는 각 메뉴를 선택하면 전체 페이지가 다시 그려지는것이 아닌, 헤더는 고정되어 있는 상태로 특정 화면 혹은 클릭한 부분만 그려진다.

🤔 CSR와 SSR은 뭘까?

💡 CSR(Client Side Rendering)

뜻 그대로 클라이언트 에서 렌더링이 진행되는 방식을 말한다.

위 사진은 CSR 의 동작과정이며, 정리하면 아래와 같다.

유저가 웹사이트에 방문하면 브라우저는 서버로 컨텐츠를 요청(Request)한다.
서버는 브라우저에게 HTML 과 다운로드할 수 있는 JavaScript 링크 를 응답(Response)한다.
브라우저는 서버로부터 받아온 HTML 에 JS를 적용하기위해 응답받은 JavaScript 링크 를 통해 서버로부터 JS 파일을 받아온다.
HTML 에 받아온 JS 파일을 적용시켜 동적 페이지로 만들어 브라우저에 출력한다.

❕CSR의 장단점

CSR 설명 중 4번 항목을 주목하면 좋다. CSR은 브라우저가 JS 파일을 다운로드하고 동적으로 DOM을 생성하는 시간을 기다려야 하기 때문에 초기 로딩 속도가 느리다.

하지만, 초기 로딩 이후에 발생되는 페이지 일부 변경 사항들에 대한 처리는 빠르다는 특징이 있다. 서버에서 변경하고자 하는 데이터만 요청하면 되기 때문이다.

더불어, 서버는 JS를 삽입하지 않는 빈 뼈대와 다름없는 HTML만 응답하는 역할을 수행하기에 서버 측의 부하가 적다. 뿐만 아니라 서버가 아닌, 클라이언트에서 연산과 라우팅 등을 모두 직접 처리하기에 반응속도가 빠르며 UX또한 우수하다.

단, CSR의 경우 SEO(검색 엔진 최적화) 측면에서 불리하다. SEO를 진행하는 웹 크롤러 봇 입장에서는 HTML 이 텅 비어있는 것처럼 보이기에 색인할만한 컨텐츠가 존재하지 않는 것으로 인식한다. 따라서 열심히 서비스를 개발하더라도 검색 사이트에 노출이 잘 되지 않는 경우가 발생할 수 있다.

→ 실제, 아직 완벽한 단계가 아니기에 구글 측에서도 SSR을 고려하라는 말을 덧붙이고 있다…

💡 SSR(Server Side Rendering)

뜻 그대로 서버 에서 렌더링이 진행되는 방식을 말한다.

위 사진은 SSR 의 동작과정이며, 정리하면 아래와 같다.

유저가 웹사이트에 방문하면 브라우저는 서버에게 리소스를 요청(Request)한다.
서버는 브라우저가 요청한 리소스를 모두 얻어와 즉시 삽입하며, CSS까지 적용한 HTML과 JS 코드를 브라우저에게 응답(Response)한다.
브라우저는 CSS까지 적용된 HTML과 서버로부터 받아온 JS 코드를 연결한다.

! SSR의 장단점

SSR 설명 중 2번을 주목하자. SSR 은 서버에서 이미 모든 데이터가 HTML 에 담긴 채로 브라우저로 전달되어 SEO(검색 엔진 최적화) 에 유리하다.

SEO 를 진행하는 웹 크롤러 봇이 서버로부터 넘어온 완성된 HTML을 읽을 수 있기 때문이다. 또한, JS 코드를 다운로드 받고 실행하기 전에 사용자는 이미 HTML 이 렌더링된 화면을 볼 수 있다. 따라서 JS 코드를 다운받고 기다려야하는 CSR 보다 초기 구동 속도가 빠르다.

이때, 상기와 같이 이미 HTML이 렌더링된 화면을 볼 수 있다. 라는 문구를 주목하자. 해당 시점에서는 사용자가 버튼을 클릭하거나 이벤트를 발생시키려 할 때 아무 반응이 없을 수 있다. 사용자와 반응할 수 있는 페이지가 사실은 내용과 스타일만 입혀진 껍데기에 불과하기 때문이다. 실제로는 서버로부터 받아온 JS 가 실행되고 핸들러가 첨부된 JS 로직이 연결될 때까지 페이지는 사용자의 입력에 응답할 수 없다.

CSR과 SSR의 차이는 어떤 Side 에서 렌더링이 진행되는가에 있다.

SSR은 TTV(Time to View, 화면에 보이는 시간) 와 TTI(Time to Interact, 반응되는 시간) 간의 시간 간격이 존재하는 것이 단점이다.

CSR은 JS가 동적으로 DOM 을 생성하기 때문에 HTML 은 JS 로직이 모두 연결된 상태이기에 사용자가 보는 관점(TTV)와 이용할 수 있는 시점(TTI)가 동일하다.

💡 번외 : SSG(Static Site Generation) 정적 사이트 생성이란?

Static Rendering 이라고도 불리는 방식은 사용자에게 보여주기 위한 페이지들을 서버에서 모두 만든 뒤 요청이 있을 때 만들어둔 페이지를 응답하는 방식이다.

→ 즉, 바뀔 일이 거의 없어 캐싱해 두면 좋은 페이지에 사용하면 적합하다.

SSR과 SSG의 차이점은?

→SSR은 특정 요청이 있을 때 즉시 HTML을 만들어 응답한다.

→ 데이터가 수시로 바뀌거나 미리 만들어두기 어려운 페이지에 적합하다.

→ 즉, SSR과 SSG는 서버에서 HTML을 보내준다는 측면에서 유사하다. 하지만, 언제 만들어주는지에 따라 차이가 존재한다.

💡 `CSR` 과 `SSR` 의 장단점 정리

CSR의 장, 단점

장점 -> 화면 깜빡임 없음 -> 초기 로딩 이후 구동 속도가 빠름 -> TTV와 TTI 사이 간극 없음 -> 서버의 부하를 분산할 수 있음
단점 -> 초기 로딩 속도가 느림 -> SEO에 불리

SSR의 장단점

장점 -> 초기 구동 속도가 빠름 -> SEO에 유리
단점 -> 화면 깜빡임이 존재 -> TTV와 TTI 사이 간극 있음 -> 서버에 부하가 올 수 있음

🤔 내가 만드는 서비스에 어떤 렌더링을 적용할까?

🚩 CSR(Client Side Rendering)

→ 사용자와 상호작용이 많은 서비스 💡 대부분이 고객의 개인정보들로 이루어진 페이지들 → 검색엔진에 노출될 필요 X (SEO 무의미)

🚩 SSR(Server Side Rendering)

→ 누구에게나 항상 같은 내용을 보여주는 페이지

→회사 홈페이지 혹은 쇼핑몰 등 홍보 혹은 검색엔진에 노출이 많이 되어야하는 서비스

→ 업데이트가 빈번해 페이지 내용이 자주 바뀌는 페이지 💡 검색엔진에 자주 노출되어야하기에 SEO에 유리

🚩 SSG(Static Site Generation)

→ SSR 과 동일하게 누구에게나 항상 같은 내용을 보여주는 페이지.

→ 홍보 혹은 상위 노출이 필요한 페이지 → 단, 💡업데이트를 거의 하지 않는 페이지

🚩 Universal Rendering (초기 렌더링 SSR + 이후 CSR)

→ 사용자에 따라 페이지 내용이 변하는 경우

→ 빠른 반응 및 응답과 화면 깜빡임 현상이 없어야 하는 경우

→ SEO를 포기할 수 없는 경우 (= 홍보 및 상위 노출의 필요성)