이 글에서 다루는 것
에이전트 응답을 WebSocket으로 스트리밍하면서, 메인 랜딩 페이지 LCP도 같이 손봤다. "빠르게 보여 주기"와 "첫 화면이 빨리 그려지기"는 다른 축이다.
하루 요약
| 작업 | 무엇을 하고 싶었나 | 한 일 | 결과 |
|---|---|---|---|
| 스트리밍 | WebSocket으로 부분 응답을 빠르게 표시 | 스트리밍 채널을 WebSocket으로 분리 | 토큰·청크 단위로 UI에 노출 |
| 안정 UI | 스트리밍 중 레이아웃 시프트 최소화 | 스트리밍 영역에 고정 높이 placeholder로 자리 예약 | layout shift 완화 |
| LCP | 히어로 이미지 우선 로드로 LCP 개선 | LCP 후보 이미지에 resource priority 조정 | 눈에 띄는 LCP 개선 |
1. 스트리밍 UI — 부분 응답 + 안정 레이아웃
배경지식 (개념)
- WebSocket: 서버와 양방향 연결을 유지해 메시지를 주고받는 프로토콜. HTTP 폴링보다 스트리밍에 유리하다.
어떤 상황이었나
에이전트 응답을 한 번에 받지 않고 토큰·청크 단위로 UI에 보여 줘야 했다. 그런데 스트리밍 메시지가 늘어나면서 레이아웃이 밀리는(layout shift) 현상이 있었다.
핵심 작업
- 스트리밍 채널을 WebSocket으로 분리해 토큰·청크 단위로 UI에 노출했다.
- 스트리밍 영역에는 고정 높이 placeholder로 자리를 예약해 layout shift를 완화했다. 내용이 늘어날 자리를 미리 잡는 선택이다.
교훈
- 스트리밍 UI는 고정 높이 placeholder가 필요하다 — 내용이 늘어날 자리를 미리 잡는다.
- 스트리밍 "빠름"과 LCP "첫 paint"는 별도로 최적화한다.
2. 랜딩 LCP — 리소스 우선순위
배경지식 (개념)
- LCP (Largest Contentful Paint): 뷰포트에서 가장 큰 콘텐츠가 그려지기까지의 시간. 보통 히어로 이미지·큰 텍스트 블록이 후보다.
- Resource priority:
fetchpriority, preload 등으로 어떤 리소스를 먼저 받을지 브라우저에 힌트를 주는 것.
어떤 상황이었나
메인 페이지 LCP 후보(큰 이미지)의 로딩 순서가 체감 속도에 큰 영향을 줬다.
핵심 작업
LCP 후보 이미지에 resource priority를 조정하고, largest-contentful-paint 기준으로 우선 로드했다. 눈에 띄는 LCP 개선을 얻었다.
교훈
- resource-priority 조정만으로도 LCP가 눈에 띄게 변한다 — 측정 전후를 비교할 것.
- 스트리밍 "빠름"과 LCP "첫 paint"는 별도로 최적화한다.
→ Largest Contentful Paint · Resource priority
파생 지식
다음에 볼 것
Blog 초안 작성과 Knowledge 문서 보강.