CSR, SSR, SSG 간단하게라도 알고가자

CSR (Client Side Rendering)

 

요즘 대세인 리액트는 CSR의 대표적인 예시이다. 말 그대로, CSR은 클라이언트 브라우저에서 초기에 어플리케이션 구동에 필요한 모든 파일을 로드한 뒤에 뷰가 구성된다.

 

 

CSR의 특징

 

• 최초 페이지 로딩시간이 오래 걸린다.
  • 아무래도 초기에 모든 파일들을 다운로드받아야 하기 때문에, 첫 화면이 구성되는 데에 다른 방식에 비해 오래걸릴 수 밖에 없다.
• 최초 페이지는 느릴지라도, 그 다음부터 페이지 이동이 빠르다.
  • 최초 페이지 이후에서는 모든 파일들이 준비된 상태이기 때문에, 페이지를 이동할 때 굉장히 빠르다.
• SEO가 다른 방식에 비해 조금 부족하다.
  • CSR이 SEO가 되지않는 것이 아니다. 그저 조금 부족할 뿐, 문제없다고 생각한다.
  • CSR이 SEO에 취약하다는 의견에 대해서는 여러가지 의견이 있는 것 같다. 특히나, 구글 검색봇은 자바스크립트를 지원하기 때문에 CSR 사이트도 문제없이 SEO가 잘 된다. 그리고 메타태그를 적절히 활용할 수 있다면 HTML만을 파싱하는 검색엔진에서도 노출될 수 있다. 물론 SSR과 비교하면, SEO가 부족한 것이 맞다. 하지만 CSR의 대표적인 단점인 SEO가 취약하다는 점은 생각보다 의미 없을 수도 있다는 의견이다.

 

 

---

 

SSR (Server Side Rendering)

 

클라이언트가 특정 url로 접속 시, 그에 해당하는 페이지의 파일을 서버에 요청하면, 서버에서 파일을 전달하는 형식이다.

 

SSR의 특징

 

• 초기에 모든 파일을 로드하지않기 때문에 확실히 CSR에 비해 최초 페이지 로드시간이 짧다.
• 그래서, 그만큼 페이지 이동간에 시간이 오래 걸린다. (CSR에 비해)
• SEO에 적합하다.
  • 완성된 HTML을 서버로부터 받아오므로 SEO에 적합하다.

 

 

 

---

 

 

 

SSG (Static Site Generator)

 

약간 SSR과 CSR을 혼합해놓은 방식이라는 느낌이 든다. 대표적으로는 Next에서 default로 사용되는 방식이다. 사전 렌더링이란 개념으로 각 페이지들의 HTML파일들을 미리 생성하여 서버에서 가지고 있는다. 그리고 클라이언트에서 URL에 따라 요청이 들어올 때 파일을 보내주는 방식이다.

 

 

SSG의 특징

 

• 아무래도 사전 페이지별 파일을 서버에서 가지고 있기 때문에 로드시간이 SSR에 비해 짧다.
• 심지어, 사전 빌드된 HTML파일을 서버에서 제공하므로 SEO에 친화적이다.
• 하지만, 사전 빌드된 파일이라는 장점때문에 동적인 데이터가 사용되는 사이트에는 적합하지 못하다.
  • 블드되는 시점에 페이지별 파일들이 생성되기 때문에, 동적인 데이터를 사용하게되면 데이터가 변경될 때마다 계속해서 빌드를 해주어야 한다. 

 

 

 

Next에서는 SSG와 SSR을 적용하여 동적인 사이트에 대응이 가능하다.

 

그리고 ISR방식이라고 SSG와 똑같이 빌드 시점에 페이지를 생성하지만, 일정 주기마다 데이터의 최신 여부를 업데이트하여 다시 생성하는 방식도 있다고 한다.

 

 

 

---

 

 

 

 

 

이론으로만 접해봤을 뿐, CSR방식의 프로젝트만 진행해본 나에게는 위의 것들이 크게 와닿지 않는 것 같다. 좀 더 다양한 방식의 프로젝트를 진행해보고 그 차이점들을 직접 느껴보고싶다는 생각이 든다.