CSR (Client Side Rendering) vs. SSR (Server Side Rendering)
| 비교 항목 | Client Side Rendering (CSR) | Server Side Rendering (SSR) |
|---|---|---|
| 렌더링 방식 | 브라우저에서 JavaScript를 실행하여 콘텐츠를 렌더링 | 서버에서 HTML을 생성하여 클라이언트에 전달 |
| 초기 로딩 시간 | 상대적으로 긺 (JavaScript 번들을 모두 다운로드하고 실행해야 함) | 상대적으로 빠름 (이미 렌더링된 HTML을 받음) |
| 초기 컨텐츠 표시 | 빈 페이지 후 로딩 | 즉시 컨텐츠 표시 |
| 서버 부하 | 낮음 (정적 파일만 제공) | 높음 (매 요청마다 HTML 생성) |
| SEO 친화성 | 낮음 (JavaScript 실행 전까지 빈 HTML) | 높음 (완성된 HTML이 검색 엔진에 제공) |
| 상호작용성 | 높음 | 상대적으로 낮음 |
| 후속 페이지 로딩 | 빠름 | 각 요청마다 서버 처리 필요 |
| Time to First Paint (TFP) | 느림 | 빠름 |
| Time to Interactive (TTI) | JavaScript 로드 후 빠름 | JavaScript 로드 필요시 추가 시간 소요 |
| 메모리 사용량 | 클라이언트 측 높음 | 서버 측 높음 |
| 사용자 경험 | 초기 로딩 후 빠른 페이지 전환 | 페이지 전환마다 서버 요청 필요 |
| 캐싱 전략 | JavaScript 파일과 정적 자원 캐싱 용이 | 동적 HTML 캐싱이 복잡할 수 있음 |
| 개발 복잡도 | 상대적으로 단순 (단일 JavaScript 애플리케이션) | 상대적으로 복잡 (서버와 클라이언트 로직 모두 관리) |
| 보안 | 중요 로직이 클라이언트에 노출될 수 있음 | 중요 로직을 서버에서 처리하여 안전 |
| 오프라인 기능 | 구현 용이 | 제한적 |
| 데이터 업데이트 | 실시간 업데이트 용이 | 페이지 새로고침 필요 |
| 대역폭 사용 | 초기에 높음, 이후 낮음 | 지속적으로 중간 수준 |
| 서버 인프라 요구사항 | 낮음 (정적 호스팅 가능) | 높음 (동적 서버 필요) |
| 리소스 사용 | 클라이언트 리소스 많이 사용 | 서버 리소스 많이 사용 |
| 데이터 업데이트 | 실시간 업데이트 용이 | 페이지 새로고침 필요할 수 있음 |
| 적합한 사용 사례 | 대시보드, SPA, 관리자 패널 | 블로그, 뉴스 사이트, 전자상거래 |
| 프레임워크 예시 | React, Vue, Angular | Next.js, Nuxt.js, Angular Universal |
| 유지보수성 | 프론트엔드 중심 유지보수 | 프론트엔드와 백엔드 모두 유지보수 필요 |
이 두 방식은 각각의 장단점이 있으며, 최근에는 이들의 장점을 결합한 하이브리드 렌더링 방식(예: Next.js의 정적 생성과 서버 사이드 렌더링 조합)이 많이 사용되고 있다.
프로젝트의 요구사항과 특성에 따라 적절한 렌더링 방식을 선택하는 것이 중요하다.