CSR과 SSR의 차이

 

현대 대부분의 프론트 프레임워크들은 SPA를 만드는데 초점이 맞춰져 있다.

그 이유야 SPA가 MPA에 비해 더 좋은 사용자 경험을 전달해주기 때문일 것이다.

 

결국 우리가 필요한 웹사이트는 HTML이 보여주는 것인데, 이런 HTML을 사용자 측에서 렌더링하느냐 서버에서 렌더링하느냐로 CSR, SSR이 나뉜다.

 

1. CSR

SPA는 기본적으로 CSR로 이루어지는데, 이는 SPA의 작동원리 때문이다.

1. SPA는 처음에만 서버에서 CSS, HTML, JS를 받는다.

2. 이 파일들을 이용하여 렌더링을 진행한다.

3. 그 후에는 데이터만 가져온다.

 

이는 처음에 가져온 JS를 통해 받아온 데이터를 클라이언트에서 처리하기 때문이다.

따라서 처음 CSS, HTML, JS를 받아오는 과정은 오래 걸리지만, 그 후에는 SPA의 장점을 살려 빠르고 좋은 환경을 경험할 수 있다.

 

다만 SPA는 사실상 HTML은 빈 파일이고, 이를 JS가 동적으로 채워나가는 방식으로 홈페이지를 구성하는데, 이는 SEO가 빈 HTML만을 읽는 참사가 일어날 수 있다. (구글은 JS를 읽어서 이런 문제에서는 자유롭다고 한다.)

 

2. SSR

SSR은 서버에서 이미 렌더 가능한 HTML을 클라이언트에 제공한다.

1. 서버에서 렌더링 가능한 HTML을 받는다.

2. 이 HTML을 이용하여 일단 렌더링을 진행한다. (하지만 JS가 없어서 상호작용은 되지 않는다.)

3. 그 후에 JS를 받아와 상호작용이 가능한 사이트가 된다.

4. 만약 상호작용이 일어나면 1~3 과정을 반복한다.

 

이는 CSR에 비해 초기 렌더링을 간소화하고, 따라서 사용자가 빠르게 초기 화면을 볼 수 있다.

물론 HTML을 받은 후 사용자에게 웹사이트를 보여주고 -> 그 후에 다시 JS를 불러와야지 상호작용이 가능한 사이트가 된다.

따라서 사이트가 보여지는 시점과 사용가능한 시점에 시간차가 생긴다.

 

또한 서버와 상호작용을 진행할 때도 HTML, JS를 받아오는 과정을 반복하므로, 데이터만 받아오는 CSR에 비하여 느리게 작동한다.

또한 서버에서 HTML을 계속 보내는 경우 당연히 데이터만 보내는 CSR보다 서버의 부담이 크다.

 

3. 대책

따라서 CSR의 단점을 보완하면서도 SPA를 사용하기 위한 방법이 필요하다.

그 중 하나의 방법이 바로 SSR과 CSR을 혼용하여 사용하는 방식이다.

대표적으로는 Next.js가 있다.

 

Next.js는 

1. 서버에서 SSR 방식으로 HTML을 렌더링한다.

2. 그 후 브라우저에서 JS를 다운받고 리액트를 실행한다.

3. 이후에는 CSR 방식으로 작동한다.

 

따라서 초기 렌더링이 빠르면서 SEO에 유리하고 SPA 방식을 사용할 수 있다.