CSR vs SSR vs SSG

Client Side Rendering (CSR)

클라이언트(브라우저)에서 웹 페이지를 렌더링하는 것이다. 모든 로직, 데이터 가져오기, 템플릿, 라우팅은 서버가 아닌 모두 클리이언트에서 처리된다.

CSR의 경우 자바스크립트 번들의 크기의 영향을 많이 받기 때문에 적극적인 코드 분할(code splitting)을 고려해야 하며, "필요한 것만 필요할 때만 제공"해야 한다.

CSR 동작 방식

일반적으로 아래와 같이 동작한다.

사용자가 웹 페이지를 방문하면(request), 브라우저는 최소한의 HTML 파일을 다운로드(response) 한다. 이 HTML 파일은 script, meta, link 등의 태그를 포함하며, 빈 컨텐츠의 index.html 파일이라고 보면 된다.
브라우저는 index.html에 있는 자바스크립트 번들 파일을 다운로드한 다음 AJAX를 통해 API 요청을 수행하여 동적 컨텐츠를 가져오고 파싱하여 최종 컨텐츠를 렌더링한다.
사용자가 페이지를 이동할 경우, 서버에 추가 HTML파일을 요청하지 않고 이미 받은 자바스크립트를 이용하여 렌더링 한다.

CSR	내용
장점	- 후속 페이지 로드 시간이 더 빠르다. CSR을 위해 이미 모든 지원 스크립트가 사전에 로드되었기 때문에 CSR의 로드 시간이 줄어든다. - 이미 스크립트가 캐싱된 경우 인터넷 없이도 해당 CSR 웹 애플리케이션을 실행할 수 있다. - CSR은 서버를 호출할 때마다 전체 UI를 다시 로드할 필요가 없다.
단점	- 초기 페이지 로드 시간이 SSR에 비해 느리다. CSR을 사용하면 브라우저는 브라우저에서 사용 가능한 컨텐츠로 HTML을 컴파일하기 전에 기본 HTML, CSS 및 모든 필수 스크립트를 로드하기 때문이다. - SEO에 친화적이지 않다. 검색 엔진 크롤러가 해당 페이지에 처음 방문했을때는 빈 페이지이기 때문에 이해할 수가 없다. - 페이지 메타데이터의 변경을 위한 추가적인 노력이 필요하다.

CSR

내용

장점

- 후속 페이지 로드 시간이 더 빠르다. CSR을 위해 이미 모든 지원 스크립트가 사전에 로드되었기 때문에 CSR의 로드 시간이 줄어든다.
- 이미 스크립트가 캐싱된 경우 인터넷 없이도 해당 CSR 웹 애플리케이션을 실행할 수 있다.
- CSR은 서버를 호출할 때마다 전체 UI를 다시 로드할 필요가 없다.

단점

- 초기 페이지 로드 시간이 SSR에 비해 느리다. CSR을 사용하면 브라우저는 브라우저에서 사용 가능한 컨텐츠로 HTML을 컴파일하기 전에 기본 HTML, CSS 및 모든 필수 스크립트를 로드하기 때문이다.
- SEO에 친화적이지 않다. 검색 엔진 크롤러가 해당 페이지에 처음 방문했을때는 빈 페이지이기 때문에 이해할 수가 없다.
- 페이지 메타데이터의 변경을 위한 추가적인 노력이 필요하다.

✨SEO : search engine optimization - 검색 엔진 최적화는 검색 엔진으로부터 웹사이트나 웹페이지에 대한 웹사이트 트래픽의 품질과 양을 개선하는 과정이다.

Server Side Rendering (SSR)

클라이언트측 또는 유니버셜 앱을 서버의 HTML로 렌더링하는 방식이다. 이렇게 하면 브라우저에서 응답을 받기 전에 데이터 패칭 및 템플릿 작성이 처리되므로 클라이언트에서 위 행위에 대 추가 왕복이 발생하지 않는다.

SSR 동작 방식

