SSR (Server-Side Rendering)

요약

• SSR?
  • 각 페이지 요청마다 서버에서 HTML을 생성하여 클라이언트에 전송하는 렌더링 방식
• 장점
  • SEO 최적화
  • 빠른 초기 로딩 속도
• 단점
  • 서버 부하 증가
  • 호스팅 비용 상승
  • 개발 복잡성 증가
  • 수화(Hydration) 과정에서 “죽은 시간” ¹ 발생 가능
• SEO가 중요한 퍼블릭 웹사이트에 적합한 방식

서버 측 렌더링(SSR)이란?

Server-Side Rendering
각 페이지 요청마다 서버에서 HTML을 생성, 클라이언트에 전송하는 렌더링 방식

SSR 단계

1. 사용자가 웹페이지에 접근
2. 서버는 완전히 렌더링된 HTML 페이지를 생성, 클라이언트에 전송
3. 클라이언트의 JavaScript가 해당 페이지를 인터랙티브하게 만드는 수화(Hydration) 과정

수화(Hydration) 과정

서버에서 렌더링된 정적 HTML에 JavaScript 이벤트 핸들러와 상태 관리를 연결하여 Interactive하게 만드는 과정

Hydration 과정의 단계

1. 서버 렌더링
   • 서버에서 완전히 렌더링된 HTML을 클라이언트에 전송
2. JavaScript 로딩
   • 클라이언트에서 JavaScript 번들을 다운로드하고 실행
3. DOM 연결
   • 기존 DOM 요소에 이벤트 핸들러와 상태를 연결
4. 상태 복원
   • 애플리케이션 상태를 클라이언트에서 복원
5. Interactive 완료
   • 사용자가 페이지와 완전히 상호작용할 수 있는 상태 도달

TTI (Time-to-Interactive)

사용자가 페이지를 보기 시작하는 시점과 실제로 상호작용할 수 있는 시점 사이의 시간

• SSR에서는 수화 과정으로 인하여 이 시간이 길어질 수 있음
• 3.8초 이하로 유지하는 것이 권장됨 ²

SSR의 장점

1. SEO 최적화

검색 엔진이 완전히 렌더링된 페이지를 수신, 콘텐츠를 쉽게 색인화할 수 있음

• Google
  • JavaScript 애플리케이션을 효과적으로 렌더링하고 인덱싱할 수 있지만, 렌더링 큐 대기 시간 존재
  • 15MB 크롤링 제한 적용, 대용량 JavaScript 번들은 완전히 처리되지 않을 수 있음
• Bing
  • 부분적 JavaScript 지원
• Yandex
  • 제한적 지원

SSR의 SEO 이점 :

• 즉시 크롤링 가능한 HTML 제공
• 메타 태그와 구조화된 데이터의 확실한 전달
• 소셜 미디어 공유 시, 정확한 프리뷰 제공

2. 성능

SSR은 초기 콘텐츠를 서버에서 전송하므로, 웹 사이트의 로딩 속도가 빨라짐

2.1. 초기 로딩 성능

• 빠른 첫 화면 표시
  • 서버에서 완전한 HTML을 전송, 즉시 콘텐츠 확인 가능
  • 이는 더 좋은 사용자 경험을 제공 → 이탈률 감소
• 네트워크 최적화
  • 초기 JavaScript 다운로드 없이도 콘텐츠 표시
• 저사양 디바이스 지원
  • 클라이언트 측 렌더링 부담 감소

2.2. Core Web Vitals

SSR은 Google의 Core Web Vitals 지표에서 우수한 성능을 보임

• LCP (Largest Contentful Paint): 2.5초 이하 달성 용이
• INP (Interaction to Next Paint): 200ms 이하 목표 달성
• CLS (Cumulative Layout Shift): 0.1 이하 유지 가능

3. 광고 서비스 호환성

• Google AdSense
  • AdSense는 크롤러를 사용, 사이트의 콘텐츠를 읽고 관련 광고를 제공하는 시스템
  • SSR을 사용하면, 크롤러가 사이트의 모든 컨텐츠를 읽고 사용자에게 더 관련성 높은 광고 제공 가능 → 클릭률과 광고 수익의 증가로 이어질 수 있음

SSR의 단점

1. 서버 부하 및 비용

• 높은 CPU/메모리 사용량
  • 매 요청마다 서버에서 렌더링 수행
• 호스팅 비용 증가
  • 서버 리소스 요구량 증가로 인한 운영비 상승
• 확장성 제약
  • 높은 트래픽 상황에서 서버 확장의 어려움

2. 개발 복잡성

• 서버/클라이언트 코드 동기화
  • 양쪽 환경에서 동작하는 코드 작성 필요
• 상태 관리 복잡성
  • 서버 상태와 클라이언트 상태의 일치성 유지
• 디버깅 어려움
  • 서버와 클라이언트 환경의 차이로 인한 문제 해결 복잡

3. UX 이슈

• 인터랙션 지연
  • 수화(Hydration) 과정 완료까지 일부 기능 사용 불가
• “죽은 시간”
  • 페이지가 보이지만 클릭이나 입력이 반응하지 않는 구간 존재
• 불일치 오류
  • 서버와 클라이언트 렌더링 결과가 다를 경우 발생하는 hydration mismatch

SSR이 적합한 경우

• SEO가 중요한 사이트
  • 블로그, 뉴스 사이트, 제품 페이지, 마케팅 랜딩페이지
• 초기 로딩 속도 우선
  • 사용자 유입이 중요한 퍼블릭 웹사이트
• 다양한 디바이스 지원
  • 저사양 디바이스나 느린 네트워크 환경 고려 필요
• 소셜 미디어 공유

  • 정확한 메타데이터와 프리뷰가 중요한 콘텐츠

최적화 전략

1. 성능 최적화

• 코드 스플리팅
  • 필요한 코드만 로드하여 번들 크기 최소화
• 캐싱 전략
  • 서버 렌더링 결과를 적절히 캐시하여 부하 감소
• CDN 활용
  • 정적 자산을 CDN으로 분산 처리

2. 개발 최적화

• 동형(Isomorphic) 코드
  • 서버와 클라이언트에서 동일하게 작동하는 코드 작성
• 환경 분리
  • 서버 전용 코드와 클라이언트 전용 코드의 명확한 구분
• 테스트 전략
  • 서버와 클라이언트 환경 모두에서의 테스트 수행

Footnotes

1. 사용자가 페이지를 볼 수는 있지만 상호작용할 수 없는 시간 ↩

2. Lighthouse에서 TTI 점수를 결정하는 방법 ↩