0. 들어가기 전에 개념정리
Rendering?
렌더링은 브라우저 화면에 웹 페이지를 그리는 것.
유저가 브라우저를 통해 서버에 요청을 보내고, 서버는 이에 응답으로 HTML, CSS, JavaScript를 보내줍니다. 브라우저는 이를 해석하여 웹 페이지를 그립니다.
웹 브라우저 Rendering 절차
브라우저가 화면에 그리는 과정CRP(Critical Rendering Path)
Render Tree = DOM Tree + CSSOM Tree
Render Tree -> Layout(ReFlow) -> Paint(RePaint)
Rendering 방식(SSG, SSR, CSR)
웹 애플리케이션에서 HTML 콘텐츠를 생성하고 클라이언트에 전달하는 방법 HTML과 데이터의 생성 위치 및 시점에 따라 구분
- SSG(Static Site Generation) : 정적 사이트 생성 방식
- 시점
빌드타임에 HTML을 생성.
즉, 배포 전에 미리 HTMl을 생성하여 정적 파일로 저장하고, 이를 요청 시 그대로 클라이언트에 전달.- 특징
정적 파일이므로 빠르고 안정적. SEO에 유리함. 데이터 변경 시 재배포 필요
SSR(Server-Side Rendering) : 서버 측 렌더링 방식
- 시점
요청 시점(Runtime)에 서버가 HTML을 동적으로 생성. 서버에서 데이터를 가져와 html을 렌더링한 후 클라이언트에 전달.- 특징
초기 로드 시 완성된 HTML이 제공되므로 SEO에 유리.
동적인 데이터 처리 가능.
서버 부하가 클 수 있음(요청마다 HTML 생성)
- CSR(Client-Side Rendering) : 클라이언트 측 렌더링 방식
- 시점
클라이언트 측에서 렌더링.
서버에서 빈 HTML(혹은 최소한의 HTML)과 JavaScript를 전달하고, JavaScript가 브라우저에서 실행되어 콘텐츠를 렌더링- 특징
서버 부하가 낮고 동적인 경험 제공 가능.
초기 로딩이 느리며, SEO가 불리(JS 실행 후 콘텐츠 렌더링)
1. Rendering Pattern
웹 애플리케이션이 브라우저에 어떻게 콘텐츠를 렌더링하고 사용자에게 제공하는지를 설명하는 패턴이나 접근 방식을 의미합니다.
1.1. static websites
정적 웹사이트는 서버에서 이미 만들어진 HTML 파일을 그대로 전달하는 방식입니다
- 정적 웹 사이트(static websites)는 HTML, CSS, JavaScript 파일이 미리 생성되어 서버에 배포된 형태.
요청시 미리 만들어진 정적 파일을 그대로 전달. - 장점
서버가 가지고 있는 정적 웹 페이지를 반환만 하기 때문에 매우 빠름.
구글과 같은 검색엔진 최적화(SEO)에 유리
웹 크롤러가 웹페이지를 수집할 수 있음
1.2. MPA = SSR
페이지마다 새로 HTML을 요청하고 화면을 다시 그리는 방식으로 작동하는 전통적인 웹 방식입니다.
- 다중 페이지 애플리케이션(Multi-Page Application)
각 페이지 요청 시 서버가 HTML을 동적으로 생성하여 클라이언트에 전달하는 전통적인 방식
새 페이지 요청마다 전체 페이지가 로드됨. - 특징
SEO에 유리하지만 서버에 부하가 클 수 있음.
페이지 간 전환 시 새로고침 발생.
1.3. SPA = CSR
초기 로딩 시 전체 앱을 불러오고, 이후에는 필요한 데이터만 받아서 업데이트하는 방식입니다.
- 단일 페이지 애플리케이션(Single-Page Application)
초기 요청 시 최소한의 HTML과 JavaScript를 서버에서 받아오고, 이후 브라우저에서 JavaScript로 UI를 동적으로 생성.
페이지 전환은 브라우저에서 처리되어 빠르고 매끄러운 사용자 경험 제공. - 특징
서버 요청 최소화, SEO가 어려움(초기 HTML에 콘텐츠 없음)
초기 로딩 시간이 느릴 수 있음(Bundled JS크키가 큼)
1.4. SSR with Hydration = MPA + SPA
서버에서 초기 HTML을 생성하고, 클라이언트에서 JavaScript로 동작을 활성화하는 방식입니다.
- 서버에서 초기 HTML을 생성(SSR)하여 클라이언트로 전달한 후, 브라우저에서 JavaScript가 이를 "하이드레이션(hydration)"하여 SPA처럼 동작.
즉, 초기 로딩은 MPA처럼 동작하고 이후 클라이언트 측에서 SPA의 동적인 경험 제공. - 특징
SEO에 유리(SSR), 동적인 사용자 경험 제공(SPA)
서버와 클라이언트 모두 부담.
하이드레이션이란?
Hydration 은 SSG, SSR 장점 위에 CSR 장점을 얹기 위한 방법이다
1.5. SSG with Hydration
정적 웹사이트(SSG)처럼 HTML을 미리 만들어 저장해두고, 클라이언트에서 JavaScript로 동적 기능을 추가하는 방식입니다.
- 빌드 시점에 미리 HTML 파일을 생성(SSG)하여 배포하고, 클라이언트에서 JavaScript를 통해 하이드레이션(hydration)하여 동적인 SPA처럼 동작.
- 특징
SSG의 빠르고 안정적인 특성 유지.
하이드레이션으로 SPA의 동적 경험 제공.
빌드 타임에 콘텐츠를 미리 생성하므로 동적 데이터 업데이트가 어렵거나, 하이드레이션 시 데이터 동기화가 필요.
1.6. ISR(Incremental Static Regeneration)
사용자가 요청하면 CDN에서 기존에 생성된 정적 페이지를 즉시 제공하고, CDN은 서버에 비동기로 요청을 보내어 필요시 새로운 정적 페이지를 생성하거나 업데이트합니다. 이렇게 함으로써 사용자 경험을 유지하면서도 콘텐츠를 점진적으로 최신 상태로 유지할 수 있습니다.
- SSG 방식의 확장된 형태로, 특정 페이지를 미리 생성한 후 요청 시 필요하면 새 HTML을 서버에서 생성(재생성)하여 제공.
SSG의 빠른 초기 로딩 성능과 SSR의 동적 데이터 업데이트를 결합한 방식. - 특징
정적 페이지를 필요 시점에 갱신.
데이터가 오래된 경우 서버에서 동적으로 재생성.
SSG보다 유연하고 SSR보다 빠름.
1.7. 정리
| 패턴 | 초기 HTML 생성 위치 | 데이터 업데이트 | SEO | 동적 경험 |
|---|---|---|---|---|
| Static Websites | 빌드 타임 (SSG) | 재배포 필요 | 우수 | 불가 |
| MPA (SSR) | 서버 (요청 시점) | 즉시 가능 | 우수 | 불가 (페이지 새로고침) |
| SPA (CSR) | 클라이언트 | 즉시 가능 | 불리 | 매우 우수 |
| SSR with Hydration | 서버 + 클라이언트 | 즉시 가능 | 우수 | 우수 |
| SSG with Hydration | 빌드 타임 + 클라이언트 | 재배포 필요 | 우수 | 우수 |
| ISR | 빌드 타임 + 요청 시점 | 일부 가능 | 우수 | 우수 |
