SSR, CSR과 SPA의 등장배경

📌 용어 정리

 

SSR = Server Side Rendering

- 서버 사이드 렌더링

 

CSR = Client Side Rendering 

- 클라이언트 사이드 렌더링

 

SPA = Single Page Application

- 싱글 페이지 어플리케이션

 

 

📌 SSR

 

기본적으로 웹은 클라이언트의 요청으로 서버에서 응답받아 HTML을 받아온다.

클라이언트는 이 HTML을 받아 DOM을 그리게된다.(DOM을 그리며 css와 js를 로드하며 브라우저를 렌더링한다)

 

단점 - 웹의 정보도 많아지고 데이터의 양이 커지며 서버는 수많은 응답을 처리해야되기 때문에 부하가 커지게 되고, 클라이언트(사용자) 입장에서도 페이지 깜빡임이 발생하게 된다.

 

이로인해 Ajax가 등장하고 비동기 처리가 가능하게 되었다

 

 

📌CSR

 

더나아가 SPA개념이 생기게 되었다

react는 이 SPA를 만드는 것을 지원하는 라이브러리이며, CSR (client Side Rendering) 방식으로 동작한다

 

CSR, client Side Rendering은 서버에서 응답 받은 HTML을 매번 받아와서 그리는 것이 아니라 client 가 알아서 화면을 그리게 된다.

 

react에서는 build시 내가 짠 모든 코드를 하나의 js파일(bundle.js)로 만들어준다

(babel로 트랜스파일링, webpack으로 bundling)

 

CSR은 → 사이트 접속 시, 서버에서 비어있는 HTML을 reponse하고 클라이언트에서 bundle.js를 읽어 DOM화면을 그리는 것이다

 

단점 - 서비스 사이즈가 커질수록 bundle.js, 번들링된 하나의 자바스크립트 파일의 크기가 당연히 커지게 된다. 커질수록 로드시간이 오래걸려 사용자가 첫화면을 보기까지가 오래걸린다 (SEO(검색 엔진 최적화) 관련 문제도 있음)

 

 

CSR의 단점인 bundle.js 파일 데이터가 많아서 사용자가 첫화면을 보기까지가 오래걸린다면 코드를 쪼개는 방법도 있다(code splitting) → url마다 각각의 번들링된 js파일을 만들 수 있다. → 로드시간을 줄일 수 있음

 

 

📌 그럼 CSR과 SSR을 합쳐서 만들면 어떨까? → next.js !

 

next.js → 첫화면은 서버에서 html(빈 html이 아닌 내용이 채워져 있는 html) 을 받아서 렌더링하고 그 후부터 클라이언트에서 DOM을 그대로 그리면 된다. → 화면깜빡임 없이 사용하고 SEO 대응도 가능하다