[/\/] SSG, ISR, SSR, CSR

우리가 평소에 쓰는 개발 모드는 yarn dev를 했을 때, 브라우저의 ‘개발자도구’에서 콘솔을 확인할 수 있었다.

yarn build를 하게 되면 실제 배포에서 사용되는 프로덕션 모드로 바꾸는 것이다

따라서 (특히 react)는 개발자도구에서 보던 태그나 다른 형태가 아닌 일그러진 형태가 되는 것이다.

react는 html요소가 거의 없으며 JS를 통해 화면에 그려내는 것이기 때문이다.

 

build를 하게 되면 빌드 시점에서의 로직이 프로덕션 모드로 생성된다.

 

 

SSG (Static Site Generation)

SSG는 최초 빌드 시의 상태를 캐싱해두었다가 사용자의 요청에 따라 고정된 HTML을 클라이언트에 전달하고 화면에 뿌려준다.

이미 서버 측에서 HTML을 빌드해두었기 때문에 사용자에게 정말 빠르게 보여줄 수 있는 것이다.

 

• 장점
  • TTV*가 매우 짧다.
  • SEO*에 유리하다.
  • CDN* 캐싱 가능하다.
• 단점
  • 정적인 데이터에만 사용 가능하다.
  • 사용자의 요청에 따라 서버와 통신하므로 클라이언트 사이드 렌더링보다 상호작용이 느릴 수 있다.
  • html 요소가 많다면 서버 부하가 클 수도 있다.
• 코드

import React from 'react';

function HomePage({ data }) {
  return <div>{data}</div>;
}

export async function getStaticProps() {
  const res = await fetch('https://...'); // 외부 API 호출
  const data = await res.json();

  return { props: { data } };
}

export default HomePage;

* TTV : 화면에 html 요소가 나타날 때까지의 시간(버튼은 나타나지만 동작 X) 

* SEO : 검색 엔진 최적화, 웹 페이지 검색엔진이 자료를 수집하여 상위 노출이 되게 한다.

              SSG의 경우에는  html 요소를 그대로 인식할 수 있어 유리하다.

* CDN : Content Delivery Network, 콘텐츠 전송 네트워크 또는 콘텐츠 배포 네트워크로 전 세계에 분산된 서버를 네트워크로 연결한 기술

 

 

 

ISR (Incremental Static Regeneration)

SSG처럼 초기에 빌드 된 정적인 페이지를 제공한다. 다만 개발자가 설정한 시간이 지날 때마다 새로운 HTML을 반영한다.

정해진 시간과 시간 사이에 사용자의 요청이 있을 때에는 이전 revalidate에서 생성한 페이지를 반영

=> revalidate 시간에만 새롭게 생성

 

최초 전체 사이트 빌드👉🏻캐싱👉🏻정해진 시간 마다 캐싱 데이터와 비교해서 변경된 페이지 전체를 빌드👉🏻캐싱👉🏻클라이언트 전달 👉🏻페이지 반영

 

Next는 revalidate Time을 재고 있지 않고, 사용자 요청 시 처음 생성 시간과 비교한다.

만약, 1시간이 지나도 요청이 없으면 새로운 데이터 안 가져옴 => 효율적

요청 시에는 무조건 data sourse까지 가서 가져옴(서버에 딜레이가 있다면 무조건 적용됨)

예시
10분 단위,
11시 9분 -> 기존 HTML
11tl 11분 -> 기존 HTML / 뒤에서 데이터 가져오는 중 / 새로운 데이터 갈아끼워 줌

 

• 장점
  • 정적인 페이지를 제공하므로 사용자 경험이 좋다.
  • 콘텐츠가 변경되었을 때 서버에서 페이지를 재생성하므로 최신 상태를 (그나마) 유지할 수 있다.
  • CDN 캐싱 가능하다.
• 단점
  • 동적인 콘텐츠를 다루기에 한계가 있을 수 있다.
  • 마이페이지 처럼 데이터에 의존하여 화면을 그려주는 경우 사용 불가