일반적으로 아래와 같이 동작한다.

사용자가 웹 페이지를 방문하면(request), 서버는 리소스를 확인하고 페이지 내에 있는 서버측 스크립트를 실행 후 HTML 컨텐츠를 컴파일 및 준비한다.
컴파일된 HTML은 추가 렌더링 및 표시를 위해 클라이언트 브라우저로 전송된다(response).
브라우저는 HTML을 다운로드하고 최종 사용자가 사이트를 볼 수 있도록 한다.
브라우저는 자바스크립트를 다운로드하고 실행하면서 페이지를 대화형(interactive)으로 만든다.
사용자가 페이지를 이동할 경우, 위 동작을 반복한다.

SSR	내용
장점	-초기 페이지 로드시간이 빠르다(FP 및 FCP가 빠르다). 렌더링이 준비된 HTML 파일을 브라우저에서 로드하기 때문에 CSR에 비해 더 빠르다. -서버에서 페이지 로직 및 렌더링을 실행하면 많은 자바스크립트를 클라이언트에 보내지 않아도 되므로 TTI(Time to Interactive)를 빠르게 수행할 수 있다. - SEO에 친화적이다. 이미 다 만들어진 페이지를 검색엔진 크롤러가 요청에 대한 응답으로 받기 때문이다.
단점	-페이지 이동시마다 서버에서 페이지를 생성하는데 시간이 걸리기 때문에 TTFB(Time to First Byte)가 느리다. -페이지 로드가 너무 무겁다면, 오히리 사용자 경험을 개선하는게 아니라 해칠 수 있다. 초기 페이지 로드시 데이터가 많이 필요한 대시 보드가 예가 될 수 있다. -서버는 항상 각 요청이 올때마다 HTML파일을 생성하기 때문에 CDN 수준에서의 컨텐츠 캐시가 되지 않는다. -CSR에 비해 서버 사이드에서 HTML파일과 안에 내용을 생성해야 하기 때문에 서버 호스팅이 필요하다.

SSR

내용

장점

-초기 페이지 로드시간이 빠르다(FP 및 FCP가 빠르다). 렌더링이 준비된 HTML 파일을 브라우저에서 로드하기 때문에 CSR에 비해 더 빠르다.
-서버에서 페이지 로직 및 렌더링을 실행하면 많은 자바스크립트를 클라이언트에 보내지 않아도 되므로 TTI(Time to Interactive)를 빠르게 수행할 수 있다.
- SEO에 친화적이다. 이미 다 만들어진 페이지를 검색엔진 크롤러가 요청에 대한 응답으로 받기 때문이다.

단점

-페이지 이동시마다 서버에서 페이지를 생성하는데 시간이 걸리기 때문에 TTFB(Time to First Byte)가 느리다.
-페이지 로드가 너무 무겁다면, 오히리 사용자 경험을 개선하는게 아니라 해칠 수 있다. 초기 페이지 로드시 데이터가 많이 필요한 대시 보드가 예가 될 수 있다.
-서버는 항상 각 요청이 올때마다 HTML파일을 생성하기 때문에 CDN 수준에서의 컨텐츠 캐시가 되지 않는다.
-CSR에 비해 서버 사이드에서 HTML파일과 안에 내용을 생성해야 하기 때문에 서버 호스팅이 필요하다.

✨CDN : content distribution network - 콘텐츠 전송 네트워크는 콘텐츠를 효율적으로 전달하기 위해 여러 노드를 가진 네트워크에 데이터를 저장하여 제공하는 시스템을 말한다.

✨TTI: Time To Interactive — 페이지가 상호작용 가능하게 될 때까지의 시간 (이벤트 발생 등). 이 지표가 저조하다면 클릭을 해도 반응이 없는 상황이 발생할 가능성이 높아집니다.

✨FCP/FP: First Contentful Paint — 요청 콘텐츠(기사 본문 등)가 표시되는 시점입니다. 즉, 하얀 화면이 아닌 뭔가 보이긴 하는 시점이라는 의미입니다.

