까먹을게 분명하기 때문에 기록하는 블로그

CSR, SSR, SSG, ISR이 뭔지 알아보자

2024.09.10 11:51

간단 요약

  • 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이라는 명칭을 쓰지만 결국 그냥 저런 빈거 하나 만들어놓고 스크립트로 계속 콘텐츠를 얹겠다는 얘기다.
...
<div id="root">
...

장점

  • 서버의 부하가 적다.
  • 필요한 콘텐츠만 부분적으로 렌더링하기 때문에 페이지 전환이 부드럽다.
  • 초기에 이미 필요한 스크립트를 다 내려받은 상태이므로 페이지 이동이 빠르다.

단점

  • 클라이언트 측에서 렌더링하기 때문에 사용자의 기기 성능에 대한 의존도가 높다. (똥컴이면 느리다는 얘기다.)
  • 클라이언트에 빈 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