INP Scanner로 INP를 측정하고 사이트 응답성 개선하기

이 글은 INP와 느린 상호작용을 조사하는 INP Scanner Milten 활용법을 설명합니다. INP는 2024년 3월 Core Web Vitals에서 FID를 대체했습니다. 실험실 테스트는 실행한 동작만 다루며 모든 방문자의 경험을 대표하지 않습니다.

Interaction to Next Paint(INP)란?

INP는 방문 중 클릭, 탭, 키보드 입력에 대한 페이지 응답성을 평가합니다. 지연에는 입력 처리 대기, 핸들러 실행, 다음 화면 갱신까지의 대기가 포함됩니다. FID가 첫 입력 지연만 측정했다면 INP는 방문 전체의 해당 상호작용을 고려합니다. 이후 비동기 네트워크 응답이 끝날 때까지의 전체 시간을 측정하지는 않습니다.

INP의 주요 특징:

• 집계: INP는 평균이 아닙니다. 일반적으로 가장 느린 상호작용을 반영하며, 상호작용이 많은 방문에서는 일부 이상치를 제외합니다.
• 기준: 200ms 이하는 좋음, 200ms 초과부터 500ms 이하는 개선 필요, 500ms 초과는 나쁨입니다. 실제 방문은 모바일과 데스크톱을 나누어 75번째 백분위수로 평가합니다.
• 포함 동작: 클릭, 탭, 키보드 입력입니다. 스크롤과 마우스 호버 자체는 INP 상호작용이 아닙니다.

INP가 왜 중요한가요?

1. 사용자 경험(UX)

시각적 반응이 늦으면 버튼이 작동하지 않는 것처럼 보여 반복 클릭을 유발할 수 있습니다. 구체적인 동작과 결과를 측정하세요. 페이지 로딩 통계가 해당 사이트에서 INP가 이탈률에 미치는 영향을 입증하지는 않습니다.

2. SEO 및 검색 순위

INP는 Google 순위 시스템에서 사용하는 Core Web Vitals의 일부입니다. 좋은 점수가 상위 노출을 보장하지 않으며, 나쁜 점수만으로 고정된 순위 불이익을 단정할 수도 없습니다. 콘텐츠 관련성과 다른 페이지 경험 요소를 함께 평가하세요.

3. 경쟁 우위로서의 속도

빠른 시각적 피드백은 동작이 접수됐음을 알려 줍니다. 사용자에게 중요한 과제를 비교하세요. 같은 지연이라도 과제마다 영향이 다를 수 있습니다.

Milten의 INP Scanner 활용하기

INP Scanner는 통제된 브라우저 실행에서 응답성을 조사하는 도구입니다. 결과를 일반화하기 전에 실행한 동작과 보고서의 한계를 확인하세요.

1. 테스트한 동작 확인하기

대표적인 흐름을 선택하고 실제로 수행한 동작을 확인합니다.

• 버튼과 링크 클릭.
• 필요한 필드의 키보드 입력.
• 요소에 도달하기 위한 스크롤. 스크롤 자체는 INP 상호작용이 아닙니다.

통제된 실행은 재현 가능한 시나리오이며 모든 방문자 기기에서의 측정이 아닙니다. 브라우저, 기기 프로필, 실제 테스트 조건을 기록하세요. 다루지 않은 중요한 흐름은 수동으로 추가 검사합니다.

2. 지연 시간 해석하기

INP 측정에는 Event Timing 데이터가 사용됩니다. PerformanceObserver로 지원되는 event 항목을 관찰할 수 있습니다. 이 용도의 일반적인 render 항목은 없습니다. web-vitals 같은 라이브러리가 상호작용을 그룹화하고 INP를 계산합니다.

• 입력 대기, 핸들러 실행, 화면 갱신 대기를 구분합니다.
• 메인 스레드의 긴 JavaScript 작업을 조사합니다.
• 애니메이션 부드러움은 관련되지만 별개의 문제로 확인합니다.

3. 지적 사항 조사하기

보고서에 실제로 있는 근거를 사용합니다.

• 기록된 상호작용과 대상 요소를 찾습니다.
• 느린 동작을 조사합니다. 600ms가 걸리는 가상의 구매 버튼은 설명용 예이며 고객 측정값이 아닙니다.
• 브라우저 성능 기록에서 가능한 원인을 확인하고 범위를 좁힌 코드 수정을 시험합니다.

자동 테스트의 한계

• 현재 서비스 이용 조건과 보고서 항목을 확인합니다.
• 브라우저 테스트만으로 방문자의 물리적 기기를 검사했다고 볼 수는 없습니다.
• 실행하지 않은 동작과 누락 데이터는 미검증으로 남기고, 가능하면 실제 방문 데이터로 보완합니다.

느린 상호작용의 주요 원인

1. 긴 이벤트 핸들러

설명용 예제입니다. 함수와 데이터는 애플리케이션에서 정의해야 합니다.

button.addEventListener('click', () => {
	// Synchronous processing of 10,000 data rows
	const result = heavyCalculation(data)
	updateUI(result)
})

