티스토리 뷰
웹 렌더링 기법 종류 간단히 알아보자 (CSR, SSR, SSG, ISR 등..)
웹 렌더링 기법의 종류
- CSR (Client-Side Rendering)
- SSR (Server-Side Rendering)
- ISR (Incremental Static Regeneration)
- SSG (Static Site Generation)
- DPR (Deferred Page Rendering)
- SPR (Streaming Page Rendering)
- ESR (Edge-Side Rendering)
- RSC (React Server Components)
개념은 이해하고 넘어가면 좋다. 하지만 꼭 다 정확한 정보까지 학습할 필요는 없다.
그 자체의 개념들도 있고, 같이 사용가능한 기법들도 있다. 간단히 알아보자.
CSR (Client-Side Rendering)
초기 로딩 시 서버에서 기본적인 HTML만 먼저 제공받고, 이후 브라우저가 자바스크립트를 실행해 동적으로 페이지를 렌더링하는 방식이다.
예시
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>React CSR Example</title>
<script defer="defer" src="/static/js/bundle.js"></script> <!-- JS가 실행된 후 React가 랜더링됨 -->
</head>
<body>
<noscript>You need to enable JavaScript to run this app.</noscript>
<div id="root"></div> <!-- React가 여기에 렌더링됨 -->
</body>
</html>
서버는 기본적인 정적리소스(HTML, JS, CSS)만 제공하므로 서버가 HTML을 생성하는 부담이 적다.
초기 렌더링 이후 필요한 데이터들은 API 요청을 통해 가져오게되고 UI는 클라이언트에서 동적으로 렌더링하는 방식으로 SPA (Single Page Application)에서 주로 사용된다.
- SSR (Server-Side Rendering) 과 비교했을때, CSR은 서버가 기본적인 정적 리소스만 제공하므로 부하가 적고 SSR은 서버가 매 요청마다 HTML을 생성해서 제공해야하므로 서버 부하가 크다.
동작 예시
- 클라이언트가 서버에서 빈 HTML과 JavaScript 번들 파일을 다운로드
- React가 실행되며 API 요청을 통해 데이터를 가져옴
- 데이터를 받아 화면을 렌더링
import { useEffect, useState } from 'react';
export default function Page() {
const [data, setData] = useState(null);
useEffect(() => {
fetch('https://api.example.com/data')
.then((res) => res.json())
.then((data) => setData(data));
}, []);
if (!data) {
return <p>Loading...</p>;
}
return <div>{data.title}</div>;
}
최초 요청 시에는 빈 페이지(Loading...)가 보이고, 이후 데이터를 받아 화면을 채우게 된다.
장점
- 부드러운 사용자 경험
- HTML 파일을 먼저 다운로드 한 후에 필요한 데이터만 가져와서 화면을 구성하기에 서버에서 매번 HTML을 생성할 필요가 없다. (SPA)
- 정적 파일(CSS, JS, 이미지)만 제공하는 구조이기에 서버 부하가 적다.
- 페이지 전환이 많거나 서버 렌더링이 필요없는 경우 부드러운 사용자 경험을 제공한다.
- 빠른 페이지 이동 (SPA)
- 최초에 필요한 리소스를 로드한 후 이후에는 페이지 이동 시 새로고침 없이 동작
- React Router, Vue Router등을 사용하면 컴포넌트 단위로 업데이트 가능
- 동적 콘텐츠에 강함
- API 기반 데이터 로딩이 필요한 경우 CSR이 유리하다. (Reac Query, SWR과 같은 라이브러리를 사용하여 필요한 데이터만 가져와서 갱신 가능.)
- 정적 파일 캐싱 가능 (CDN 활용)
- 초기 번들 파일 (JS, CSS)을 CDN에 캐싱하여 빠르게 배포 가능하다.
- 브라우저가 리소스를 캐싱하면 서버 요청을 최소화하여 성능을 최적화할수 있다.
- PWA(Progressive Web App)와 결합하면 오프라인 모드에서도 동작 가능하다.
단점
- 초기 로딩 속도 지연
- HTML 파일과 정적 파일(CSS, JS, 이미지)를 다운로드 하고 실행해야 렌더링이 완료된다.
- SSR 보다 초기 화면 표시 속도가 느릴수있다.
- 보완하기 위해서는 코드 스플리팅을 통한 초기 로딩 최적화가 있다. (DPR)
- Lazy Loading으로 필요할때만 자바스크립트 실행 (DPR)
- 초기 페이로드 증가
- 클라이언트에서 모든 처리를 하기 때문에 자바스크립트 번들이 커질수 있다.
- 네트워크 속도가 느리거나 저사양 기기에서는 로딩 시간이 길어질 수 있다.
- 첫 화면 FCP, LCP 성능 저하
- 주요 콘텐츠가 자바스크립트를 실행한 후 렌더링 되므로 FCP(First Contentful Paint)와 LCP(Largest Contentful Paint)가 느려진다. - 사용자 경험(UX)에 영항을 준다.
- SEO & OG 태그 최적화 불리
- 초기 HTML 컨텐츠가 없고 자바스크립트 실행 후 렌더링 되므로 SEO에 불리하다.
- 대부분 검색엔진 크롤러는 자바스크립트를 실행하지 않거나 제한적으로 실행한다.
- OG태그가 동적으로 변경되므로 SNS 크롤러가 정보를 제대로 가져가지 못할 수 있다.
- 자바스크립트 비활성화 시 페이지 작동 불가
- 자바스크립트를 기반으로 렌더링 되므로 사용자가 자바스크립트를 비활성화 할 경우 사이드가 정상적으로 표시되지 않는다.
- 메모리 사용량
- 모든 렌더링이 클라이언트에서 이루어지므로 브라우저 메모리 사용량이 증가할 수 있다.
- SPA에서는 오래 사용하면 메모리 누수가 발생할 가능성이 있다.
Q. SEO 최적화 하려면?
A.
- SSR (Server-Side Rendering) 또는 SSG(Static Site Generation) 적용하는게 좋다.
- Next.js 같은 프레임워크에서 SSR/SSG를 사용하면, 검색엔진이 크롤링할 수 있도록 미리 HTML을 생성 가능하다.
- 프리렌더링 (Pre-rendering)
- puppeteer, prerender.io 같은 도구를 활용해 서버에서 자바스크립트를 실행한 후 정적 HTML을 제공한다.
- Dynamic Rendering
- 일반 사용자는 CSR을 사용하지만 검색엔진 크롤러에게는 SSR 방식의 HTML을 제공한다.
- 사용자가 브라우저 접근 시 CSR방식으로 페이지 렌더링한다. 하지만 검색엔진 접근 시 별도의 SSR 처리된 HTML을 반환한다. 이때 웹 서버또는 프록시에서 User-Agent를 확인하여 요청 주체가 일반사용자인지 검색엔진 크롤러인지를 판단한다.
- SEO 최적화된 페이지만 SSR로 작업하고 나머지 페이지는 CSR 유지한다.
SSR (Server-Side Rendering)
요청 시점에 서버에서 HTML을 미리 렌더링하여 클라이언트에 전달하는 방식이다.
요청할 때마다 서버에서 HTML을 생성한다.
사용자가 웹 페이지를 요청하게되면 서버에서 자바스크립트를 실행하여 완성된 HTML을 생성하고, 브라우저로 전송한다.
이후 브라우저에서 HTML을 렌더링 후 React가 hydration을 수행한다.
- hydration을 수행하게되면 자바스크립트를 실행하고, HTML이 먼저 표시된 후 클라이언트에서 자바스크립트가 실행되어 인터랙티브 기능이 활성화된다.
초기 로딩 속도가 빠르며 SEO에 유리하다.
Next.js는 SSR을 쉽게 구현할 수 있도록 지원한다.
장점
- SEO & OG 태그 적용에 유리하다.
- 서버에서 미리 완성된 HTML을 제공하므로 검색엔진 크롤러가 쉽게 콘텐츠를 수집할 수 있다.
- CSR 방식처럼 자바스크립트가 실행될 때까지 기다릴 필요가 없다.
- 페이스북, 트위터, 카카오톡 등에서 URL 공유 시 Open Graph (OG) 태그를 정확히 반영할 수 있다.
- 초기 로딩속도 향상 (FCP(First Contentful Paint)와 LCP(Largest Contentful Paint) 개선)
- 클라이언트가 요청하면 서버에서 HTML을 반환하므로 브라우저가 빠르게 콘텐츠를 표시할 수 있다.
- 저사양 기기나 네트워크 환경이 좋지 않은 경우에도 빠른 응답이 가능하다.
단점
- 서버 부하 증가
- 모든 요청을 서버에서 처리해야하므로 사용자가 많아질 경우 서버의 부하가 증가한다.
- CSR은 정적인 HTML을 전달받고 자바스크립트가 이후 실행되지만, SSR은 매 요청마다 HTML을 생성해야하기때문에 트래픽이 많을 경우 서버 비용이 증가할 수 있다.
- 응답 시간이 길어질 수 있다. (TTFB 증가)
- 서버에서 HTML을 생성한 후 클라이언트에 보내기 때문에 첫번째 바이트(First Byte) 응답 속도(TTFB)가 증가할 수 있다.
- 특히 데이터 베이스 요청이 많거나 복잡한 연산이 필요한 경우 응답 속도가 느려질 가능성이 높다.
- 페이지 간 이동 속도가 느릴수 있다.
- SSR에서는 페이지를 이동할 때마다 서버에서 새로운 HTML을 요청해야하므로 CSR보다 클라이언트 측 페이지 전환속도가 느리다.
- CSR은 이미 로드된 자바스크립트를 재사용하면서 상태를 유지할 수 있지만, SSR은 매번 새롭게 HTML을 받아야한다.
- 브라우저에서 자바스크립트 실행이 지연될 가능성
- SSR로 렌더링된 HTML이 먼저 표시되더라도 브라우저에서 자바스크립트가 완전히 로드될 때까지 인터랙션이 제한될 수 있다.
- hydration (클라이언트에서 이벤트 바인딩 및 추가 렌더링)이 필요하기 때문에 사용자가 조작하려고할때 반응이 늦을 수 있다.
- 구현이 복잡할 수 있다.
- 서버에서 데이터를 미리 가져와야하므로 클라이언트와 서버의 데이터 관리 로직을 분리해야한다.
- 특히 SSR 지원 프레임워크에서 사용하는 메서드등이 있을 수 있고 API 호출 방식이 달라질 수 있다.
SSG (Static Site Generation)
빌드 시점에 HTML을 미리 생성하여 정적 파일로 제공하는 렌더링 방식이다.
즉 페이지를 미리 생성하여 서버 없이도 빠르게 제공할 수 있는 방식이다.
미리 생성된 정적 HTML을 제공하기 때문에 서버 부하가 없다.
동작
- 빌드 시점에 모든 정적 HTML을 미리 생성한다.
- 생성된 HTML은 CDN등에 배포되어 사용자가 요청하면 즉시 응답한다.
- 사용자가 페이지 요청
- 서버는 동적으로 HTML을 생성하지 않고 미리 생성된 정적 HTML을 그대로 제공한다.
- API 요청 없이도 빠른 페이지 로딩 속도를 유지할 수 있다.
- 데이터 변경이 있더라도 즉시 반영되지 않는다.
- 새로운 데이터를 반영하려면 전체 사이트를 다시 빌드해야한다.
- 이 문제를 해결하기 위해 ISR(Incremental Static Regeneration)이 등장하였다.
장점
- 빠른 페이지 로딩 속도
- HTML을 미리 생성하여 정적 파일로 제공하므로 요청 시 서버에서 HTML을 새로 생성하지 않는다.
- CDN을 활용하여 전 세계 어디서나 빠르게 로드 가능하다. (ESR)
- 사용자는 즉각적인 응답을 받을 수 있어 사용자경험(UX)가 개선된다.
- SEO & OG태그 최적화
- 정적 HTML을 제공하므로 검색엔진 크롤러가 쉽게 콘텐츠를 인덱싱 할 수 있다.
- 서버 부하 감소 및 비용 절감
- HTML을 미리 생성하여 제공하므로 요청 시 서버에서 HTML을 새로 만들 필요가 없다.
- 트래픽이 많아도 서버 부하가 적고 CDN을 활용하면 더욱 부담을 줄일 수 있다. (ESR)
- 서버리스 환경에서 배포하면 서버 비용을 크게 절감할 수 있다.
- 보안성이 높다.
- 정적 HTML 파일을 제공하기 때문에 서버에서 실행되는 코드가 없다.
- 정적파일이 데이터 베이스 또는 API와의 직접적인 연동이 필요하지 않으므로 보안 위협이 적다.
- CDN과 함께 사용시 글로벌 서비스 최적화 (ESR)
- 정적 HTML파일을 CDN에 배포하면 전세계 어디서든 빠르게 응답 가능하다.
- 유지보수 및 확장성 용이
- 정적 페이지이므로 배포 후 서버 관리가 필요없다.
- 트래픽이 증가해도 정적 HTML을 제공하기에 확장성이 뛰어나다.
- 빌드 시점에 데이터가 반영되므로 페이지를 업데이트하는 로직이 단순하다.
단점
- 데이터 변경이 실시간으로 반영되지 않는다.
- 데이터 변경 될때마다 전체 사이트를 다시 빌드해야하므로 실시간 데이터 반영이 어렵다.
- 빌드시간이 길어질 수 있다.
- 페이지가 많을수록 빌드시간이 부담될 수 있다.
- 사용자별 맞춤 데이터 제공이 어렵다. (개인화 데이터 제공 어려움)
- 데이터 일관성 문제가 발생할 수 있다.
- 빌드 시 데이터를 가져와 HTML을 생성하므로 빌드 이후 API 데이터가 변경될 경우 기존 HTML과 불일치 할 수 있다. 즉, 정적 페이지와 실제 API 데이터가 다를 가능성이 있다.
- 동적인 페이지 생성이 어렵다.
ISR (Incremental Static Regeneration)
Next.js에서 제공하는 SSG(Static Site Generation)의 한계를 보완한 렌더링 방식이다.
정적 페이지의 성능을 유지하면서도 특정 주기로 데이터를 갱신할 수 있는 기능을 제공한다.
즉, 초기에는 정적 HTML을 제공하지만 특정 시간이 지나면 요청이 들어올때 최신 데이터로 페이지를 재 생성하는 방식이다.
SSG & SSR의 문제점으로 인해 ISR이 등장하게 되었다.
기존 SSG는 빌드 시점에 HTML을 생성하므로 실시간 데이터 반영이 어려웠다.
예를들어 블로그 사이트에서 새로운 글이 추가되었을때 반영하려면 전체 사이트를 다시 빌드해야했다. 이렇게 되면 대규모 사이트에서는 모든 페이지를 미리 빌드하는것이 부담된다.
기존 SSG(Server-Side Rendering)의 문제점은 모든 요청마다 서버에서 새롭게 HTML을 생성하므로 성능 부담이 큰 부분이다. 방문할 때마다 서버에서 데이터를 받아야하므로 트래픽이 많아지면 서버 부하가 증가할 수 있다.
ISR은 SSG의 정적 페이지 방식과 SSR의 동적 데이터 갱신을 결합한 방식이다.
동작
- 초기 페이지 요청
- 사용자가 특정 페이지에 최초로 접근하면 빌드 시 생성된 정적 HTML을 즉시 반환한다. (SSG와 동일하게 동작)
- 새로운 요청(추가 요청)이 발생하면 revalidate 시간을 확인한다.
- 설정한 revalidate 시간이 지나지 않았다면 기존 정적 페이지를 그대로 제공한다.
- 설정한 revalidate 시간이 지났다면 새로운 요청이 들어올때 백그라운드에서 최신 데이터를 가져와 새로운 HTML을 생성한다.
- 새로운 HTML 생성 (백그라운드 처리)
- revalidate 시간이 지나고 새로운 요청이 들어오면 Next.js가 서버에서 최신 데이터를 가져와 새로운 HTML을 생성한다.
- 이 과정은 백그라운드에서 실행되므로 기존 사용자에게는 기존 정적 페이지가 계속 제공된다.
- 새로운 HTML이 생성되면, 다음 요청부터 적용한다.
- 새로운 HTML이 생성되면 기존 HTML을 교체하고 이후 요청부터는 새로 생성된 HTML이 제공된다.
장점
- 정적 페이지 (SSG)의 속도 유지
- 최초 요청 시 빌드된 HTML을 반환하므로 로딩 속도가 빠르다.
- 데이터를 일정 주기로 갱신 가능하다.
- revalidate 설정을 통해 필요한때만 새로운 데이터를 가져와 갱신할 수 있다.
- SEO & OG 태그 최적화
- 정적페이지를 제공하므로 검색엔진 크롤러가 쉽게 인덱싱 가능하다.
- 서버 부하 감소
- SSR처럼 매 요청마가 서버에서 HTML을 생성하지 않으므로 서버 부하를 줄일 수 있다.
- 전체 사이트 빌드 없이 개별 페이지만 업데이트 가능
- 새로운 데이터가 들어와도 전체 사이트를 다시 빌드할 필요 없다.
단점
- 최신 데이터가 즉시 반영되지 않는다.
- revalidate 시간이 지나기 전까지는 이전 데이터를 제공하므로 실시간 데이터가 필요한 경우 부적절하다.
- 백그라운드 업데이트 동안 오래된 데이터를 제공
- 새로운 HTML을 생성하는 동안 첫번째 요청자는 여전히 이전 데이터를 보게된다.
- 첫번째 요청이 느릴 수 있다.
- revalidate 후 첫번째 요청시 새로운 HTML을 생성하는 동안 응답 시간이 증가할 수 있다.
- 복잡한 동적 페이지에는 적합하지 않는다.
- 사용자마다 다른 데이터를 제공해야하는 경우 적합하지 않다.
Q. 단점 3번에서 첫번째 요청이 느릴수도 있다고 했는데, 백그라운데에서 미리 HTML을 생성해두는거 아닌가? 왜 다시 생성하는거지?
A. ISR에서는 백그라운드에서 새로운 HTML을 생성하지만 첫번째 요청자가 기다려야하는 경우도 발생할 수 있다.
이 동작 방식은 Next.js의 ISR 캐시 정책과 관련있다.
ISR에서 revalidate 시간이 지나면 새로운 요청이 들어올때 백그라운드에서 새로운 HTML을 생성한다.
하지만 새로운 HTML이 완전히 생성될 때까지 첫번째 요청자는 이전 HTML을 보게 되는 것이 아니라 새로운 HTML을 기다려야 할 수도 있다.
ISR의 두가지 HTML 갱신 방식이 있는데,
- 백그라운드 재생성 (기본적인 ISR 방식)
- revalidate 시간이 지나면 다음 요청이 들어올때 백그라운드에서 새로운 HTML을 생성한다.
- 첫번째 요청자는 이전 HTML을 보고 새로운 HTML이 생성된 후부터 이후 요청자들이 업데이트된 HTML을 받을수있다.
해당 방식에서는 기존 HTML을 보게되므로 사용자는 이전 데이터를 볼 뿐 느리다고 체감하지 않는다.
- 요청과 동시에 새 HTML 생성 (Blocking Mode)
- revalidate 시간이 지나면 첫번째 요청자가 새로운 HTML이 생성될 때까지 기다려아한다.
- 이후 요청부터는 새로운 HTML이 제공된다.
첫번째 요청자도 최신 데이터를 받는 장점이 있으나 새로운 HTML이 생성되기까지 기다려야하므로 응답시간이 길어질 수 있다.
Next.js는 기본적으로 백그라운드에서 새 HTML을 생성하는 방식을 사용하며 Blocking Mode를 명시적으로 설정하는 방법은 없다.
하지만 백그라운드에서 HTML을 생성하는 도중 오류가 발생하거나 캐시가 만료되었는데 새로운 HTML이 생성되지 않은 경우, 그리고 페이지가 처음 요청되었고 정적파일이 아직 존재하는 경우(동적으로 생성되는 페이지인 경우 빌드 시점 일부 페이지만 미리 생성) 등의 특정 조건인 경우에 Blocking Mode로 동작할 수 있다.
DPR (Deferred Page Rendering)
웹 페이지의 렌더링을 지연(defer)하여 최적화 하는 기술이다.
초기 로딩 속도 개선을 위해 사용자가 실제로 필요로하는 컨텐츠만 우선적으로 렌더링하고 나머지는 나중에 처리하는 방식이다. (= 불필요한 렌더링을 최소화하여 성능을 최적화 하는 기법)
나머지 비 필수 콘텐츠는 일정 조건(ex: 스크롤이나 사용자 입력으로 인해 노출되는..)에서 동적으로 로드된다.
Next.js를 사용하면 DPR 개념이 이미 여러곳에서 활용된다. (Lazy Loading, Code Splitting, Dynamic Import 등)
기법
- 지연 렌더링 (Lazy Rendering)
- 사용자가 볼 가능성이 높은 콘텐츠만 먼저 렌더링하고 나머지는 특정 조건에서 렌더링한다.
- 예시: 무한스크롤
- 점진적 렌더링 (Progressive Rendering)
- 페이지의 중요한 요소(기본 레이아웃 이나 텍스트)들을 먼저 렌더링 한 후, 추가적인 요소 (이미지나 복잡한 UI)를 나중에 렌더링한다.
- 스켈레톤 UI (Skeleton Loading)
- 초기 로딩 단계에서 콘텐츠의 대략적인 형태(스켈레톤 UI)를 먼저 보여주고, 실제 콘텐츠가 로드되면 대체한다.
- 코드분할(Code Splitting)
- 웹팩등의 번들러를 사용하여 페이지에서 필요하지 않은 자바스크립트 파일을 지연로드한다.
장점
- 초기 로딩 속도 개선
- 핵심 콘텐츠만 우선 렌더링하고 나머지는 나중에 로드하여 사용자 경험 향상
- 초기 페이지 로드 시간이 줄어들어 LCP (Largest Contentful Paint) 성능이 개선된다.
- 서버 부하 감소 & 최적화
- SSR과 함께 적용하면 불필요한 HTML & 데이터 렌더링을 줄일 수 있다.
- 서버의 리소스 사용을 줄여 트래픽이 많은 사이트에서도 안정적인 성능 유지가 가능하다.
- 네트워크 트래픽 절감
- 필요할때만 데이터를 로드하는 방식으로 클라이언트의 불필요한 데이터 요청이 감소된다.
- 모바일 환경에서 데이터 사용량을 줄여 사용자 경험(UX)가 개선된다.
- UX 향상 (Lazy Loading + Skeleton UI)
- 느린 네트워크 환경에서도 부드러운 UI 경험을 제공한다.
- 브라우저 렌더링 성능 최적화
- 불필요한 DOM 요소를 줄여 브라우저의 Reflow & Repaint 비용을 감소한다.
- 특히 SPA에서 성능 최적화가 크다.
- 코드 스플리팅과 결합 가능
- Dynamic Import 또는 React.lazy와 결합하면 불필요한 코드 로드 자체를 방지할 수 있다.
SPR (Streaming Page Rendering)
전체 페이지를 한번에 렌더링하는 대신 페이지의 일부를 먼저 렌더링하고, 나머지는 데이터를 가져오는대로 순차적으로 렌더링하는 기법이다. (점진적 렌더링)
React 18에서 도입된 RSC(React Server Components) & Suspense Streaming을 활용하면 Next.js와 같은 프레임워크에서 효과적으로 적용할 수 있다.
- SSR과의 차이점은 SSR같은 경우 모든 데이터를 서버에서 가져온 후 한번에 HTML을 반환한다.
- SPR은 먼저 기본적인 UI를 렌더링 한 후 데이터가 준비되는 대로 추가적으로 업데이트한다.
Q. SPR: 먼저 기본적인 UI를 렌더링한 후, 데이터가 준비되는 대로 추가적으로 업데이트. 즉 기본적인 UI 를 렌더링하기 위한 HTML 먼저 반환하고 이후에 추가적으로 업데이트한다는거야? (JS실행해서?)
A. 맞다.
SPR(Streaming Page Rendering)은 기본적인 UI를 담은 HTML을 먼저 반환한 후, 추가적인 데이터를 받아오는 대로 점진적으로 UI를 업데이트하는 방식이다. 이 과정에서 자바스크립트 실행을 통해 추가적인 렌더링이 진행된다.
흐름
- 서버가 기본적인 HTML을 먼저 클라이언트로 전송한다.
- 중요한 UI요소를 포함하고 있다.
- 아직 데이터가 필요한 컴포넌트는 로딩 UI로 표시한다. (<Suspense> 내부의 Comments 컴포넌트는 아직 데이터를 불러오지 않아서 로딩을 표시)
- 클라이언트에서 HTML을 렌더링하고 자바스크립트를 실행한다.
- React 18의 Suspense Streaming이 사용되면 클라이언트에서 자바스크립트가 실행되면서 비동기 데이터를 받아오는대로 UI를 업데이트한다. (fetch() 요청)
- 데이터가 준비될때마다 UI가 업데이트됨
- fetch()등을 통해 추가 데이터를 가져오고 React의 useState, useEffect, Suspense등을 사용해 업데이트 진행한다.
ESR (Edge-Side Rendering)
에지 서버(Edge Server)에서 HTML을 렌더링하는 기법이다.
사용자의 지리적 위치와 가까운 에지 서버에서 요청을 처리하여 성능을 극대화하는 방식이다.
즉, 중앙서버가 아닌 가장 가까운 에지서버에서 HTML을 생성하여 반환한다.
일반적으로 CDN과 연계하여 동작하며 SSR(Server-Side Rendering)의 개념을 에지 컴퓨팅과 결합한 형태이다.
개념
- CDN 서버에서 HTML을 생성하여 반환한다.
- 사용자의 위치에서 가장 가까운 에지서버에서 페이지를 제공하므로 지연시간(Latency)가 감소한다. 즉, 기본적인 SSR보다 빠른 응답속도를 가진다.
- CDN을 통해 정적인 콘텐츠 뿐만 아니라 동적인 HTML도 캐싱할 수 있다.
- 전통적인 SSR과는 다르게 전역에 분산된 에지서버에서 분산 처리하기 때문에 백엔드 부하를 줄일 수 있다.
Q. esr은 결국 ssr + cdn이라는거지?
A. 맞다. SSR + CDN = ESR
RSC (React Server Components)
서버에서 일부 컴포넌트를 렌더링하는 React 기술로 클라이언트에서 실행되지 않고 서버에서만 실행되는 React 컴포넌트를 의미한다.
이는 기존 SSR과 CSR의 단점을 보완하며 서능과 사용자 경험을 개선하는 역할을 한다.
기본적으로 모든 컴포넌트가 서버 컴포넌트이며 클라이언트에서 실행해야 하는 경우 'use client'를 선언해야한다.
SSR과 RSC의 차이
SSR은 요청 시마다 전체 페이지를 서버에서 HTML로 생성하여 응답하는 방식이며,
RSC는 서버에서 필요한 일부 컴포넌트만 실행하고 React 트리 형태로 클라이언트로 전달한다.
즉, 서버에서 UI를 HTML로 변환하지 않고 React 컴포넌트 트리 데이터로 전달한다. 그리고 클라이언트에서 UI를 조립하며 추가적인 Hydration을 최소화하여 성능을 최적화 한다.
| 구분 | SSR (Server-Side Rendering) | RSC (React Server Components) |
| 렌더링 시점 | 요청 시마다 서버에서 전체 페이지 렌더링 | 요청 시마다 필요한 서버 컴포넌트만 실행 |
| HTML 생성 | 서버에서 HTML을 생성해 클라이언트로 전달 | 일부 컴포넌트만 서버에서 실행 후 React 트리로 전달 |
| 클라이언트에서 실행 여부 | 클라이언트에서 Hydration(재구성) 진행 | 클라이언트에서 실행되지 않음 (HTML로 변환 X) |
| 데이터 페칭 방식 | API 요청 후 전체 HTML을 렌더링 | 서버에서 직접 DB/API 요청 후 React 트리 반환 |
클라이언트 컴포넌트 예시
// ⬇️ 'use client'를 선언해야 클라이언트에서 실행됨
"use client";
import { useState } from "react";
export default function ClientComponent() {
const [count, setCount] = useState(0);
return (
<div>
<h1>클라이언트 컴포넌트</h1>
<button onClick={() => setCount(count + 1)}>Count: {count}</button>
</div>
);
}
서버 컴포넌트 예시
// ⬇️ 'use client' 없이 자동으로 서버에서 실행됨
import { fetchData } from "@/lib/api";
export default async function ServerComponent() {
const data = await fetchData(); // 서버에서 직접 API 요청 수행
return (
<div>
<h1>서버 컴포넌트</h1>
<pre>{JSON.stringify(data, null, 2)}</pre>
</div>
);
}
개념
- 서버에서만 실행되는 React 컴포넌트
- 브라우저에서 실행되지 않고 서버에서 데이터를 가져오고 렌더링한 후 클라이언트로 전달된다.
- 네트워크 요청을 서버에서 직접 수행한다.
- 기존 CSR에서는 API 요청을 클라이언트에서 처리해야했지만, RSC를 사용하면 서버에서 직접 DB/API 요청을 수행할 수 있다.
- 클라이언트 측 자바스크립트 번들 크기 감소
- 클라이언트에서 실행되지 않으므로 자바스크립트 번들이 작아지고 로딩속도가 향상된다.
- 서버와 클라이언트의 역할 분리
- 서버에서 무거운 로직(데이터 페칭, 연산)을 처리하고 클라이언트는 UI 인터랙션에 집중할 수 있도록 설계한다.
Q. 그럼 RSC는 HTML을 실제 렌더링하는건, 클라이언트네?
A. 맞다. RSC는 서버에서 React 트리를 생성하지만, 실제 HTML 렌더링은 클라이언트에서 수행된다.
- 서버에서 React 컴포넌트 실행 → React 트리(JSON 형태)로 변환
- 클라이언트에서 해당 React 트리를 받아서 HTML을 렌더링
- 서버 컴포넌트는 클라이언트에서 실행되지 않으며, 클라이언트 측 번들 크기를 줄임
즉, SSR처럼 서버에서 HTML을 만들어 보내는 것이 아니라, 서버에서 React 트리를 만들어 클라이언트가 최종적으로 HTML을 렌더링하는 방식이다.
한줄 요약
- CSR (Client-Side Rendering) → 클라이언트에서 JavaScript로 렌더링하여 SPA(단일 페이지 애플리케이션) 구현 (React, Vue 등).
- SSR (Server-Side Rendering) → 서버에서 HTML을 생성해 초기 로딩 속도와 SEO를 개선하는 방식.
- ISR (Incremental Static Regeneration) → 빌드 타임에 정적 페이지를 생성하고, 필요할 때만 업데이트하여 빠른 렌더링을 제공.
- SSG (Static Site Generation) → 정적 HTML을 사전 생성하여 빠른 응답을 제공하는 방식으로 ISR의 이전 버전.
- DPR (Deferred Page Rendering) → 페이지 일부를 지연 로딩하여 성능 최적화 및 서버 부하 감소.
- SPR (Streaming Page Rendering) → React 18+에서 지원하는 기능으로, HTML을 스트리밍 방식으로 점진적으로 전송.
- ESR (Edge-Side Rendering) → CDN(Edge Server)에서 SSR을 수행하여 빠른 응답 속도를 제공.
- RSC (React Server Components) → 서버에서 일부 컴포넌트를 렌더링하여 클라이언트의 번들 크기를 줄이고 성능 최적화.
'React' 카테고리의 다른 글
| 별점 컴포넌트를 만들어보자 (0) | 2024.12.23 |
|---|---|
| React의 가상 DOM, Vue의 가상 DOM과 비교 (2) | 2024.12.11 |
| React 생명 주기(LifeCycle) (0) | 2021.05.01 |
| 인프런 React 강의 듣고 사이트 만들기 _ Front & back 작업 3. https 적용하기 (0) | 2021.04.05 |
| React. DOM엘리먼트에 텍스트 삽입하기 innerHTML말고 dangerouslySetInnerHTML를 사용하자 (0) | 2021.03.16 |
| 인프런 React 강의 듣고 사이트 만들기 _ Front & back 작업 2. 피셔-에이츠 셔플 (0) | 2021.03.01 |
| 인프런 React 강의 듣고 사이트 만들기 _ Front & back 작업 1. 심심이 채팅을 만들어보자! (simsimi API, 심심이 API) (0) | 2021.02.16 |
| 인프런 React 강의 듣고 사이트 만들기 _ Front 작업 10. react-slick으로 슬라이드 만들기 (AsNavFor 방식) (0) | 2021.02.13 |