25장 성능 예산을 시안 단계에서 정한다
빠른 사이트는 개발팀이 나중에 압축해서 만드는 것이 아니다. Hero에 어떤 asset을 얼마나 크게 쓰는지, font를 몇 벌 쓰는지, 첫 화면에 component를 몇 개 놓는지가 이미 성능 결정이다.
Core Web Vitals의 “좋음” 기준은 75번째 percentile에서 LCP 2.5초 이하, INP 200ms 이하, CLS 0.1 이하다. Lab score 한 번과 실제 field data는 다르다. 출시 전 lab test로 문제를 막고, 출시 뒤 실제 사용자 data를 device·connection·page별로 본다.
Onda의 예산 예시는 다음과 같다. 팀과 audience에 맞게 수치를 조정하되 예산 자체를 없애지 않는다.
| 항목 | 초기 예산 | 설계 선택 |
|---|---|---|
| 첫 document + critical CSS | 80KB gzip | framework 없이 작은 page |
| hero image | 250KB 전후 | 적정 dimension·modern format·quality 비교 |
| 첫 화면 전체 image | 400KB | gallery lazy loading |
| JavaScript | 60KB gzip | 예약 interaction만 hydrate |
| web font | 0–100KB | system stack 우선, subset 검토 |
| 제3자 script | 1개 이하 | conversion 가치와 비용 동시 기록 |
예제 PNG는 원본 생성 asset과 출판 재현성을 보존하기 위해 포함했다. 실제 production에서는 화면에 필요한 크기의 AVIF/WebP 변형, srcset, sizes, cache header를 만든다. <img width height>로 aspect ratio를 예약해 CLS를 줄인다. LCP 후보인 hero는 lazy load하지 않고, below-the-fold image만 lazy load한다.
<img
src="onda-hero-1280.webp"
srcset="onda-hero-768.webp 768w, onda-hero-1280.webp 1280w"
sizes="(max-width: 760px) 100vw, 58vw"
width="1536" height="864"
alt="늦은 오후 도예 작업실에서 작은 그릇을 다듬는 손">
INP가 나쁘면 animation만 의심하지 않는다. 긴 event handler, 큰 hydration, synchronous storage, tag manager를 performance trace로 찾는다. CLS는 dimension 없는 image·광고, 늦게 바뀌는 font, DOM 위쪽에 삽입되는 banner를 본다. AI에게 score만 주지 말고 trace의 long task, LCP element, 요청 waterfall을 제공한다.