피드로 돌아가기
Dev.toFrontend
원문 읽기
TTFB 1,400ms를 200ms대로 단축한 Streaming SSR 도입 전략
Your Page Is Only as Fast as Your Slowest API: The Case for Streaming SSR
AI 요약
Context
전통적 SSR의 Promise.all 패턴으로 인한 Short-board effect 발생. 모든 API 응답이 완료될 때까지 HTML 전송이 차단되어 가장 느린 API의 응답 시간이 곧 페이지의 TTFB와 FCP가 되는 구조적 한계 노출.
Technical Solution
- All-or-nothing 렌더링 방식을 탈피한 데이터 전송 구조 설계
- Shell 및 Fast Data를 우선 Flush 하여 브라우저의 즉각적인 HTML 파싱 유도
- Slow Data를 Suspense fallback과 연동하여 응답 바디에 Chunk 단위로 스트리밍 전송
- Client-side fetching의 Waterfall 및 SEO 손실 문제를 서버 레벨의 스트리밍으로 해결
- Caching이 불가능한 실시간 및 개인화 데이터에 대해 Streaming SSR을 적용하는 상호 보완적 전략 채택
- Loader 내 Slow API를 defer() 처리하여 Promise 형태로 전달하는 비동기 렌더링 파이프라인 구축
실천 포인트
1. Loader 내 모든 API의 p95 지표를 분석하여 200ms 초과 대상 식별
2. 식별된 Slow API를 await 대상에서 제외하고 defer() 또는 Promise 형태로 전환
3. UI 단에서 해당 데이터를 사용하는 컴포넌트를 Suspense 및 Await 경계로 감싸고 적절한 Fallback UI 설계
4. TTFB와 FCP 지표를 측정하여 최저 응답 시간으로 수렴하는지 검증