CSR vs SSR vs SSG

Dongjun Ahn·2022년 4월 21일
0

CSR(Client Side Rendering)

CSR은 react, vue 등의 SPA(Single Page Application)에서 쓰이는 기법으로, 서버에서 화면을 구성했던 SSR 방식과 달리 클라이언트에서 화면을 구성한다.
SPA의 경우 첫 화면에 들어가게 되면, 데이터를 제외한 화면을 그리는 코드들이 프론트 서버에서 다운받아 진다.
(데이터를 제외한 코드들은 js파일에 한번에 번들되어 오기때문에 번들된 이 파일을 처음에 다운받는데 시간이 꽤 걸릴 수 있지만 code splitting이라는 기능으로 어느정도 해결 가능)

장점

  • 첫 로딩만 기다린다면 이후 좋은 UX를 제공
  • 연속된 렌더링으로 인한 과부하를 줄일수 있음.

단점

  • 초기 렌더링 속도가 느리다.
  • 검색 엔진 최적화에 문제가 발생한다.

SSR(Server Side Rendering)

SSR은 서버에서 사용자에게 보여줄 페이지를 모두 구성하여 사용자에게 페이지를 보여주는 방식이다.
SSR을 사용하면 모든 데이터가 매핑된 서비스 페이지를 클라이언트(브라우저)에게 바로 보여줄 수 있다. 서버를 이용해서 페이지를 구성하기 때문에 클라이언트에서 구성하는 CSR(client-side rendering)보다 페이지를 구성하는 속도는 늦어지지만 전체적으로 사용자에게 보여주는 콘텐츠 구성이 완료되는 시점은 빨라진다는 장점이 있다. 더불어 SEO(search engine optimization) 또한 쉽게 구성할 수 있다.

장점

  • 초기 렌더링 속도가 빠르다.
  • JS를 이용한 렌더링이 아니므로 SEO(검색 엔진 최적화)가 가능하다. => HTML에 모든 컨텐츠가 저장되어 있음.

단점

  • 매번 새로운 페이지를 요청할 때 마다 새고로침이 발생한다.
  • 간단한 데이터 수정에도 서버를 거쳐야한다.
  • 서버에 요청을 하는 행위는 서버에 과부하의 원인이다.

SSG(Static Site Generator)

SSR처럼 서버로부터 완성된 HTML을 받아오지만, 다른 점은 HTML 파일의 생성시점이 빌드 타임이라는 것이다. Static이라는 용어가 들어간 것은 HTML이 정적이라는 것이지 페이지가 정적이라는게 아니므로 오해하지 말아야 한다.
Next.js에서 권장하는 렌더링 방식이기도 하다.

장점

  • 빌드 타임에서 HTML 파일이 생성되기 때문에 빠른 FP, FCP, TTI를 제공한다. 또한 매 요청마다 생성 하는 것이 아니므로, SSR 과 다르게 일관성있게 빠른 TTFB를 달성한다. (그냥 빠르다는 뜻)
  • Build 명령 자체가 실제로 사이트를 방문하는 사람의 워크플로에서는 벗어나므로 문제가 되지않는다.

단점

  • 모든 URL에 대해 개별 HTML 파일을 생성해야 한다. 따라서 URL을 미리 예측할 수 없거나 URL을 예측할 수 없으면 적용이 어렵다.

SEO(Search Engine Optimization)

대부분의 웹 크롤러, 봇들은 JS를 실행시키지 못하고 HTML에서만 컨텐츠를 수집한다.
따라서 방식으로 개발된 페이지를 빈 페이지로 인식하게 되고 SSR 방식은 View를 서버에서 전부 렌더링하기 때문에 HTML에 모든 컨텐츠가 저장되어 있어 SEO를 사용하는데 문제가 없다.

References

https://d2.naver.com/helloworld/7804182
https://velog.io/@ksh4820/SPA-CSR%EA%B3%BC-SSR-SEO
https://front-end.me/web/web-site-optimization/

profile
Front-end Developer

0개의 댓글