• 코드

import React from 'react';

function HomePage({ data }) {
  return <div>{data}</div>;
}

export async function getStaticProps() {
  const res = await fetch('https://...'); // 외부 API 호출
  const data = await res.json();

  return { 
    props: { data },
    revalidate: 60, // 1초 후에 페이지 재생성
  };
}

export default HomePage;

 

 

 

SSR (Server Side Rendering)

이름에서도 알 수 있듯이 렌더링 주체는 서버이다. 최초 빌드 시 프로덕트 모드가 생성되지만 그 상태를 캐싱해두지 않는다.

사용자에 요청에 따라 그 즉시 서버 측에서 렌더링하여 DB에게 API 요청 등을 마치고 html 파일을 전달한다.

요청마다 해당 부분만 렌더링 한 html을 클라이언트에 전달 -> 화면에 뿌려주기 때문에 최신 데이터를 확인할 수 있다.

하지만 요청마다 새로운 데이터를 받아와야 하기 때문에 TTI(요청 시 응답 시간)이 느리다.

 

즉, HTML 요소는 빠르게 보여주지만 데이터 요청에 대한 응답은 느리다.

 

• 장점
  • TTV가 빠름
  • SEO 최적화 좋음
  • 실시간 데이터 사용
  • 마이페이지처럼 데이터에 의존한 페이지 구성 가능
• 단점 
  • CDN 캐싱 불가 -> 따로 처리하면 캐싱 가능
  • 동시 요청이 많아지면 서버에 부하가 걸릴 수 있음
  • 요청할 때마다 페이지를 만들어야 함
• 코드

import React from 'react';

function HomePage({ data }) {
  return <div>{data}</div>;
}

export async function getServerSideProps() {
  const res = await fetch('https://...',  { cache: 'no-store' }); // 외부 API 호출
  const data = await res.json();

  return { props: { data } };
}

export default HomePage;

 

 

 

CSR (Client Side Rendering)

네 가지의 렌더링 방식 중 유일하게 렌더링 주체가 클라이언트이다. 쉽게 React라고 생각하면 편하다.

서버에서는 초기 HTML(index.html)과 JS(bundle.js) 파일만 제공한다.

클라이언트가 API 요청을 직접 보내서 데이터를 가져오고, JS가 화면을 동적으로 생성한다.

서버에서 직접 렌더링된 HTML을 제공하지 않으므로, 초기 화면은 빈 상태이다.

html이 없으므로 API 요청을 통해 받은 데이터로 화면을 그려주기 때문에 TTV가 길 수도 있다.

대신 이후의 페이지 전환과 데이터 요청이 빠르다. 

다만 React 컴포넌트는 동기적으로 렌더링되기 때문에 비동기 코드(async-await)는 useEffect 또는 tanstack query에서 관리해야 한다.

 

• 장점
  • (최초 한번 로드가 끝나면) 사용자와의 상호작용이 빠르고 부드럽다.
  • 서버에게 추가적인 요청을 보낼 필요가 없기 때문에, 사용자 경험이 좋다.
  • 서버 부하가 적다.
• 단점
  • 첫 페이지 로딩 시간(Time To View)이 길 수도 있다.
  • JavaScript가 로딩 되고 실행될 때까지 페이지가 비어있어 검색 엔진 최적화(SEO)에 불리하다
• 코드

import React from 'react';
import ReactDOM from 'react-dom';

function App() {
  return <h1>Hello, Client Side Rendering!</h1>;
}

// index.js
ReactDOM.render(<App />, document.getElementById('root'));

 

 

 

SSG, SSR, ISR, CRS 어떨 때 사용?

SSG - 변동이 없고 고정된 정보를 보여주는 페이지

ISR - 일정 시간마다 변동되는 내용을 포함하는 페이지

SSR - 자주 변경되어야 하는 페이지/SEO 최적화

CRS - 자주 변경되어야 하고 빠른 반응이 필요한 페이지/TTV 길 수 있음