스킬: 성능
UI를 빠르고 안정적으로 만드세요. 성능을 접근성 문제로 취급하십시오 — 느리거나 버벅이는 UI는 저사양 기기에서 먼저 실패합니다.
단계
workflows/performance.md읽기 (핵심 웹 바이탈 목표, 로딩 전략, 레이아웃 변경, 애니메이션 성능, 디자인 시스템 런타임 비용).- 예산 대비 진단: LCP ≤ 2.5초, INP ≤ 200ms, CLS ≤ 0.1. 중간 등급 모바일 프로필에서 측정 (느린 4G 스로틀 + 4배 CPU).
- 로딩: 접힌 부분 위를 먼저 렌더링 (SSR/서버 컴포넌트), 라우트 + 무거운 위젯별 코드 분할, 접힌 부분 아래/상호작용 이후 지연 로딩 (Astro Islands / Qwik), 중요한 글꼴 두께 하나 미리 로드, 최신 반응형 이미지.
- 레이아웃 변경 제거: 스켈레톤 크기를 최종 치수에 맞추고,
aspect-ratio(tokens/sizing.json)를 통해 미디어 공간 예약, 기존 콘텐츠 위에 콘텐츠를 삽입하지 않음. - 애니메이션:
transform/opacity만 사용,will-change는 드물게, 100–300ms (tokens/motion.json),prefers-reduced-motion존중. 낮은 INP를 위해 JS보다 CSS 상태 스타일링 선호; 트리 셰이킹/컴포넌트별 가져오기.
검증 (완료 조건)
- Lighthouse / 필드 데이터가 중간 등급 모바일에서 LCP ≤ 2.5초, INP ≤ 200ms, CLS ≤ 0.1을 충족.
- 느린 4G + 4배 CPU 스로틀 상태에서 첫 번째 상호작용이 응답성을 유지.
- 스켈레톤 + 미디어가 공간을 예약 (로드 시 CLS 0); 루프에 비합성 애니메이션 없음.