# 간단 요약 * CSR: 초기 로드(빈 HTML, js 다 내려받아야해서 느림) 후 브라우저에서 그때그때 동적으로 그리기때문에 온전히 사용자 기기 성능에 따라 빠를 수도 느릴 수도 있음. 그리고 SEO에 취약함. * SSR: 초기 로드(HTML를 바로 내려받아서 빠름) 후 사용자가 보려고 하는 페이지를 서버에서 다 그려주고 보여주기 때문에 서버에 부하가 있을 수 있음. 그리고 SEO에 유리함. * SSG: 모든 URL에 대한 콘텐츠를 빌드할 때 정적인 페이지로 미리 만들어놓고 보여줌. SEO에 유리함. * ISR: SSG와 비슷한데 데이터의 변경사항에 대응할 수 있음.

# History 위에 간단 요약은 적어놓았지만 간단한 역사 정도는 알고 있으면 좋을 것 같아서 작성하는 부분.
## Web1.0 * 인터넷이 보급된 초기 버전으로 공급자들이 자신이 알고있는 정보 또는 콘텐츠를 독자들에게 공유하기 위해 웹 페이지를 만들었다. 하지만 독자들은 단순히 이 정보를 읽기만 할 뿐 **나무위키**처럼 잘못된 정보가 있을 때 누구나 수정할 수 있는 구조가 아니었다. 즉, `읽기 전용`에 대한 데이터가 정적인 웹 페이지만 만들 수 있었다. * 이 때 위에서 설명한 **SSG 기법**이 사용되었다.
## Web2.0 * Web1.0이 **읽기 전용**이었다면 드디어 독자들이 특정 콘텐츠들에 대한 `참여/기여를 할 수 있는 형태`가 되었다. 즉, 위에서 예시로 들었던 **나무위키**처럼 독자들이 잘못된 정보에 대해 "이 정보는 잘못되었으니 내가 수정하겠다."가 가능해진 것이다. * 여기서 더 다양한 형태의 콘텐츠로 소셜 미디어, 블로그, 채팅 등을 할 수 있게 된 것이고 이 버전에서 **CSR, SSR, ISR** 등의 개념이 나타나게 되었다.
## Web3.0 * 대망의 요즘 블록체인과 함께 핫한 주제인 Web3.0 버전이다. 아직 완전한 개념으로써 자리 잡아 현재는 이렇게 개발되고 있다의 개념이 아닌 이렇게 개발 **해야한다**라는 개념에 가깝다. * 지금까지의 Web2.0에선 독자들이 어떤 기여를 하던 어떤 참여를 하던 결국 그 관리는 콘텐츠를 제공해준 공급자가 하게 되있었다. 즉 내가 제공한 정보, 내가 했던 행동 이런 모든게 공급자 서버에 기록되고 있는 것이다. 그럼 이 공급자가 날아가버리면 어떻게 될까? 이 공급자가 악의적인 마음을 먹고 내 공급자에 제공했던 정보를 다른 곳에 유출시켜버린다면? 이런 문제들이 있다. * 결국 Web3.0의 대략적인 개념은 이런 중앙 집중형에서 벗어나 분산해서 모두가 가지고 있게 하겠다라는 것이다. 여기서 나온 개념이 **블록체인**이다.

# CSR(Client-Side Rendering) * 클라이언트측에 빈 HTML, Javascript를 내려주고 사용자가 보려고 하는 부분을 스크립트를 이용해 동적으로 렌더링하는 방식. * 리액트를 처음 배울 때 CRA를 통해 프로젝트를 생성하면 아래의 div 태그를 본 적이 있을 것이다. 거창하게 DOM이라는 명칭을 쓰지만 결국 그냥 저런 빈거 하나 만들어놓고 스크립트로 계속 콘텐츠를 얹겠다는 얘기다. ```html ...

