INP: FID를 대체하는 새로운 중요 지표
2024년 3월 12일 Google은 Core Web Vitals: FID(First Input Delay) 전환을 완료했습니다. 종료하고 INP(Interaction to Next Paint)를 입력했습니다. 패널의 조용한 변화 그러나 수백만 사이트의 SEO 순위에 실질적인 영향을 미치는 Google Search Console. 나에 따르면 Chrome 사용자 경험 보고서(CrUX)의 데이터, 웹사이트의 43%가 여전히 실패함 INP "양호" 임계값(200ms 미만), 보다 훨씬 높은 수치 FID에 실패한 사이트 중 30%에 해당합니다.
FID는 첫 번째 입력까지의 지연만 측정했습니다. 즉, 사용자가 입력한 이후 얼마나 많은 시간이 경과했는지입니다. 브라우저가 해당 이벤트 처리를 시작할 때 처음으로 클릭했습니다. 첫 번째 상호작용만 측정하고 유지되지 않았기 때문에 이기기 쉬운 측정항목이었습니다. 다음 페인트에 대해 설명합니다. INP는 근본적으로 다릅니다. 반응성 전반적으로 세션 전체 기간 동안 최종 점수로 선택 최악의 상호작용 백분위수.
무엇을 배울 것인가
- INP가 FID와 어떻게 다른지, 실제 반응성을 측정하는 이유는 무엇입니까?
- INP 좋음/개선 필요/나쁨 임계값(200ms / 500ms)
- Chrome DevTools, web-vitals.js 및 PageSpeed Insights를 사용하여 INP를 측정하는 방법
- INP를 폭발시키는 가장 일반적인 5가지 JavaScript 패턴
- CrUX 필드 데이터와 Lighthouse 합성 데이터를 해석하는 방법
- 느린 상호 작용을 찾아 수정하는 디버깅 워크플로
INP가 측정하는 것: 기술적 정의
INP는 방문 중 클릭, 탭 및 페이지와의 모든 사용자 상호 작용을 관찰합니다. 키 누르기. 각 상호작용에 대해 입력 이후의 시간을 측정합니다. 당시 사용자의 브라우저 다음 프레임을 칠합니다 반영하는 해당 입력에 대한 시각적 반응. 이 간격을 상호 작용 대기 시간 세 부분으로 구성됩니다.
- 입력 지연: 브라우저가 이벤트 처리를 시작하기 전에 경과한 시간(메인 스레드가 사용 중이었습니다)
- 처리 시간: JavaScript 이벤트 핸들러의 실행 시간
- 프레젠테이션 지연: 브라우저가 새 프레임을 레이아웃하고, 칠하고, 합성하는 데 걸리는 시간
INP는 98번째 백분위수 세션의 모든 상호작용 중(또는 최악의 경우) 상호작용이 50개 미만인 경우 값). 평균도 아니고 일반적인 값도 아니고 거의 최악입니다. 이로 인해 INP는 FID보다 지연 시간 급증에 훨씬 더 민감해집니다.
INP 임계값
| 평가 | INP 값 | SEO 영향 |
|---|---|---|
| 좋은 | < 200ms | 순위에 긍정적으로 기여 |
| 개선이 필요함 | 200ms - 500ms | 중립, 개선이 필요한 부분 |
| 가난한 | > 500ms | 구글 순위 페널티 |
FID와 INP: 실질적인 차이
FID에서 INP로의 전환이 중요한 변화인 이유를 이해하려면 다음 시나리오를 고려하십시오. 전자상거래 페이지가 있습니다. 처음 로드할 때 사용자는 "장바구니에 추가"를 클릭하고 이벤트는 50ms(훌륭한 FID) 내에 처리됩니다. 그런 다음 페이지를 탐색하고, 제품을 필터링하고, 카테고리 드롭다운을 엽니다. 이 두 번째 상호 작용은 계산량이 많기 때문에 800ms가 걸립니다. 메인 스레드에서 실행 중입니다.
와 함께 버팀대: 점수는 50ms였습니다 - 좋은.
와 함께 INP: 점수는 800ms입니다 - 가난한.
INP는 첫 번째 클릭뿐 아니라 세션 전반에 걸친 실제 사용자 경험을 반영합니다. 이것이 우수한 FID를 가졌던 많은 사이트가 이제 문제가 있는 INP를 갖게 된 이유입니다.
INP 측정 방법
1. Chrome DevTools - 성능 패널
INP를 진단하는 가장 정확한 방법은 Chrome DevTools의 성능 패널입니다. 다음과 같이 진행하세요:
- DevTools(F12)를 열고 탭으로 이동합니다. 성능
- 녹음을 시작하려면 빨간색 원을 클릭하세요.
- 측정하려는 상호작용(클릭, 입력 등)을 실행하세요.
- 녹음 중지
- 결과 패널에서 섹션의 빨간색 막대를 찾습니다. 상호작용
- 세부 정보를 보려면 상호작용을 클릭하세요. 입력 지연, 처리 시간, 프레젠테이션 지연
2. 웹 바이탈 JS 라이브러리(필드 데이터)
도서관 web-vitals Google을 사용하면 프로덕션 사용자의 실제 INP를 측정할 수 있습니다.
프로젝트에 추가하고 데이터를 분석 엔드포인트로 보냅니다.
import { onINP } from 'web-vitals';
onINP((metric) => {
// metric.value: il valore INP in millisecondi
// metric.rating: 'good' | 'needs-improvement' | 'poor'
// metric.entries: le PerformanceEventTiming entries
console.log('INP:', metric.value, metric.rating);
// Invia a analytics
fetch('/api/vitals', {
method: 'POST',
body: JSON.stringify({
metric: 'INP',
value: metric.value,
rating: metric.rating,
url: window.location.href,
}),
});
});3. PageSpeed Insights 및 CrUX
PageSpeed Insights는 '필드 데이터' 섹션에 도메인의 실제 CrUX 데이터를 표시합니다. CrUX 데이터는 동기화가 활성화된 Chrome 사용자를 기반으로 하므로, 따라서 이는 합성 Lighthouse 결과가 아닌 실제 장치에 대한 실제 경험을 반영합니다. 하드웨어로 제어되는 방식으로 실행됩니다.
실험실 데이터와 현장 데이터
"Lab" 모드의 Lighthouse 및 PageSpeed Insights는 중급형 모바일 장치를 시뮬레이션합니다. 느린 4G 연결에서. CrUX 데이터(필드 데이터)는 사이트의 실제 사용자를 반영합니다. 두 측정치 사이에 30~50%의 차이가 나는 것이 정상입니다. 필드 데이터를 지표로 사용 SEO 결정을 위한 기본 정보와 기술 디버깅을 위한 실험실 데이터입니다.
높은 INP를 유발하는 가장 일반적인 패턴
1. 메인 스레드의 긴 작업
높은 INP의 주요 원인은 다음과 같습니다. 긴 작업: 자바스크립트 작업
50ms 이상 지속됩니다. 각 장기 작업은 브라우저의 기본 스레드를 차단하여 응답하지 못하게 합니다.
사용자 입력에. 이를 식별하는 가장 쉬운 방법은 DevTools Performance 패널입니다.
또는 API PerformanceObserver:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.duration > 50) {
console.warn('Long Task rilevato:', {
duration: entry.duration,
startTime: entry.startTime,
});
}
}
});
observer.observe({ type: 'longtask', buffered: true });2. 헤비 이벤트 핸들러
많은 계산을 동기적으로 수행하는 클릭 핸들러는 높은 INP의 원인이 되는 경우가 많습니다. 일반적인 패턴은 다음과 같은 핸들러입니다.
- 메모리의 대규모 배열 필터링 또는 변환
- DOM을 대규모로 렌더링(수백 개의 요소 추가)
- 복잡한 레이아웃을 계산하거나 브라우저 리플로우를 강제 적용
- 대규모 JSON을 구문 분석합니다.
3. 반응/각도 변화 감지가 최적화되지 않음
React 또는 Angular와 같은 프레임워크에서는 단일 이벤트가 변경 감지 주기를 트리거할 수 있습니다. 전체 구성 요소 트리를 다시 계산합니다. 복잡한 구성 요소 또는 메모가 없는 경우 적절하다면 100~400ms 정도 걸릴 수 있습니다.
Angular에서 해결책은 다음과 같습니다. ChangeDetectionStrategy.OnPush 그리고 신호의 사용
세분화 된 반응성. 리액트에서는, React.memo, useMemo e useCallback
그것들은 핵심 도구입니다.
4. 타사 스크립트
분석, 채팅 위젯, 광고 스크립트 및 기타 제3자 스크립트는 종종 메인 스레드에서 실행됩니다. 입력에 대한 응답을 차단할 수 있습니다. 이를 식별하려면 DevTools Performance 패널에서 타사 도메인에서 발생하는 장기 작업을 찾으세요.
5. SSR 프레임워크의 수화
SSR(Next.js, Angular Universal, Nuxt)을 사용하는 애플리케이션에서 수화 단계는 다음과 같을 수 있습니다. 비싸다. 하이드레이션 중에 프레임워크는 렌더링된 DOM에 이벤트 핸들러를 다시 연결합니다. 서버 측. 이 단계가 사용자 상호 작용과 겹치면 INP가 저하됩니다.
INP 디버깅 작업흐름
높은 NPI를 진단하고 수정하기 위해 권장되는 작업 흐름은 다음과 같습니다.
- 문제가 있는 상호작용 식별 성능 패널 사용 DevTools 제공. 상호 작용 섹션에서 지연 시간이 200ms를 넘는 상호 작용을 찾아보세요.
- 분석 분석: 세 가지 구성 요소(입력 지연, 처리, 프레젠테이션)이 가장 큰가요?
- If 및 입력 지연: 당시 메인 스레드에서는 다른 것이 실행 중이었습니다. 클릭의. 타임라인에서 상호 작용 이전의 장기 작업을 찾으세요.
-
경우와 처리 시간: 이벤트 핸들러가 너무 느립니다.
미국
scheduler.yield()깨뜨리기 위해(다음 기사 참조) - 프레젠테이션이 지연되는 경우: 프레임 렌더링이 느립니다. 스래싱 레이아웃, 비용이 많이 드는 CSS 애니메이션 또는 과도한 합성 레이어를 찾으십시오.
INP 및 SEO: 실제 영향
Google은 INP를 포함한 핵심 웹 바이탈이 순위 요소임을 확인했습니다. 무게 정확히 공개되지는 않았지만 경험적 증거에 따르면 INP가 "나쁨"에서 "좋음"으로 바뀌는 것으로 나타났습니다. 경쟁 페이지의 순위가 2~5% 향상될 수 있습니다. 트래픽이 있는 사이트의 경우 이는 상당한 유기적 트래픽 증가로 해석됩니다.
모든 메인 페이지(홈페이지, 카테고리 페이지, 제품 페이지)를 "좋음" 등급(< 200ms)으로 지정합니다. 정적 콘텐츠 페이지에는 거의 없습니다. INP 문제; 문제는 복잡한 대화형 인터페이스가 있는 페이지에 중점을 둡니다.
다음 단계
이제 INP 문제를 측정하고 식별하는 방법을 알았으므로 다음 단계는 다음 단계를 배우는 것입니다.
문제 해결: 이 시리즈의 다음 기사에서는 사용 방법을 설명합니다. scheduler.yield()
긴 작업을 분할하고 하나의 상호 작용과 다른 상호 작용 사이의 기본 스레드를 확보합니다.
렌더링 측면의 경우 LCP 최적화 기사에서는 프리젠테이션을 지연시키고 첫 번째 중요한 프레임의 페인트를 가속화합니다.
결론
INP는 웹 성능 측정의 패러다임 전환을 나타냅니다. INP만으로는 충분하지 않습니다. 페이지가 빠르게 로드되도록 하려면 답변 전체적으로 빠르게 세션 기간. INP의 양호 기준을 충족하지 못한 사이트 중 43%에 기회가 있습니다. 사용자 경험과 SEO 순위를 모두 향상시키는 구체적인 방법입니다.
출발점은 항상 측정입니다. 설치 web-vitals.js 당신의 것
사이트를 운영하고, 실제 사용자 데이터를 수집하고, Chrome DevTools를 사용하여 상호작용을 진단합니다.
문제. 구체적인 데이터가 있어야만 정보를 바탕으로 최적화 결정을 내릴 수 있습니다.