CSR과 SSR? (feat. CDN이란)

SPA와 MPA

SPA (Single Page Application)

React, Vue와 같은 프레임워크처럼 하나의 페이지로 구성된 웹 어플리케이션 입니다.

SPA는 CSR 방식을 채택합니다.

 

MPA (Multi Page Application)

탭을 이동할 때마다 서버로부터 화면에 필요한 새로운 HTML 파일을 받아와서 페이지 전체를 새로 렌더링하는 전통적인 방식입니다.

MPA는 SSR 방식을 채택합니다.

 

 

브라우저 렌더링은 크게 CSR과 SSR의 방식으로 나누어집니다.

CSR (Client Side Rendering)

렌더링이 클라이언트 쪽에서 일어납니다.

서버는 요청을 받으면 클라이언트에게 HTML과 JS 파일을 보내줍니다. 클라이언트는 해당 콘텐츠를 받아 렌더링을 시작합니다.

 

1. 유저가 서버에 웹사이트와 관련한 요청을 보낸다.
2. CDN이 HTML파일과 JS로 접근할 수 있는 가까운 링크를 클라이언트로 보낸다.
3. 클라이언트는 서버로부터 데이터를 제외한 빈 뼈대만 포함된 HTML 파일을 다운로드 받는다. 이 때 SSR과는 달리 유저는 아무것도 볼 수 없다.
4. 그리고 링크를 통해 JS파일을 다운로드 받는다.
5. 다운이 완료된 JS가 실행되어 동적 DOM을 생성하고, 데이터를 위한 API를 호출한다.
6. 서버가 API로부터 요청에 응답한다.
7. API로부터 받아온 데이터를 placeholder 자리에 넣어준다. 이제 페이지는 상호 작용이 가능해진다.

 

CDN(Content Delivery Network)이란?

지리, 물리적으로 떨어져 있는 사용자에게 컨텐츠를 더 빠르게 제공하는 기술을 의미한다.
사용자가 원격지에 있는 서버(Origin Server)로 부터 Content(ex Web Object, Video, Music, Image, Document 등)를 다운로드 받을때 가까이 있는 서버에서 받는 것보다 시간이 오래 걸린다. 
그러므로 사용자와 가까운 곳에 위치한 Cache Server에 해당 Content를 저장(캐싱)하고 Content 요청시에 Cache Server가 응답을 주는 기술이다.

1. 웹사이트 로딩 속도 개선
물리적으로 가까운 서버에 요청을 보내기 때문에 로딩 속도가 개선된다.
2. 인터넷 회선 비용 절감
3. 컨텐츠 제공의 안정성
하나의 CDN 서버가 오프라인 상태가 되더라도 다른 운영 서버가 해당 서버를 대체하여 서비스가 중단되지 않도록 할 수 있습니다.
4. 웹사이트 보안 개선
DDOS 공격의 경우 대량의 가짜 트래픽을 웹사이트로 전송해서 어플리케이션의 동작이 중지되도록 하는 공격입니다. CDN은 여러 중간 서버 간의 로드를 분산시켜서 오리진 서버에 끼치는 영향을 줄임으로써 이러한 트래픽 급증을 처리할 수 있습니다.

 

CSR의 장점

• 빠른 인터렉션을 구현할 수 있다.
  • View 렌더링을 브라우저에게 담당시킴으로서 서버 트래픽을 감소시키고, 사용자에게 더 빠른 인터렉션을 제공합니다.
  • 모든 리소스를 다시 다운받는게 아니라, 변경이 일어난 부분의 리소스만 요청하므로 새로고침이 발생하지 않습니다.
• 서버 부하 감소
• TTV(Time to View)와 TTI(Time to Interaction) 사이 간극이 없다.

 

CSR의 단점

• 서버에 첫 요청을 보낼 때 전체 페이지에 대한 모든 문서 파일을 받다 보니 SSR보다 첫 페이지 로딩 속도가 느립니다.
  • code-splitting, tree-shaking, chunk 분리 등을 통해 보완할 수 있음
• 검색엔진최적화(SEO)에 대한 추가 보완 작업이 필요합니다.
  • 검색 엔진이 색인을 할 만한 콘텐츠가 존재하지 않기 때문에 SEO에 불리하다.
  • 구글의 검색엔진의 경우 자바스크립트 엔진이 내장되어 있어 크롤링이 되지만, 네이버나 다음의 경우 검색 엔진이 제대로 크롤링하지 못하기 때문에 별도의 보완 작업이 필요합니다.
  • 웹팩 플러그인의 pre-rendering을 설정하여, 각 페이지에 해당하는 html 파일을 미리 생성해두고 서버에서 요청하는 자가 크롤러라면 사전에 렌더링해 둔 html 파일을 보여주는 식으로 SEO를 개선할 수 있음
