CSR, SSR, SSG 정리

https://youtu.be/iZ9csAfU5Os?si=dWfuGRQuhMFz9jUQ

드림코딩 유튜브 영상을 본 후 정리한 내용이다.

---

1990년 중반까지는 Static Sites로, 클릭할 때마다 html을 서버에서 불러와서 페이지 전체가 update

 

1996년 <iframe> 도입 - 문서 내에서 또 다른 문서를 담을 수 있는 태그

                                    - 부분적 update 가능

 

1998년 - XMLHttpRequest API(fetch API의 원조)

             - HTML 문서 전체가 아니라 JSON과 같은 포맷으로 서버에서 가볍게 필요한 데이터만 받아올 수 있음.

             - Data는 JS를 이용해서 동적으로 HTML 요소 생성

 => 2005년 - 공식적인 이름 AJAX

    -> web Application(gmail, google map...)

       => SPA(Single Page Application) : 필요한 데이터를 부분적으로 받아와 부분적 update

          => React, Vue, Angular framework

              => CSR

 

 

(1) 서버에서 index.html 송신 -> index.html에는 js 링크만 포함되어 있음

(2) index.html에 포함된 js 링크를 다운로드

     -> js에는 어플리케이션에서 필요한 로직, 어플리케이션을 구동하는 프레임워크와 라이브러리의 소스코드 포함

(3) 추가 요청 데이터와 js를 기반으로 동적으로 html을 생성하여 화면에 표출

 

* CSR 단점

  - 사용자가 첫 화면 보기까지 시간 소요가 많이 됨.

    (TTI와 TTV 동시)

  - Low SEO(Search Engine Optimization)

    -> CSR html은 js 링크만 내포함에 따라 검색엔진 분석에 대한 어려움

    * Web crawlers - 서버에 등록된 website의 html 문서 분석(title, description, link ..) -> 빠른 검색에 도움을 줌

 

=> SSR 등장! (<- Static Sites 영감)

 

서버에서 필요한 data 모두 가져와서 HTML 파일 생성

 -> 동적으로 제어할 수 있는 소스코드(JS)와 함께 클라이언트에게 전달

   -> 클라이언트 : 사용자에게 바로 전달(화면 표출)

 

* SSR 장점

  - 초기 화면 로딩 속도

  - Great SEO(Search Engine Optimization)

     -> 모든 콘텐츠가 html에 담겨있어 효율적인 SEO!

 

* SSR 단점

  - Static Sites에서 발생했던 Blinking Issue

    -> 전체적인 website를 다시 서버에서 받아오는 것과 동일 -> Bad UI

  - 서버 과부하

    -> 사용자가 많을수록 과부하 ↑

        (많은 사용자가 클릭할 때마다 서버에서 필요한 data 가져와서 html을 만들어야 함)

- 사용자가 빠르게 웹사이트를 확인할 수는 있지만,

  동적으로 데이터를 처리하는 JS를 아직 다운받지 못해 반응이 없는 경우가 발생할 수 있음

  -> TTV 후에 TTI가 이루어짐(그 사이의 공백기간 큰 편)

 

** TTV (Time to View)        :  사용자가 웹브라우저에서 내용을 보는 시점

** TTI  (Time to Interact)   :  사용자가 웹브라우저에서 인터렉션(클릭 등)할 수 있는 시점

 

React = CSR에 특화된 라이브러리

React + Gatsby => React로 만든 웹 어플리케이션을 정적으로 웹페이지를 미리 생성해두어서 서버에 배포해 놓을 수 있음

(+동적인 요소도 추가 가능)

 

Next.js = 강력한 CSR을 지원하는 라이브러리 but SSG, CSR+SSR 지원