... ```
## 장점 * 서버의 부하가 적다. * 필요한 콘텐츠만 부분적으로 렌더링하기 때문에 페이지 전환이 부드럽다. * 초기에 이미 필요한 스크립트를 다 내려받은 상태이므로 페이지 이동이 빠르다.
## 단점 * 클라이언트 측에서 렌더링하기 때문에 사용자의 기기 성능에 대한 의존도가 높다. (똥컴이면 느리다는 얘기다.) * 클라이언트에 빈 HTML을 내려주기 때문에 SEO에 취약하다. * 모든 페이지를 동적으로 그리기 위한 스크립트를 내려받기 때문에 초기 로딩이 길다.
## 어떤 종류를 개발할 때 좋을까? * 굳이 검색엔진에 잡힐 필요가 없는 경우 * 관리자 백오피스 사이트 * 동적 콘텐츠를 많이 다뤄야하는 사이트 (페이스북같은 소셜미디어 등)

# SSR(Server-Side Rendering) * 서버에서 사용자가 보려고하는 페이지에 대헤 렌더링한 HTML을 내려주는 방식.
## 장점 * 서버에서 다 그려서 내려주기 때문에 클라이언트 측의 부하가 적다. * 서버에서 완성된 페이지를 내려주기 때문에 웹 크롤링이 쉬워 SEO에 유리하다. * 클라이언트가 요청한 페이지에 대한 요청을 그때그때 HTML로 내려주기 때문에 초기 로딩이 빠르다.
## 단점 * 서버에서 다 그려서 내려주기 때문에 서버의 부하가 있을 수 있다. * 페이지를 HTML로 다 그려서 내려주기 때문에 페이지 이동시마다 깜빡임이 발생할 수 있다. * 페이지를 HTML로 다 그려서 내려주기 때문에 페이지 이동이 느리다.
## 어떤 종류를 개발할 때 좋을까? * 반드시 검색엔진에 잡혀야 하는 경우 * 콘텐츠를 보는 사용자 사이트 * 정적 콘텐츠를 많이 다뤄야하는 사이트 (블로그, 포탈사이트, 쇼핑몰 등)

# SSG(Static Site Generation) * 모든 URL에 대한 콘텐츠를 빌드할 때 정적인 페이지로 미리 렌더링하는 방식.
## 장점 * 서버에서 모든 데이터를 적용한 정적인 페이지로 완성된 상태로 내려주기 때문에 웹 크롤링이 쉬워 SEO에 유리하다. * 이미 모든 콘텐츠가 적용된 정적인 페이지로 만든 상태로 내려주기 때문에 초기 로딩이 빠르다.
## 단점 * 필요한 데이터가 이미 모두 적용된 상태로 빌드되어 내려진 정적 페이지이므로 데이터가 동적으로 바뀔 수 없다. (즉, 어떤 상품을 데이터로 추가했을 때 그 상품에 대한 페이지를 정적 페이지로 미리 렌더링 해야한다는 말이다.)

# ISR(Incremental Static Regeneration) * SSG와 비슷하게 모든 URL에 대한 콘텐츠를 빌드할 때 정적인 페이지로 미리 렌더링하지만 콘텐츠의 데이터의 변경사항을 적용할 수 있는 방식. * 장단점은 SSG와 거의 동일하다. SSG에서 추가로 데이터의 변경이 있을 때 서버에서 페이지를 재생성해서 내려주므로 데이터의 변경에 대응할 수 있다는 이점이 추가된다.

# Reference * [https://www.simplilearn.com/what-is-web-1-0-web-2-0-and-web-3-0-with-their-difference-article](https://www.simplilearn.com/what-is-web-1-0-web-2-0-and-web-3-0-with-their-difference-article) * [https://teawon.github.io/cs/csr-ssr/#1-%EA%B0%9C%EC%9A%94](https://teawon.github.io/cs/csr-ssr/#1-%EA%B0%9C%EC%9A%94) * [https://story.pxd.co.kr/1662](https://story.pxd.co.kr/1662) * [https://dante6327.tistory.com/23](https://dante6327.tistory.com/23) * [https://yong-nyong.tistory.com/86](https://yong-nyong.tistory.com/86)

댓글