CSR vs SSR vs SSG vs Universal Rendering vs ISR
Next.js란??
리액트를 위해 만든 오픈소스 자바스크립트 웹 프레임워크로 서버사이드렌더링 server side (SSR), 정적 사이트 생성 static site generation(SSG), 중분 정적 재생성incremental static regeneration(ISR)과 같은 풀스택으로서의 기능을 제공한다
SSR이란?
서버에서 페이지를 그려 클라이언트(브라우저)로 보낸 후 화면에 표시하는 기법
SSR을 쓰는 이유
검색 엔진 최적화
- 구글, 네이버와 같은 검색 사이트에서 검색했을 때 결과가 사용자에게 많이 노출될 수 있도록 하는 최적화 기법
빠른 페이지 렌더링
- 클라이언트 사이드 렌더링과 다르게 서버에서 미리 그려서 브라우저로 보내주기 때문에 페이지를 그리는 시간 단축
Client Side Rendering(CSR)
클라이언트(브라우저)에서 웹 페이지를 렌더링
모든 로직, 데이터 가져오기, 템플릿, 라우팅은 서버가 아닌 클라이언트에서 처리
장점
- 후속 페이지 로드 시간이 더 빠르다
- 별도의 API를 호출할 필요가 없는 페이지이거나 지연 로딩 모듈이 필요하지 않다
- 스크립트가 캐싱된 경우 인터넷 없이도 해당 CSR 웹 애플리케이션을 실행할 수 있다
- 서버 호출할때마다 전체 UI를 다시 로드할 필요가 없다
단점
- 초기 페이지 로드 시간이 SSR에 비해 느리다. CSR을 사용하면 브라우저는 HTML을 컴파일 하기 전에 기본 HTML, CSS 및 모든 필수 스크립트를 로드하기 때문이다
- SEO에 친화적이지 않다. 검색 엔진 크롤러가 해당 페이지에 처음 방문하면 빈 페이지여서 이해할 수 없다. 물론 자바스크립트를 실행시킬 수 있는 구글 크롤러와 같은 검색 엔진 크롤러가 등장하고 있긴하지만, 아직 많은 검색 엔진 크롤러들이 지원되지 않는다
여기서 웹 크롤러란?
주로 Google, Bing 등의 검색 엔진에서 운영하는 일종의 봇
이들의 목적은 인터넷 전반에 걸쳐 웹 사이트의 컨텐츠를 색인화하여 해당 웹 사이트를 검색 엔진 결과에 나타내도록 하는 것
- 페이지 메타데이터의 변경을 위한 추가적인 노력이 필요하다. 한 페이지에서 다른 페이지로 변할 경우 이를 인지 시켜주기 위해 각 페이지에 대한 메타 데이터를 설정하고 클라이언트에서 렌더링 하기 위한 추가 노력이 필요함
여기서 메타 데이터란?
시간이 지남에 따라 많은 양의 데이터를 수집, 저장 및 분석할 수 있도록 일관된 방식으로 구조화된, 다른 데이터를 설명하는 데이터
- 브라우저가 페이지를 표시하기 전 HTML 및 Javascript 파일을 다운로드하고 프레임 워크를 실행하는 동안 사용자는 빈 페이지를 보게 되므로 사용자 경험(UX)가 좋지 않음
- 클라이언트의 하드웨어 및 소프트웨어에 너무 많이 의존. 사용자 기기에 따라 하위 지원되는 하드웨어 및 소프트웨어 사용자라면, 최적의 시간에 페이지를 렌더링 못하게 될 확률이 큼. 페이지의 이탈률은 페이지 로드시간에 정비례해서 이탈률이 높을수록 검색엔진 순위도 낮아짐
Server Side Rendering(SSR)
서버의 HTML로 렌더링 하는 방식.
브라우저에서 응답을 받기 전에 데이터 패칭 및 템플릿 작성이 처리되므로 클라이언트에서 위 행위에 대한 추가 왕복이 발생하지 않는다
장점
- 초기 페이지 로드시간이 빠름. 렌더링이 준비된 HTML 파일을 브라우저에서 로드하기 때문에 CSR에 비해 더 빠름
- 서버에서 페이지 로직 및 렌더링을 실행하면 많은 자바스크립트를 클라이언트에 보내지 않아도 되므로 TTI(Time to Interactive)를 빠르게 수행할 수 있다
TTI란?
웹 페이지가 사용자와 상호작용할 수 있는 상태가 되기까지 걸리는 시간을 나타내는 성능 지표
즉, 웹 페이지가 로드되고 모든 컨텐츠가 표시되어 사용자가 실제로 페이지와 상호작용할 수 있는 상태가 되는 시점
- SEO에 친화적
- 클라이언트 하드웨어 및 소프트웨어 성능에 영향을 덜 받음
단점
- 페이지 이동시마다 페이지를 생성하는데 시간이 걸림(TTFB가 느림)
- 페이지 로드가 너무 무거우면 오히려 사용자 경험을 해칠 수 있음
- 서버는 각 요청이 올때마다 HTML파일을 생성하기 때문에 CDN 수준에서의 컨텐츠 캐시가 되지 않음
CDN이란?
Content Delivery Network의 약자, 컨텐츠 전송 네트워크를 의미
전 세계적으로 분산된 서버 네트워크로 구성되어 있으며, 컨텐츠를 빠르고 안정적으로 사용자에게 전달할 수 있음
일반적으로 사용자가 웹 페이지나 애플리케이션에 접속하면, 해당 콘텐츠는 사용자와 물리적으로 가장 가까운 CND 서버로부터 제공됨
정적 콘텐츠뿐만 아니라 동적 콘텐츠, 비디오 스트리밍 등 다양한 형태의 콘텐츠를 제공할 수 있음
- 서버의 호스팅이 필요함. 클라이언트에서 자바스크립트를 이용해 렌더링하는 CSR에 비해 서버사이드에서 HTML파일과 안에 내용을 생성해야 하기 때문에 서버 호스팅이 필요함
서버 호스팅이란?
인터넷을 통해 웹사이트나 애플리케이션을 접속할 수 있도록 서버를 제공하는 서비스
- CSR에 비해 더 많은 개발 노력이 필요하며, SSR프레임 워크를 사용한다면 추가적인 러닝 커브에 대한 비용이 발생
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친화적
FP, FCP, TTI, TFB란?
FP(First Paint)
- 웹 페이지의 첫 번째 픽셀이 화면에 렌더링되기 시작하는 시간
- 사용자가 페이지가 로딩되고 있는지를 파악하는데 유용
FCP(First Contentful Paint)
- 웹 페이지에 첫 번째로 컨텐츠가 렌더링되어 사용자에게 표시되는 시간(텍스트, 이미지, 배경색 등 실제 컨텐츠가 화면에 표시되기 시작하는 시점)
- 사용자가 페이지의 실질적인 내용을 보기 시작하는 시점을 측정하여 페이지 로딩의 빠르기를 나타냄.
빠른 FCP는 사용자의 대기 시간을 줄여주고 페이지의 인상을 높일 수 있음
TTI(Time to Interactive)
- 웹 페이지가 사용자와 상호작용이 가능한 상태가 되는 시간. 페이지가 로딩된 후에 사용자가 입력을 받고 응답할 수 있는 상태가 될 때까지 걸리는 시간
- 사용자가 페이지와 상호작용할 수 있는 시점을 측정하여, 페이지가 완전히 사용 가능한 상태가 되는 속도. 빠른 TTI는 사용자 경험을 향상시키고 페이지의 대화형 요소에 대한 대기 시간을 최소화
TFB(Time to First Byte)
- TFB는 클라이언트가 요청한 리소스의 첫 번째 바이트를 수신하는데 걸리는 시간. 서버가 요청을 받아들이고 응답을 시작하는 시점부터 클라이언트가 첫 번째 바이트를 수신할 때 까지의 시간
- TFB는 서버 응답의 빠르기를 측정하여 웹 페이지의 로딩 시간을 결정. 빠른 TFB는 페이지 로딩 전체에 긍정적인 영향을 미치며, 서버의 성능과 네트워크 지연 시간을 개선하는데 중요
SSG 단점
모든 URL에 대해 개별 HTML 파일을 생성해야 함.
URL을 미리 예측할 수 없거나 URL을 예측할 수 없으면 적용이 어려움
SSR은 항상 SSG보다 별로??
속도는 SSG보다 느릴 수 있어도, SSR은 SSG에서 가능한 것보다 더 많은 '실시간' 데이터를 가져와 보다 완전한 요청에 대한 응답을 하는 장점이 있음
그래도 SSG에 비해 성능은 좋지 않아 반드시 필요한 경우에만 사용하는 것을 권장
Universal Rendering
SSR을 통해 빠른 FCP를 구현한 다음 클라이언트에서 rehydration 이라는 기술을 통해 다시 렌더링하는 방식
초기 로딩시엔 SSR처럼 작동하고 그 이후에는 CSR로 작동하는 방식
Next.js / Nuxt.js, angular universal 등이 이를 지원
Universal Rendering 장점
SSR을 통해 빠른 FCP를 구현하여 CSR의 단점을 개선
Universal Rendering 단점
별도의 서버가 필요, 구현 또는 구현을 위한 프레임워크 학습에 들어가는 비용이 큼
페이지가 빨리 로드되며 인터렉션이 가능한 것처럼 보이지만, 실제로 클라이언트에서 자바스크립트가 실행되고 이벤트 핸들러가 적용될 때까지 입력에 응답할 수 없어, 사용자 경험이 안좋아질 수 있음
Incremental Static Regeneration(ISR)
ISR(증분 정적 재생성)은 런타임 중에 정적 페이지를 만들거나 업데이트 할 수 있도록 해주는 SSG와 SSR의 하이브리드 솔루션
Next.js에서 제공하는 기능이기도 하며, 전체 사이트를 다시 빌드할 필요 없이 페이지 별로 정적 생성을 사용할 수 있게 해줌
ISR 동작 방식
- 사용자가 웹 페이지를 방문하면(request), 요청에 의해 페이지가 생성되지만 데이터가 오기를 기다려야하는 SSR과 달리 즉시 대체 페이지(fallback page)가 제공. 이 단계에서 대부분 placeholder 및 스캘래톤을 표시
- 데이터가 확인되면 최종 페이지가 캐시되고, 사용자는 SSG와 마찬가지로 캐시된 비전의 페이지를 받게 됨
ISR 장점
SSR과 달리 페이지가 즉시 제공되며(fallback page), 빠른 경험으로 사용자 경험도 좋아짐
ISR 단점
- 실시간 업데이트 어려움
데이터가 변경될때마다 즉시 사이트를 업데이트 하지 않고 사전에 설정된 주기에 따라 업데이트를 수행. - 캐시 관리 복잡성
변경된 데이터만 업데이트하므로, 이전에 생성된 정적 사이트 캐시와의 동기화를 관리해야함. 캐시 무효화와 관련된 복잡성을 야기함 - 성능 오버헤드
변경된 데이터를 식별하고 다시 생성하는 과정이 필요, 이로 인해 성능 오버헤드가 발생. 특히 데이터 양이 많거나 업데이트 주기가 짧은 경우 이러한 오버헤드가 커짐
성능 오버헤드란?
시스템이나 프로그램이 일반적으로 실행되는 데 필요한 추가적인 자원 또는 시간을 소비하는 현상. 이는 일반적으로 효율성을 감소시키고 전체적인 성능을 저하시키는 결과를 초래
- 구현 및 유지 관리 복잡성
데이터의 변경 여부를 식별하고 업데이트 하는 방법을 정교화게 관리해야하여, 코드의 복잡성 증가 - 동적 데이터 처리 제한
정적 사이트 생성과 동적 데이터 처리의 중간에 위치하여, 일부 동적 기능 구현하는데 제한. 특히 사용자 맞춤형 콘텐츠나 실시간 데이터를 다루는 경우 제한이 더욱 부각