• 혹은 CSR에 SSR을 도입하는 방법으로 단점을 개선할 수 있습니다.
  • next.js: react에서 SSR을 사용할 수 있도록 도와줌.
  • nuxt.js: vue에서 SSR을 사용할 수 있도록 도와줌.

 

SSR (Server Side Rendeing)

서버쪽에서 렌더링 준비를 마친 상태로 클라이언트에 전달하는 방식입니다.

1. 유저가 서버에 웹사이트와 관련한 요청을 보낸다.
2. 서버는 즉시 렌더링 가능한 html 파일(화면에 표시하는데 필요한 데이터를 얻어와 삽입하고, css까지 모두 적용해서 렌더링 준비를 마친 HTML 파일) 을 응답으로 전달합니다.
3. 클라이언트에 전달하는 순간, 이미 렌더링 준비가 되어 있기 때문에 HTML은 즉시 렌더링된다.
   하지만 Javascript가 읽히기 전이므로 사이트 자체는 조작 불가능하다.
4. 클라이언트가 JS를 다운받는다.
5. JS를 다운받는 동안 유저는 콘텐츠를 볼 수 있지만 사이트를 조작할 수는 없다. 이 때의 사용자 조작을 기억하고 있는다.
6. 브라우저가 Javascript 프레임워크를 실행한다.
7. JS까지 모두 컴파일되고 나면 기억하고 있던 사용자 조작이 실행되고 웹 페이지는 상호작용이 가능한 상태가 된다.

 

SSR의 장점

• 첫 페이지 로딩 속도가 CSR보다 빠르다.
  • 첫 페이지에 필요한 부분의 HTML과 JS만 불러오므로, CSR에 비해 더 빠르다.
• 검색엔진최적화(SEO)가 가능합니다.
  • 모든 데이터가 이미 담겨진 채로 브라우저에 전달되기 때문

 

SSR의 단점

• 초기 로딩 이후 페이지 전환이 있을 때 속도가 CSR에 비해 느리다.
  • 페이지를 이동할 때마다 불필요한 부분까지 모두 포함하여 서버에게 필요한 데이터를 요청하기 때문에 새로고침되어 화면이 깜박인 후 표시된다.
• SSR은 페이지가 전환될 때마다 매번 서버에 요청을 하기 때문에 서버 자원을 더 많이 사용한다.
• TTV(Time to View)와 TTI(Time to Interaction) 사이 간극이 있다..

 

사용 권장 예시

SSR 사용 권장 예시

• 네트워크가 느릴때. CSR은 초기 화면을 렌더링 할 때 한번에 모든 것을 불러오지만 SSR은 각 페이지마다 나눠 불러오기 때문에!
• SEO가 필요할 때 (상위 노출이 필요할 때)
• 최초 로딩이 빨라야 하는 사이트를 개발할 때
• 웹 사이트 상호작용이 별로 없을 때

CSR 사용 권장 예시

• 네트워크가 빠를 때
• 서버의 성능이 좋지 않을 때
• 주로 고객 개인 정보로 이루어진 페이지라 SEO는 크게 중요하지 않을 때
• 웹 어플리케이션에 사용자와 상호작용할 것들이 많을 때. (초기 화면에서 아예 렌더링 되지 않아서 사용자의 행동을 막는 것이 사용자 경험에 오히려 유리함)

 

Reference

• https://velog.io/@vagabondms/%EA%B8%B0%EC%88%A0-%EC%8A%A4%ED%84%B0%EB%94%94-SSR%EA%B3%BC-CSR%EC%9D%98-%EC%B0%A8%EC%9D%B4
• https://miracleground.tistory.com/entry/SSR%EC%84%9C%EB%B2%84%EC%82%AC%EC%9D%B4%EB%93%9C-%EB%A0%8C%EB%8D%94%EB%A7%81%EA%B3%BC-CSR%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8-%EC%82%AC%EC%9D%B4%EB%93%9C-%EB%A0%8C%EB%8D%94%EB%A7%81
• https://www.youtube.com/watch?v=YuqB8D6eCKE 
• https://aws.amazon.com/ko/what-is/cdn/