SSR(서버사이드랜더링) vs CSR(클라이언트사이드랜더링)

[ 렌더링이란 ? ]

현재 페이지를 그리기전 DOM tree + CSSOM을 결합해 만들어진 렌더링 트리를 이용해 레이아웃단계를 거쳐 페인팅(화면에 그려주는 것)되는 과정을 말한다. 

브라우저 동작 과정 에 렌더링 관한걸 적어두었다 참고하면 좋을꺼같다 ㅎㅎ

 

렌더링 방식에는 2가지가 있다. 

 

1. SSR - Server Side Rendering

- Client에서 요청시마다 페이지가 새로고침되며, 화면이 어떻게 보여질지 Server에서 해석하여 Client에게 보내주는 방식

- 웹의 초기부터 SPA에 대한 구현체들이 나오기 전까지는 전통적인 웹사이트들은 모두 MPA 형태로 서비스해 왔다.

MPA는 페이지를 이동할 때마다 새로운 페이지를 요청한다. 모든 템플릿은 서버 연산을 통해서 렌더링하고 완성된 페이지 형태로 응답한다. 이 과정을 서버 사이드 렌더링(SSR)이라고 부른다. 

 

 

2. CSR - Client Side Rendering

- 처음에 하나의 빈 페이지를 서버측에서 제공하고, View에 대해서는 Client에서 JavaScript를 통해 렌더링 하는 방식이다.

- SPA (Single Page Application) 이 CSR방식을 주로 사용한다. SPA 특징은 최초 한 번 페이지 전체를 로딩한 후에 데이터만 변경하여 사용하는 방식이다. 

 

[ MPA & SPA ]

• MPA ( Multi Page Application ) : 다중 페이지 어플리케이션
  •  

    

  • 여러개의 페이지로 구성된 어플리케이션이다. 
  • 전통적인 웹 애플리케이션 개발 방식으로 jsp , php 등과 같은 웹 서버 언어로 구축된 웹사이트에서 많이 보인다.
  • 웹 브라우저에서 특정 페이지에 대한 요청을 서버에 보낼 때 마다 서버는 데이터를 HTML 문서로 웹 브라우저에 응답해준다. ( 매번 전체 페이지가 다시 불러와지면서 화면이 깜빡거리는 현상이 일어남 )
  • 주소창을 입력하거나 , 새로고침 , 또는 일부 데이터가 바뀌는 등 사용자가 어떤 요청을 하게되면 그에 맞는 html , 이미지 등의 파일들이 전부 다운로드 되고 다시 렌더링 된다. ( SSR : 서버 사이드 렌더링 방식 )
  • AJAX를 통해서 화면이 깜빡거리는 현상을 어느정도 해결은 했지만 근본적인 페이지 새로고침된다는 문제는 해결할 수 없다.
  • MPA 구조는 프론트엔들와 백엔드가 2계층 구조로 결합되어 있어 비즈니스가 복잡해지거나 비대해진다면 관리하기가 어려워진다.
  • MPA의 장점이 있다면 SEO (Search Engine Optimization, 검색 엔진 최적화) 친화적이다. 그 이유는 MPA는 완성된 형태의 HTML 파일을 서버로 부터 전송 받기 때문에 검색 엔진이 크롤링하기에 적합하다. 
• SPA ( Single Page Application ) : 단일 페이지 어플리케이션
  •  

    

  • 한개의 페이지로 구성된 어플리케이션이다. 
  • MPA의 단점을 개선해줄 수 있는 것이 SPA이다. SPA는 하나의 HTML 파일을 가지고 javascript를 이용해 동적으로 화면을 구성한다. 서버는 최조 실행 시 HTML 파일을 비롯한 정적 자원을 클라이언트에 보내주며 , 이후에는 JSON 데이터를 전송 하며 데이터만을 바꿔준다. ( CSR : 클라이언트 사이드 렌더링 방식이지만 SPA 모두 CSR인 것은 아니다)
  • 즉, 최초에 서버에서 받아온 HTML 파일에서 변경되는 부분만 다시 렌더링하기 때문에 새로고침을 해도 깜빡이는 현상이 없고 성능면에서도 매우 뛰어나다.
  • 하지만 단점도 존재한다. 최초 실행 시 모든 정적 리소스를 받아오기 때문에 초기 로딩 속도가 느리며 , SEO에 취약하다. 
  • Angular , React , Vue 등 프론트엔드 기술들이 나오면서 크게 유행하고있다.

	MPA	SPA
장점	1. SEO 관점에서 유리하다.  - 완성된 형태의 HTML 파일을 서버로부터 전달받아 검색엔진이 페이지를 크롤링하기에 적합하다. 2. 첫 로딩이 빠르다  - 서버에서 이미 렌더링해서 가져오기 때문 - 그러나 클라이언트에서 JS 파일을 모두 다운로드하고 적용하기 전 까지는 각각의 기능은 동작하지 않는다.	1. 깜빡임이 없다.  - 최초 한번만 서버에서 정적리소스를 전부 받아 캐시에 저장한다. 그 후 필요한 리소스만 부분적으로 로딩하기 때문에 UX적인 면에서도 좋고 성능적으로도 좋다. 2. 서버의 템플릿 연산을 클라이언트로 분산한다.  3. 컴포넌트별 개발이 용이하다.  4. 모바일 앱 개발을 염두에 둔다면 동일한 API를 사용하도록 설계가 가능하다.
단점	1. 페이지 깜빡임 현상 (UX 적인 문제) - 매 페이지 요청마다 전체 페이지를 다시 렌더링하기 때문에  2. 페이지 이동시 불필요한 템플릿도 중복해서 로딩 (성능 문제) 3. 서버 렌더링에 따른 부하 (성능 문제) 4. 모바일 앱 개발시 추가적인 백엔드 작업이 필요해 개발이 복잡해진다. (생산성 문제)	1. 초기 구동 속도가 느리다. - Javascript 파일을 번들링해서 한 번에 받기 때문에  (페이지를 읽는 시간 + JS를 읽는 시간 + JS가 화면에 그리는 시간) -> (Webpack의 code splitting으로 해결 가능) 2. 검색 엔진 최적화(SEO)가 어렵다  - SSR 를 적용할 수 있기때문에 해결 가능하다. 3. 보안 이슈 - 프론트엔드에 비즈니스 로직을 최소화해야 한다. - SSR 에서는 사용자의 대한 정보를 서버측에서 세션으로 관리하지만 CSR 방식에서는 클라이언트 측의 쿠키말고는 사용자에 대한 정보를 저장할 공간이 마땅치 않다.