학습 목표
- 화면 성능을 측정하고 개선하기의 역할과 적용 조건을 설명할 수 있다.
- 느린 모바일 조건에서 첫 화면·입력·목록 스크롤을 기록하세요.
- 같은 조건에서 성능과 키보드·오류 상태가 유지되는지 확인하세요.
사전 지식
앞선 Firestore 조회와 구독 비용 최적화를 먼저 읽으면 용어를 이해하기 쉽습니다. 이미 아는 내용이면 이 장부터 시작해도 됩니다.
개념 이해
성능은 파일 크기만이 아니라 첫 화면이 보이고 사용자의 입력에 반응하며 화면이 안정되는 경험입니다. 느린 구간을 재현하고 같은 조건으로 전후를 비교하세요.
코드 분할·Lazy Loading·번들
처음 필요하지 않은 편집기나 큰 차트는 지연 로딩을 검토합니다. 라이브러리 전체 가져오기를 피하고 실제 번들에 포함된 크기를 확인합니다.
이미지·WebP·AVIF
표시 크기에 맞는 이미지와 적절한 압축 형식을 사용합니다. 크기 정보를 지정해 레이아웃 이동을 줄이고 중요한 첫 화면 이미지를 무조건 늦추지 않습니다.
렌더링·중복 요청·리스트 가상화
불필요한 상태 갱신과 중복 요청을 줄입니다. 매우 긴 목록은 보이는 항목만 그리는 가상화를 검토하지만 접근성·검색·스크롤 복원도 확인합니다.
Debounce·Throttle·검색
Debounce는 입력이 잠시 멈춘 뒤 실행, Throttle은 일정 간격으로 실행 횟수를 제한합니다. 검색 요청에는 이전 응답이 새 결과를 덮지 않도록 취소·순서 검사를 둡니다.
Core Web Vitals·Lighthouse
LCP는 주요 내용 표시, INP는 상호작용 응답, CLS는 예상치 못한 배치 이동을 관찰합니다. Lighthouse 실험실 결과와 실제 사용자 환경 지표를 구분합니다.
실제 사용 사례
검색어 한 글자마다 API를 부르면 입력량만큼 비용이 늘어납니다. 짧은 입력 대기와 요청 취소를 적용한 뒤 느린 네트워크에서 마지막 검색 결과만 표시되는지 확인하세요.
단계별 실습
실습은 운영 서비스가 아닌 별도 연습 프로젝트에서 진행하세요. 기존 파일이 있다면 변경 전 기록을 남깁니다.
- 느린 모바일 조건에서 첫 화면·입력·목록 스크롤을 기록하세요.
- Lighthouse와 Network에서 큰 자원과 중복 요청을 찾으세요.
- 가장 큰 원인 하나에 코드 분할·이미지 크기·검색 대기를 적용하세요.
- 같은 조건에서 성능과 키보드·오류 상태가 유지되는지 확인하세요.
코드와 프롬프트
아래 요청에서 대괄호 부분을 내 프로젝트에 맞게 바꾼 뒤 AI 도구에 전달하세요.
[느린 화면]을 실제 병목부터 분석해줘. 번들·이미지·렌더링·요청·긴 목록·검색을 측정하고 한 가지 개선씩 적용해줘. LCP·INP·CLS와 사용성 전후를 구분해 보고해줘.자주 발생하는 문제와 해결
| 문제와 원인 | 해결 방법과 확인 기준 |
|---|---|
| 측정 없이 모든 함수에 메모화를 적용함 | 실제 렌더링 비용과 상태 흐름을 먼저 확인합니다. |
| 이전 검색 결과가 늦게 와 덮어씀 | 요청 취소와 최신 요청 확인을 적용합니다. |
핵심 요약
- 측정→한 가지 변경→같은 조건 재측정 순서를 지킵니다.
- 빠르게 보이는 것과 입력에 빨리 반응하는 것은 모두 중요합니다.
완료 확인
참고자료
확인 기준일: 2026-10-20. 요금·사용 한도·제품 기능·설정 경로는 변경될 수 있으므로 작업 직전 공식 문서와 설치 버전을 확인하세요.