chore(wiki): reinforce knowledge batch #6-#10 (200 docs milestone)

00_Raw/레거시 웹사이트의 프론트엔드 성능(LCP, INP, CLS) 고도화.md

@@ -0,0 +1,31 @@
+# [[레거시 웹사이트의 프론트엔드 성능(LCP, INP, CLS) 고도화]]
+
+## 📌 Brief Summary
+레거시 웹사이트의 프론트엔드 성능 고도화는 2025년 구글 코어 웹 바이탈(Core Web Vitals) 업데이트 기준에 맞춰 웹사이트의 로딩 속도(LCP), 반응성(INP), 시각적 안정성(CLS)을 최적화하는 전략이다. 사이트 전체를 재구축하지 않고도 이미지 최적화, 자바스크립트 분할, CSS 인라인 처리 등의 기술적 조치를 통해 사용자 경험(UX)을 개선하고 검색 엔진 최적화(SEO) 순위와 전환율을 향상시키는 것을 목표로 한다. 특히 2025년부터 FID를 대체한 새로운 반응성 지표인 INP에 대한 대응이 필수적이다.
+
+## 📖 Core Content
+소스에 기반한 프론트엔드 성능(LCP, INP, CLS) 고도화 방법은 다음과 같다.
+
+*   **LCP (Largest Contentful Paint) 최적화 (로딩 성능)**
+    *   LCP는 페이지의 주요 콘텐츠가 화면에 표시되는 데 걸리는 시간을 측정한다. 2025년 구글의 기준에 따르면 'Good(우수)' 판정을 받기 위해 LCP는 2.5초 미만, 더 엄격하게는 2.0초 미만이어야 한다 [1-3].
+    *   **최적화 전략:** 크고 최적화되지 않은 이미지는 LCP 불량의 주요 원인이다. 이미지를 WebP 또는 AVIF 같은 차세대 포맷으로 변환하고 압축해야 한다 [4-6]. 핵심 LCP 리소스(예: 히어로 이미지)에는 `fetchpriority="high"` 속성이나 `preload`를 사용하여 브라우저가 우선적으로 다운로드하도록 지시한다 [6, 7]. 또한, 서버 응답 시간(TTFB)을 줄이기 위해 CDN(콘텐츠 전송 네트워크)을 사용하고, 렌더링을 차단하는 자바스크립트와 CSS를 제거하거나 인라인화 및 지연 로딩(Lazy Loading)을 적용해야 한다 [4, 8-11].
+
+*   **INP (Interaction to Next Paint) 최적화 (반응성)**
+    *   2025년 업데이트의 가장 큰 변화로, 기존의 FID(First Input Delay)를 대체하는 지표다. 클릭이나 키보드 입력 등 사용자의 모든 상호작용 후 브라우저가 다음 프레임을 표시할 때까지의 전체 지연 시간을 측정한다. 200ms 미만(또는 150ms 미만)을 유지해야 한다 [1-3].
+    *   **최적화 전략:** 메인 스레드를 차단하는 무거운 자바스크립트 실행이 주요 원인이다. 50ms 이상의 긴 작업(Long tasks)을 잘게 쪼개어 브라우저가 상호작용을 처리할 틈을 주거나(`setTimeout` 등 활용), 무거운 연산은 Web Worker를 사용하여 메인 스레드에서 분리해야 한다 [11-17]. 타사 스크립트(분석, 채팅 위젯 등) 로딩을 지연시키고, 이벤트 핸들러에는 디바운스(Debounce) 및 스로틀(Throttle) 기법을 적용하며 비활성 시간에는 `requestIdleCallback`을 활용한다 [18-22].
+
+*   **CLS (Cumulative Layout Shift) 최적화 (시각적 안정성)**
+    *   페이지 로딩 중 요소들이 예기치 않게 이동하는 시각적 불안정성을 측정한다. 목표 점수는 0.1 미만(더 엄격하게는 0.08 미만)이다 [1, 2, 23].
+    *   **최적화 전략:** 이미지와 비디오 요소에 명시적인 `width`와 `height` 크기 속성을 부여하여 브라우저가 로딩 전 미리 공간을 확보하게 해야 한다 [24-27]. 동적으로 삽입되는 광고, 배너, 위젯 등은 `min-height` 등을 사용하여 미리 공간을 예약해야 하며, 사용자가 스크롤을 시작한 후 뷰포트 위쪽에 콘텐츠를 주입해서는 안 된다 [26-29]. 폰트 로딩으로 인한 텍스트 리플로우 현상을 막기 위해 CSS에서 `font-display: swap` 또는 `optional`을 적용하고, 애니메이션 시에는 레이아웃 재계산을 유발하는 `top`, `left` 속성 대신 `transform` 속성(GPU 가속 활용)을 사용한다 [11, 25, 30, 31].
+
+*   **모니터링 및 성능 관리**
+    *   Core Web Vitals는 정기적으로 모니터링되어야 한다. 실험실 환경(Lab Data)을 위해 Google Lighthouse와 PageSpeed Insights, WebPageTest를 사용해 디버깅하고 병목 현상을 파악한다 [32-35].
+    *   실제 사용자 환경(Field Data) 추적을 위해 Google Search Console의 Core Web Vitals 보고서를 확인하고, 지속적인 추적을 위해 RUM(Real User Monitoring) 도구를 통합하여 성능 회귀를 방지하는 성능 예산(Performance Budgets)을 설정하는 것이 좋다 [36-40].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Core Web Vitals]], [[Search Engine Optimization (SEO)]], [[User Experience (UX)]], [[Server-Side Rendering (SSR)]]
+- **Projects/Contexts:** [[구글 2025 검색 알고리즘 업데이트 대응]], [[레거시 웹사이트 프론트엔드 최적화 및 마이그레이션 프로젝트]]
+- **Contradictions/Notes:** 소스 6은 2025년 기준 LCP를 2.0초 미만, CLS를 0.08 미만, INP를 150ms 미만으로 매우 엄격하게 제시하고 있으나[1], 소스 12 및 소스 15 등에서는 구글의 권장 임계값을 LCP 2.5초 미만, CLS 0.1 미만, INP 200ms 미만으로 안내하고 있어 목표 수치에 대한 미세한 차이가 존재한다 [2, 3]. 동적 렌더링(Dynamic Rendering)에 대해 소스 28(LinkGraph)은 봇 전용으로 사전 렌더링 된 페이지를 제공하는 것을 대안으로 소개하지만, 구글은 콘텐츠가 동일하지 않을 경우 이를 클로킹(Cloaking)으로 간주하므로 최후의 수단으로만 사용해야 한다고 경고한다 [41].
+
+---
+*Last updated: 2026-04-26*