CSR(Client Side Rendering)과 SSR(Server Side Rendering)

CSR와 SSR을 비교하며 알아보기 전에

SPA(Single Page Application)과 MPA(Multiple Page Application)에 대해 알아보자

 

◎ SPA (Single Page Application)

    한개의 html 파일을 기반으로 Javascript를 이용해 화면의 컨텐츠를 동적으로 바꾸는 방식의 웹 어플리케이션

    -> 웹 어플리케이션에 필요한 모든 리소스를 최소 한번에 다운로드한다.

• 장점
  1. 페이지 요청시 전체 페이지를 업데이트 할 필요가 없기에 화면에 깜빡 거림이 없어 사용자 경험(UX)가 좋다.
  2. 정적 리소스를 한번만 요청하고 받은 데이터는 전부 저장하기에 필요한 리소스만 로딩하기에 성능 면에서 좋다.
  3. 서버의 템플릿 연산을 클라이언트로 분산이 가능해 성능면에서 좋다.
  4. 컴포넌트 별로 개발하기에 좋다.(React가 대표적인듯) 생산성이 좋다.
• 단점
  1. Javascript 파일을 번들링해 한번에 받기에 초기 구동 속도가 느리다.(webpack의 code splitting으로 해결 가능하다)
  2. 검색엔진최적화(SEO: Search Engine Optimization)가 어렵다.(SSR로 해결 가능하다)

 

◎ MPA (Multiple Page Application)

    새로운 페이지 요청이 있을 때마다 정적 리소스(HTML, CSS, Javascript)를 다운로드한다.

• 장점
  1. 검색엔진최적화(SEO)에 유리
     완성된 형태의 HTML 파일을 서버로 부터 받기에 검색엔진이 페이지를 크롤링하기 쉬워 검색엔진최적화(SEO)에 유리하다
  2. 이미 렌더링되어 받아오기에 초기 로딩이 짧다.
     
     
• 단점
  1. 새로운 페이지 요청시 페이지 전체를 로딩하기에 새로운 페이지로 이동시 화면이 깜빡인다.
  2. 클라이언트가 파일을 모두 다운로드하고 적용하기 전까지 각각의 기능이 동작하지 않는다.
     
  3. 페이지 이동시 중복된 템플릿도 로딩해 성능면에서 좋지 않다.
  4. 서버에서 렌더링 하기에 서버에 부하가 있다.

 

위에서 적혀 있듯이 SPA는 CSR를, MPA는 SSR를 사용하는 것이 일반적이지만,

모든 SPA와 MPA가 CSR, SSR을 각각 사용한다는 것은 아니다.

 

SPA가 SSR를 사용하면 SPA에서의 단점(SEO)를 보안할 수 있다.

 

 

 

◎ CSR(Client Side Rendering)

렌더링이 클라이언트에서 일어나며,

요청받은 서버에서 HTML과 JS를 보내주면 클라이언트는 렌더링을 하는 방식이다.

CSR의 단계를 설명하는 사진이다

단계 별로 알아보자

1. 사용자가 웹 사이트 요청을 보낸다.
2. CDN이 HTML 파일과 JS로 접근할 수 있는 링크를 보내준다.
   (CDN: Content Delivery Network은 데이터 사용량이 많은 애플리케이션의 웹 페이지
   로드 속도를 높이는 상호 연결된 서버 네트워크이다)
3. 클라이언트는 HTML과 JS를 다운로드 받는다.(사용자는 아무것도 볼 수 없다)
4. 3과 비슷(하지만 
5. 다운로드된 JS가 실행된다. 또한 데이터를 위한 API가 호출된다.
6. 서버가 API 요청에 응답
7. API로 받아온 데이터를 placeholder에 넣어주면서 상호작용 가능한 페이지가 된다.

정리하자면,

클라이언트에서 요청이 오면 서버는 처리없이 보내주며, 클라이언트는 받은 파일들이
다운로드되고 실행될때 까지 화면은 볼 수 없다.

리엑트에서 실행되는 과정이 아래의 사진과 같다.

• 장점
  1. 사용자는 첫 로딩만 기다리면 동적으로 빠르게 렌더링 되기에 사용자 경험(UX)이 좋다.
  2. 서버에게 요청하는 횟수가 SSR에 비해 적기 때문에 서버의 부담이 적다.
• 단점
  1. 모든 스크립트 파일이 로드될 때까지 기다려야 한다.
     (청크chunk 단위로 리소스를 묶어 요청할 때만 다운받게 해서 완화시킬 수는 있지만 완벽히 해결 불가)
  2. 검색엔진 최적화(SEO)에 어려움이 있다.
     (구글 봇의 경우 JS를 지원하지만,
     다른 검색엔진의 경우 그렇지 않기에 검색엔진의 검색 봇이 크롤링하기에 어려움이 있다.)

 

 

◎ SSR(Server Side Rendering)

서버측에서 렌더링을 해준 상태에서 클라이언트로 전달해주는 방식이다.

SSR의 과정을 보여주는 사진이다.

단계별로 알아보자

1. 사용자가 웹 사이트 요청을 보낸다
2. 서버가 즉시 렌더링 가능한 HTML파일을 만든다
3. 브라우저가 HTML을 받는 순간 즉시 렌더링 되지만, 상호작용은 JS가 읽히기 전이므로 되지 않는다.
4. 클라이언트가 JS를 다운로드한다.
5. JS가 다운로드 되기 전까지 컨텐츠는 보여지지만 상호작용은 되지않는다. 이때 사용자 조작을 기억하고 있는다.
6. 브라우저가 JS 프레임워크를 실행한다.
7. JS가 컴파일되었기 때문에 기억하고 있던 사용자 조작이 시작되고, 상호작용되는 웹 페이지가 된다.

정리하자면,

서버에서 즉시 렌더링 가능한 HTML 파일을 생성하고 보내주며,

JS가 다운로드, 컴파일 되기 전까지 사용자 조작을 기억하고 완료되면 사용자 조작을 실행.

리엑트에서 실행되는 과정이 아래의 사진과 같다.

 

• 장점
  1. 서버에서 렌더링되어 초기 로딩 속도가 빠르기에 사용자가 빨리 볼 수 있다.
  2. JS를 이용한 렌더링이 아니기에 검색엔진 최적화가 가능하다.
• 단점
  1. 페이지 요청을 할 때마다 새로고침이 되기에 사용자 경험이 SPA에 비해 좋지 않다.(깜빡 거림 등)
  2. 서버에게 요청을 많이 보내기 때문에 서버의 부하가 커진다.