INP 중심으로 다시 보는 Core Web Vitals: 현재 기준, 측정 방법, 개선 우선순위

Google은 2024년 3월에 First Input Delay, 즉 FID를 Interaction to Next Paint, 즉 INP로 교체했어요[86]. 현재 Core Web Vitals의 핵심 3개 지표는 LCP, INP, CLS예요[88]. 그래서 반응성 논의는 이제 과거의 첫 입력 지연보다, 사용자가 페이지를 쓰는 동안 실제로 느끼는 상호작용 지연 전반을 더 직접적으로 다루게 됐어요. 다만 이를 2026년 특정 트렌드로 단정하기보다는, 2024년 3월 이후의 현재 실무 기준으로 이해하는 편이 정확해요.

이 변화의 핵심은 측정 범위가 넓어졌다는 점이에요. FID는 이름 그대로 첫 입력에 집중했지만, INP는 사용자가 한 번 더 누르고, 메뉴를 열고, 검색창에 입력하고, 모달을 닫는 과정까지 포괄적으로 본다는 점이 달라요[89]. 즉 페이지가 초기 로드만 빠른지보다, 사용 중 계속 민첩한지가 더 중요해졌다고 볼 수 있어요. 사용자 경험 평가 관점에서 보면, 이는 단일 순간보다 전체 사용 흐름에 가까운 기준이에요.

Google의 현재 INP 평가 구간은 세 단계예요[87]. 200밀리초 이하이면 좋음, 200밀리초 초과 500밀리초 이하이면 개선 필요, 500밀리초 초과이면 나쁨이에요. 실무에서는 이 숫자가 우선순위를 정하는 기준선 역할을 해요. 예를 들어 사용자 인터랙션이 180ms라면 현상 유지가 가능하지만, 320ms라면 어느 화면과 어떤 상호작용이 지연을 만드는지 바로 분해해서 봐야 해요.

다만 이 숫자를 목표치로만 보고 끝내면 아쉬워요. 같은 280ms라도 검색 자동완성 입력처럼 연속적인 작업에서는 더 답답하게 느껴질 수 있고, 드물게 여는 설정 패널에서는 상대적으로 덜 민감할 수 있어요. 그래서 기준값은 공통 언어로 쓰되, 실제 사용 흐름과 함께 해석하는 것이 실무적으로 더 유용해요. 이 부분은 수치와 제품 맥락을 함께 보는 접근이라고 이해하면 돼요.

INP는 첫 상호작용만 보는 지표가 아니에요[89]. web.dev의 설명대로, 페이지 수명주기 전반에서 발생한 클릭, 탭, 키보드 상호작용의 지연을 측정해요[89]. 그래서 초기 랜딩 페이지가 빨라도, 사용자가 장바구니 버튼을 누를 때 오래 멈춘다거나, 검색 결과 필터를 적용할 때 늦게 바뀌면 INP가 나빠질 수 있어요. 이 점 때문에 INP는 단순 로딩 최적화보다 상호작용 설계와 자바스크립트 실행 방식까지 함께 보게 만들어요.

Google은 INP를 입력 지연, 처리 시간, 표현 지연의 3단계로 나눠 생각하라고 안내해요[94]. 입력 지연은 이벤트가 실행 대기열에 묶여 시작이 늦어지는 구간이고, 처리 시간은 실제 이벤트 핸들러와 연관 작업이 도는 구간이에요. 표현 지연은 처리 후 다음 페인트가 늦게 나타나는 구간이에요. 따라서 문제를 해결하려면 단순히 이벤트 리스너만 줄이기보다, 메인 스레드 점유와 렌더링 지연까지 같이 봐야 해요.

CrUX는 실제 Chrome 사용자에게서 수집한 필드 데이터를 집계하는 소스예요[92]. 즉 내 로컬 개발 환경이나 랩 테스트가 아니라, 현실 사용 환경에서 어떤 경험이 발생했는지 보는 창구라고 이해하면 돼요. 다만 이번 근거 범위에서는 p75나 28일 집계 방식 같은 세부 방법론은 직접 확인되지 않으므로, 여기서는 '실사용 집계 데이터' 수준으로만 말하는 것이 안전해요. 현황 파악은 CrUX, 원인 분석은 다른 도구로 나누는 접근이 적절해요.

Event Timing API는 브라우저가 상호작용 타이밍 데이터를 드러내는 핵심 API예요[91]. 디버깅할 때 어떤 이벤트가 늦었는지, 이벤트 발생부터 시각적 반영까지 어디가 길었는지 더 세밀하게 보는 출발점이 돼요. Chrome 문서는 이 API가 INP 관련 진단 데이터에 중요하다고 설명해요[91]. 즉 CrUX가 '문제가 있다'를 알려준다면, Event Timing은 '어떤 상호작용이 문제인지'를 좁히는 데 도움을 줘요.

LoAF, 즉 Long Animation Frames API는 긴 애니메이션 프레임을 보고해 메인 스레드 작업이 INP에 어떤 부담을 주는지 찾는 데 유용해요[90]. 상호작용 직후 프레임이 길어졌다면, 이벤트 처리 자체보다 렌더링 직전의 레이아웃 계산이나 스크립트 실행이 병목일 수 있어요. 또 Lighthouse는 메인 스레드 작업 최소화, 자바스크립트 실행 시간 감소, 긴 작업 회피 같은 진단을 제공해 반응성 문제를 구조적으로 보게 해줘요[93]. 요약하면 CrUX는 현상, Event Timing은 상호작용 단위 타이밍, LoAF는 프레임 병목, Lighthouse는 전반 진단에 강해요.

