# [[Frontend Performance Checklist]]

## 📌 Brief Summary
프론트엔드 성능 체크리스트(Frontend Performance Checklist)는 웹사이트의 로딩 속도와 효율성을 극대화하기 위한 핵심 프론트엔드 모범 사례와 최적화 전략을 정리한 포괄적이고 플랫폼에 구애받지 않는 가이드입니다 [1]. 2025년 기준, 이 체크리스트는 구글의 코어 웹 바이탈(Core Web Vitals)의 엄격해진 기준(LCP, INP, CLS)을 달성하고, 에셋 최적화 및 코드 분할을 통해 로딩 시간을 단축하는 기술적 세부 항목들로 구성됩니다 [2], [3], [4], [5]. 이를 통해 개발자는 사용자 경험을 향상시키고 SEO 순위를 높이는 빠르고 효율적인 웹 애플리케이션을 구축할 수 있습니다 [1], [6], [7].

## 📖 Core Content
**코드 및 자바스크립트 최적화 (Code & Script Optimization)**
*   **라우트 기반 코드 분할 및 지연 로딩:** 라우트 단위로 코드 분할(Code splitting)을 설정하고 화면에 당장 보이지 않는 컴포넌트(Below-fold components)는 지연 로딩(Lazy loading)을 적용합니다 [4], [5], [6].
*   **번들 크기 최소화:** 사용하지 않는 코드를 제거하는 트리 쉐이킹(Tree-shaking)을 올바르게 구성하고, 압축된(gzipped) 메인 자바스크립트 번들의 크기를 200KB 이하로 유지합니다 [4], [5].
*   **렌더링 차단 리소스 제거:** 중요하지 않은 타사(Third-party) 스크립트와 자바스크립트는 지연(defer)시키거나 비동기(async)로 로드하여 메인 스레드 점유를 최소화합니다 [8], [9], [4], [5].
*   **INP(Interaction to Next Paint) 개선:** 50ms 이상의 긴 작업(Long tasks)을 잘게 쪼개거나, 무거운 연산을 웹 워커(Web Workers)로 오프로드하여 브라우저의 상호작용 지연을 줄입니다 [10], [11], [12], [13], [14], [15].

**에셋 및 미디어 최적화 (Asset & Media Optimization)**
*   **차세대 이미지 포맷 사용:** 이미지를 기존 포맷보다 용량이 작은 WebP나 AVIF로 압축 및 변환하여 제공합니다 [16], [17], [18], [4], [5].
*   **응답형 이미지 및 우선순위 지정:** 기기에 맞는 반응형 이미지(`srcset`)를 사용하고, 페이지의 가장 큰 핵심 콘텐츠(LCP 이미지)에는 `fetchpriority="high"` 속성을 부여하여 렌더링 우선순위를 높입니다 [16], [4], [5].
*   **CLS(Cumulative Layout Shift) 방지:** 시각적 안정성을 위해 모든 이미지와 비디오, 그리고 광고 슬롯 등에 명시적인 너비와 높이(`width`/`height`) 또는 최소 높이(`min-height`) 속성을 사전에 지정해 둡니다 [19], [20], [21], [4], [5].

**렌더링 및 네트워크 전략 (Rendering & Network Strategy)**
*   **크리티컬 CSS 인라인 처리:** 스크롤 없이 볼 수 있는 상단 영역(Above-the-fold) 렌더링에 필요한 핵심 CSS(Critical CSS)를 인라인으로 삽입하고, 나머지 CSS 로드를 지연시킵니다 [8], [22], [23], [4], [5], [6].
*   **폰트 및 외부 리소스 최적화:** 웹 폰트를 사전에 로드(Preload)하고 `font-display: optional` 또는 `swap` 속성을 사용하여 폰트 로드 지연으로 인한 텍스트 깜빡임 현상을 방지합니다 [19], [24], [25], [4], [5]. 외부 도메인 리소스 로딩 속도를 높이기 위해 리소스 힌트(`preconnect`, `dns-prefetch`, `modulepreload` 등)를 적용합니다 [9], [26].
*   **캐싱 및 전송 프로토콜:** 정적 에셋 서빙을 위해 CDN을 활용하고, HTTP/2 또는 HTTP/3 프로토콜과 Brotli 등의 압축 기술을 결합하여 TTFB(Time to First Byte)를 줄입니다 [17], [22], [18], [23], [6].

**성능 모니터링 및 유지 보수 (Monitoring & Budgets)**
*   **성능 예산(Performance Budgets) 설정:** 페이지의 총 자바스크립트 및 에셋 크기 제한을 설정하고(예: Webpack Bundle Analyzer 사용), Lighthouse CI 등을 활용해 배포 파이프라인에서 LCP < 2.5초, CLS < 0.1, INP < 200ms 기준을 준수하는지 강제합니다 [27], [28], [29], [30].
*   **지속적 모니터링:** 구글 Search Console 및 RUM(Real User Monitoring) 도구를 연동해 실제 트래픽 환경의 성능 데이터를 수집하고, 임계값을 초과할 시 경고가 발생하도록 모니터링 환경을 구성합니다 [26], [31], [32], [33], [34].

## 🔗 Knowledge Connections
- **Related Topics:** [[Core Web Vitals]], [[Code Splitting]], [[Lazy Loading]], [[Server-Side Rendering (SSR)]]
- **Projects/Contexts:** [[Web Performance Optimization]], [[React SEO Optimization]], [[Modern Website Architecture]]
- **Contradictions/Notes:** 프론트엔드 성능을 모니터링할 때 단순히 통제된 환경(Lab testing)의 Lighthouse 점수만을 보고 최적화가 완료되었다고 판단하는 것은 흔한 오류(Pitfall)입니다. 사용자 경험을 온전히 개선하기 위해서는 크롬 사용자 경험 보고서(CrUX) 데이터나 RUM 도구 기반의 실제 필드 데이터(Field data) 검증이 반드시 수반되어야 합니다 [35], [36].

---
*Last updated: 2026-04-26*