문제: 동기식 heavyCalculation이 메인 스레드를 차지해 다음 화면 갱신을 늦출 수 있습니다. 해결: 작업을 줄이거나 나누고, 적합한 계산은 Web Worker로 옮깁니다. setTimeout을 한 번 호출하는 것은 같은 무거운 작업을 나중에 예약할 뿐, 메인 스레드 밖으로 옮기는 방법이 아닙니다.

2. 렌더링 차단 CSS/JS

예:

<link rel="stylesheet" href="large-styles.css" />
<script src="analytics.js" defer></script>

문제: 렌더링을 막는 스타일시트와 비싼 스크립트 실행은 화면 표시나 입력을 지연할 수 있습니다. defer는 실행 시점을 바꾸지만 실행 비용을 없애지는 않습니다. 예제 스타일시트는 화면에 적용되며, media="print"만 사용하면 화면에는 적용되지 않습니다. 개선 방법:

• 실제로 중요한 CSS만 인라인으로 넣고 효과를 측정합니다.
• 동적 클래스와 UI 상태를 확인한 뒤 미사용 스타일을 제거합니다. PurgeCSS에는 적절한 설정이 필요합니다.
• 중요하지 않은 스크립트를 미루고 실행 비용도 줄입니다.

3. 느린 애니메이션

예:

@keyframes fade {
	from {
		opacity: 0;
		transform: translateX(-100px);
	}
	to {
		opacity: 1;
		transform: translateX(0);
	}
}

문제: opacity와 transform 애니메이션은 대체로 효율적이지만 많은 요소를 동시에 움직이면 끊김이 생길 수 있습니다. 개선 방법:

• 애니메이션을 단순화하고 동시에 움직이는 요소를 줄입니다.
• 필요할 때만 변경 직전에 will-change: transform을 검토합니다. GPU 가속을 보장하는 설정이 아니며 과도하게 사용하면 자원을 소비합니다. 결과를 측정하세요.

4. 반복적인 강제 레이아웃 계산(layout thrashing)

예:

for (let i = 0; i < 100; i++) {
	element.style.height = `${i}px`
	console.log(element.offsetHeight) // Forces layout recalculation
}

문제: 스타일 쓰기와 offsetHeight 같은 크기 읽기를 번갈아 하면 레이아웃 계산이 반복될 수 있습니다. 레이아웃 계산과 페인팅은 다른 작업입니다. 해결:

• 가능하면 크기 읽기를 먼저 모아서 수행한 뒤 씁니다.
• 적절한 경우 requestAnimationFrame으로 시각적 변경을 예약합니다. 같은 읽기·쓰기 루프를 안으로 옮기는 것만으로는 해결되지 않습니다.

INP를 개선하는 방법: 5가지 실용적인 팁

1. 이벤트 핸들러 최적화

• 긴 작업을 나누고 setTimeout 같은 적절한 방식으로 각 부분 사이에 브라우저에 제어권을 돌려줍니다.
• queueMicrotask는 화면을 그릴 기회를 주지 않습니다. 마이크로태스크가 이어지면 페이지가 계속 차단될 수 있습니다.
• 핸들러의 즉시 작업을 줄이고 빠른 피드백을 표시합니다.

2. JavaScript 번들 크기 줄이기

• Webpack Bundle Analyzer 등을 활용해 사용하지 않는 라이브러리를 제거합니다.
• 코드 분할로 모듈을 동적으로 불러옵니다.

3. 디바운스와 스로틀 사용하기

과제가 허용한다면 비용이 큰 처리에 debounce나 throttle을 적용합니다. 예제에는 debounce 정의 또는 import가 필요합니다. 입력 필드 자체의 반응은 즉시 유지하세요. 300ms는 작업 예약의 예이지 INP 목표가 아닙니다.

const debouncedSearch = debounce((query) => {
	fetchResults(query)
}, 300)

4. 렌더링 최적화

• 불필요한 DOM 복잡성을 줄입니다.
• 선택자가 원인이라고 미리 판단하지 말고 스타일과 레이아웃 비용을 측정합니다.
• 화면 밖 영역에 content-visibility: auto를 검토하고 배치, 포커스, 접근성을 확인합니다.

5. 저사양 장치에서 테스트

가능하면 대표적인 저사양 기기도 테스트하세요. 개발자 도구로 CPU를 4배 느리게 하는 등 CPU와 네트워크를 제한할 수 있습니다. 이는 실험실 조건의 예이며 서비스가 고정 3G 프로필이나 물리적 기기를 사용한다는 뜻이 아닙니다.

수정 결과 확인하기

게시 후 비슷한 조건에서 같은 동작을 반복합니다. 시간과 기능 결과를 모두 확인하세요. 빨라진 장바구니에도 올바른 상품이 담겨야 합니다.

INP Scanner와 Milten의 결과를 조사에 활용할 때는 다음을 기록합니다.

• 검사한 동작과 부족한 근거를 기록합니다.
• 같은 흐름에서 수정 전후를 비교합니다.
• 실제 방문은 해당 데이터로 평가합니다. 좋은 실험실 결과가 모든 사용자의 좋은 INP를 증명하지는 않습니다.

중요한 느린 동작 하나를 고르고 원인 가설을 세워 제한된 수정을 시험하세요. 성공, 실패, 미실행 검사를 구분해 기록합니다.

자세한 내용은 INP 측정 가이드와 INP 최적화 가이드를 참고하세요.