✨TTFB: Time to First Byte (첫 번째 바이트까지의 시간) — 링크를 클릭한 후 처음으로 들어오는 콘텐츠 비트 사이의 시간을 나타냅니다.

Static Site Generator(SSG)

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

Next.js에서 권장하는 렌더링 방식이기도 하다.

SSG 동작 방식

일반적으로 아래와 같이 동작한다.‌

사용자가 웹 페이지를 방문하면(request), 엣지 캐싱(edge caching)된 HTML 클라이언트로 반환해 준다.
브라우저는 HTML을 다운로드하고 최종 사용자가 사이트를 볼 수 있도록 한다.

엣지 캐싱(edge caching)이란?

최종 사용자에게 더 가까운 컨텐츠를 저장하기 위해 캐싱 서버를 사용하는 것이다. 대표적으로 CDN을 많이 사용한다.

SSG	내용
장점	- 빌드 타임에 HTML 파일이 생성되기 때문에 빠른 FP, FCP, TTI를 제공한다. 또한 매 요청마다 생성하는 것이 아니므로, SSR과 달리 일관성있게 빠른 TFB를 달성할 수 있다. - 이미 생성된 HTML 파일을 받기 때문에 SEO 친화적이다.
단점	-모든 URL에 대해 개별 HTML 파일을 생성해야 한다. 따라서 URL을 미리 예측할 수 없거나 URL을 예측할 수 없으면 적용이 어렵다.

SSR은 항상 SSG보다 항상 별로인가?

속도는 SSG보다 느릴 수있다. 하지만 SSR의 장점은 SSG에서 가능한 것보다 더 많은 "실시간" 데이터를 가져와 보다 완전한 요청에 대한 응답(response)을 하는 것이다.

그렇지만 SSG에 비해 성능은 좋지 않기 때문에 반드시 필요한 경우에만 사용하는 것을권한다.

Universal Rendering

SSR을 통해 빠른 FCP를 구현한 다음 클라이언트에서 rehydration이라는 기술을 통해 다시 렌더링하는 방식이다.

쉽게 말해 초기 로딩시에는 SSR처럼 작동하고 그 이후에는 CSR로 작동하는 방식이며, Next.js, Nuxt.js, angular universal 등이 이를 지원한다.

Universal Rendering	내용
장점	-SSR을 통해 빠른 FCP를 구현하므로 CSR의 단점을 개선할 수 있다.
단점	-별도의 서버가 필요하며, 구현 또는 구현을 위한 프레임워크 학습에 들어가는 비용이 크다.

Incremental Static Regeneration (ISR)

ISR(증분 정적 재생성)은 런타임 중에 정적 페이지를 만들거나 업데이트 수 있도록 해주는 SSG과 SSR의 하이브리드 솔루션이다.

Next.js에서 제공하는 기능이기도 하며, 전체 사이트를 다시 빌드할 필요없이 페이지별로 정적 생성을 사용할 수 있게 해준다.

ISR 동작 방식

사용자가 웹 페이지를 방문하면(request), 요청에 의해 페이지가 생성되지만 데이터가 오기를 기달려야하는 SSR과 달리 즉시 대체 페이지(fallback page)가 제공된다. 이 단계에서 대부분 placeholder 및 스캘래톤을 표시한다.
데이터가 확인되면 최종 페이지가 캐시되고, 사용자는 SSG와 마찬가지로 캐시된 버전의 페이지를 받게 된다.
재검증시에도 사용자는 먼저 캐시된 버즌을 받고 업데이트된 버번을 받는다. (캐싱 전략: Stale-while-revalidate)

ISR	내용
장점	-SSR과 달리 페이지가 즉시 제공되며(fallback page), 빠른 경험으로 사용자 경험도 좋아진다.
단점	-페이지 디자인에 따라 첫번째 의미있는 페인팅을 지연시킬 수도 있다.

저작자표시 (새창열림)