전자상거래 상품 목록을 예로 들어볼게요. 사용자가 '가격 낮은 순' 정렬 버튼을 클릭했는데 420ms 뒤에야 목록이 바뀐다면, 기준상 개선 필요 구간이에요[87]. 이때 원인은 한 가지가 아닐 수 있어요. 클릭 직후 대용량 자바스크립트가 이미 메인 스레드를 점유하고 있으면 입력 지연이 길어지고, 정렬 계산이 무겁다면 처리 시간이 길어지며, 목록 재배치와 스타일 계산이 크다면 표현 지연이 늘어나요[94].

다른 예로 검색 입력창 자동완성을 생각해볼 수 있어요. 사용자가 키보드로 5글자를 입력하는 동안 각 입력마다 추천 목록이 늦게 갱신되면, INP는 키보드 상호작용 전반을 반영하기 때문에 체감 품질이 크게 떨어질 수 있어요[89]. 특히 이 사례는 '첫 클릭은 빨랐다'는 이유로 안심할 수 없다는 점을 잘 보여줘요. 페이지 생애주기 전체를 본다는 INP의 성격 때문에, 반복 입력이나 후반부 인터랙션도 중요해요.

공식 근거로 가장 분명한 방향은 3단계 분해예요[94]. 먼저 입력 지연이 길다면, 상호작용 시점에 이미 메인 스레드를 오래 붙잡는 작업이 있는지 의심해야 해요. 처리 시간이 길다면 이벤트 핸들러 내부 로직과 연쇄 업데이트를 살펴봐야 하고, 표현 지연이 길다면 다음 페인트가 왜 늦는지 렌더링 경로를 봐야 해요. 이 접근은 도구 선택에도 바로 연결돼요.

구현 팁 자체는 이번 제공 근거에 모두 직접 연결되지는 않아요. 예를 들어 코드 분할, 분석 스크립트 지연, Web Worker 사용, requestIdleCallback, 이벤트 위임, 가상화, DOM 읽기/쓰기 배치, transform/opacity 기반 애니메이션 같은 방법은 널리 쓰이는 실무 패턴이지만, 여기서는 공식 사실이라기보다 '검토해볼 만한 실전 선택지'로 보는 편이 맞아요. 즉 도구로 병목 유형을 먼저 확인한 뒤, 그 유형에 맞는 최적화 기법을 선택해야 해요. 원인 진단 없이 기법부터 적용하면 효과가 제한적일 수 있어요.

Lighthouse가 메인 스레드 작업, 자바스크립트 실행 시간, 긴 작업을 경고하는 이유는 분명해요[93]. 하지만 모든 상황에서 스크립트 양만 줄인다고 해결되지는 않아요. 예를 들어 클릭 직후 꼭 필요한 UI 피드백을 먼저 주고, 덜 중요한 후속 갱신은 뒤로 미루는 식으로 표현 지연을 낮출 수도 있어요. 반대로 데이터 처리 자체가 핵심이면, 렌더링보다 처리 경로를 더 줄여야 해요.

여기서 중요한 트레이드오프는 정확성과 즉시성의 균형이에요. 한 번에 모든 목록을 재계산해 완전한 상태를 보여주면 처리 시간이 길어질 수 있고, 단계적으로 보여주면 즉시 반응은 좋아져도 구현 복잡도가 커질 수 있어요. 또 시각적 품질을 높이기 위한 애니메이션이 길거나 무거우면 LoAF에서 긴 프레임으로 드러날 수 있어요[90]. 결국 INP는 단순 속도 경쟁이 아니라, 사용자가 '눌렀을 때 바로 반응한다'고 느끼게 만드는 설계 문제예요.

가장 실용적인 출발점은 전체 사이트를 한 번에 고치려 하지 않는 것이에요. 사용량이 높은 화면 1개, 핵심 상호작용 1개를 정하고, 예를 들어 '모바일 상품 필터 열기'나 '검색창 입력' 같은 흐름을 대상으로 잡아요. 그런 다음 CrUX로 실제 문제가 보이는지 확인하고[92], Event Timing과 LoAF, Lighthouse로 원인 층위를 나눠 보세요[90][91][93]. 이렇게 하면 INP를 추상 지표가 아니라 제품 동작의 구체적 병목으로 바꿔 다룰 수 있어요.

정리하면, 지금 확실한 사실은 세 가지예요. 첫째, INP는 2024년 3월부터 FID를 대체한 현재 Core Web Vitals 반응성 지표예요[86]. 둘째, 기준값은 200ms와 500ms로 나뉘고[87], 클릭·탭·키보드 상호작용을 페이지 생애주기 전반에서 본다는 점이 핵심이에요[89]. 셋째, 실사용 현황은 CrUX, 세부 타이밍은 Event Timing, 프레임 병목은 LoAF, 전반 진단은 Lighthouse로 보는 조합이 현재 가장 근거에 맞는 운영 방식이에요[90][91][92][93].