7.8 KiB
category, tags, title, last_updated
| category | tags | title | last_updated | ||||
|---|---|---|---|---|---|---|---|
| Unified |
|
|
2026-05-02 |
Interaction to Next Paint (INP)
📌 Brief Summary
INP(Interaction to Next Paint)는 웹 페이지의 전반적인 상호작용성(Interactivity)과 응답성(Responsiveness)을 측정하기 위해 2024년 Google이 공식 도입한 Core Web Vitals 지표입니다 [1-3]. 첫 번째 상호작용만 측정하던 기존의 FID(First Input Delay)와 달리, 페이지 방문 기간 동안 발생하는 모든 상호작용(클릭, 탭, 키 누름 등)의 전체 지연 시간을 측정하여 실제 사용자 경험을 더 정확하게 반영합니다 [4-6]. 사용자의 작업에 대해 즉각적인 시각적 피드백을 제공하는 것을 목표로 하며, 200밀리초(ms) 이하의 지연 시간을 기록해야 '좋음(Good)'으로 평가받을 수 있습니다 [5, 7].
"단 한 번의 빠른 반응이 아니라, 사용자가 페이지를 떠날 때까지 수행하는 모든 상호작용의 지연을 감시하고, 0.2초 이내의 즉각적인 응답성을 일관되게 보장하라" — FID를 대체하여 웹사이트의 전체적인 반응성을 측정하는 2024년 이후 Core Web Vitals의 핵심 지표.
📖 Core Content
-
도입 배경 및 영향: INP는 2024년에 기존 Core Web Vitals 지표였던 First Input Delay (FID)를 공식적으로 대체했습니다 [1, 2]. FID가 첫 번째 상호작용의 이벤트 핸들러 시작 전 지연 시간만을 측정했던 반면, INP는 페이지 전체 수명 동안 발생하는 모든 상호작용을 추적하고 렌더링 지연까지 포함하여 측정합니다 [4-6]. 이 엄격해진 기준 변화로 인해 2024년 2월, 모바일 웹사이트들의 Core Web Vitals 통과율이 크게 하락하는 현상이 관찰되기도 했습니다 [1].
-
측정 및 산출 방식: INP는 75백분위수(75th percentile)의 방문 데이터를 기준으로 계산됩니다 [8]. 페이지 내 상호작용이 50개 이하인 경우 가장 긴 상호작용 지연 시간을 INP로 간주하며, 상호작용이 50개를 초과할 경우 이상치(Outlier)의 영향을 줄이기 위해 50개 그룹당 가장 지연 시간이 긴 1개를 제외한 나머지 중 최댓값을 사용합니다 [8].
- 평가 임계값: 200ms 이하는 '좋음(Good)', 200ms 초과 500ms 이하는 '개선 필요(Needs improvement)', 500ms 초과는 '나쁨(Poor)'으로 분류됩니다 [5].
- 브라우저 지원: Chrome뿐만 아니라 Interop 2025 프로젝트를 통해 Firefox(버전 144부터 지원)와 Safari에서도 INP 측정 지표 구현 작업이 시작되었습니다 [9].
-
지연 시간의 세부 구성 요소 (Sub-pArts): 사용자 상호작용의 전체 대기 시간은 크게 3단계로 나뉘며, Chrome DevTools를 통해 이 세부 정보(INP breakdown)를 확인할 수 있습니다 [4, 5, 10].
- 입력 지연 (Input delay): 이벤트가 감지된 시점부터 이벤트 핸들러가 실행되기 전까지의 시간 [4, 5].
- 처리 시간 (Processing duration): 이벤트 핸들러 코드가 실제로 실행되는 시간 [4]. 성능 병목이 가장 자주 발생하는 구간입니다 [10].
- 표시 지연 (Presentation delay): 사용자 작업 이후 다음 프레임을 화면에 렌더링(페인트)할 때까지 걸리는 시간 [4].
-
최적화 전략: INP를 최적화하기 위해서는 브라우저의 메인 스레드(Main Thread) 차단을 최소화해야 합니다. 이를 위해 긴 작업(Long Tasks)을 비동기 청크로 분할하고, 핵심 이벤트 핸들러의 우선순위를 높이며, 불필요한 JavaScript 지연 로드(Lazy load) 및 수동 이벤트 리스너(Passive event listeners) 사용, 레이아웃 스래싱(Layout Thrashing) 감소 등의 전략이 필요합니다 [11-14]. Chrome DevTools의 성능 패널에 통합된 Long Animation Frames API를 활용하면 상호작용을 지연시키는 특정 스크립트와 그 원인을 직관적으로 파악할 수 있습니다 [15, 16].
-
특수 측정 사례 (텍스트 강조 표시): 웹 페이지에서 텍스트를 드래그하여 강조 표시(Highlighting)하는 행위도 일반적으로 INP 점수에 영향을 주는 사용자 상호작용으로 간주됩니다 [17]. 다만, 2025년 초 Chrome의 업데이트를 통해 사용자가 창의 가장자리에 도달하여 스크롤이 트리거되는 텍스트 강조 표시 상황에서는 INP 점수가 증가하지 않도록 측정 방식이 조정되었습니다 [17].
- 추출된 패턴: "Continuous Responsiveness and Task Yielding" — 긴 작업을 작게 쪼개어 브라우저가 사용자 입력과 렌더링 업데이트 사이에 숨 쉴 틈(Yield)을 주는 패턴.
- INP의 핵심 메커니즘:
- Input Delay: 사용자 입력 후 이벤트 핸들러가 실행되기 전까지의 대기 시간 (주로 메인 스레드 점유로 발생).
- Processing Time: 이벤트 핸들러 자체의 실행 시간.
- Presentation Delay: 이벤트 처리 후 실제 화면에 변경 사항이 그려지기까지의 시간.
- 주요 최적화 전략:
- Breaking Up Long Tasks: 50ms 이상의 무거운 동기 작업을
scheduler.yield()나setTimeout으로 분할. - Web Workers: 복잡한 연산을 메인 스레드 밖으로 오프로드.
- Optimization of Third-party Scripts: 상호작용을 저해하는 광고/분석 스크립트의 실행 지연.
- Event Debouncing/Throttling: 잦은 이벤트 발생을 제한하여 렌더링 부하 감소.
- Breaking Up Long Tasks: 50ms 이상의 무거운 동기 작업을
- 의의: 사용자의 입력에 즉각적으로 반응하는 웹사이트를 통해 심리적 마찰을 줄이고 비즈니스 전환율을 높임.
⚖️ Trade-offs & Caveats
- 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- 정책 변화: AI 분야의 자동 자산화 수행.
- 과거 데이터와의 충돌: 과거 FID는 첫 번째 상호작용의 지연만 측정했으나, INP 정책은 '전체 세션 중 가장 긴 지연 시간'을 측정 정책으로 삼아 훨씬 엄격한 최적화를 요구함.
- 정책 변화: Antigravity 프로젝트는 모든 동적 리스트 렌더링 시 가상화(Virtualization) 적용을 의무화하며, 100ms 이상의 메인 스레드 차단 작업 발생 시 빌드 경고 정책을 시행함.
🔗 Knowledge Connections
- Related Topics: Core Web Vitals, First Input Delay (FID), Long Animation Frames API
- Projects/Contexts: Chrome User Experience Report (CrUX), Chrome DevTools, Interop 2025
- Contradictions/Notes: 초기 측정 방식에서는 모든 텍스트 강조 표시가 INP에 영향을 주었으나, 2025년 초 Chrome의 업데이트로 인해 스크롤을 동반하는 텍스트 강조 표시는 예외적으로 INP 지연 시간에 합산되지 않도록 변경되었습니다 [17].
Last updated: 2026-04-19
- Core-Web-Vitals-Metrics, JavaScript-Optimization-Patterns, Google-Page-Experience-2025-Update, Frontend-Performance-Optimization-Guide
- Raw Source: 00_Raw/INP (Interaction to Next Paint).md, 00_Raw/Interaction to Next Paint (INP).md