측정·순위 · 공식 문서
INP 개선 방법, 긴 작업을 찾아 줄이는 점검 순서
INP 는 클릭·탭·키 입력 뒤 화면이 바뀔 때까지의 시간이고, 입력 지연·처리 시간·표시 지연 3구간의 합입니다. 대개 50ms 를 넘는 긴 스크립트 작업이 기본 스레드를 붙잡는 것이 원인이라, 느린 클릭을 찾아 긴 작업을 나누고 처리 코드를 가볍게 합니다.
메뉴 버튼을 눌렀는데 화면이 한참 그대로라 다시 누르게 되는 순간이 INP 가 재는 장면입니다. 숫자는 방문 중 가장 느렸던 반응으로 정합니다.
원인은 대개 스크립트입니다. 다만 어떤 클릭이 느린지 모르면 고칠 코드를 고를 수 없어, 느린 클릭부터 찾습니다.
발견 01
INP 는 3구간의 합이라, 어느 구간이 긴지 보면 고칠 코드가 좁혀집니다
INP is a metric that assesses a page's overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user's visit to a page. The final INP value is the longest interaction observed, ignoring outliers.
INP 는 방문 내내 일어난 모든 클릭·탭·키보드 입력의 지연을 보고 페이지의 전반적인 반응성을 재는 지표다. 최종 값은 튀는 값을 뺀 가장 긴 상호작용이다.
| 구간 | 무엇이 걸리나 | 원문 정의 |
|---|---|---|
| 입력 지연 | 누른 순간부터 클릭 처리 코드가 돌기 시작할 때까지. 다른 스크립트가 기본 스레드를 붙잡고 있으면 길어집니다. | The input delay, which starts when the user initiates an interaction with the page, and ends when the event callbacks for the interaction begin to run.입력 지연은 사용자가 상호작용을 시작한 때부터 그 상호작용의 이벤트 처리 코드가 돌기 시작할 때까지다. |
| 처리 시간 | 클릭·입력 처리 코드가 끝까지 도는 시간. 처리 코드가 하는 일이 많으면 길어집니다. | The processing duration, which consists of the time it takes for event callbacks to run to completion.처리 시간은 이벤트 처리 코드가 끝까지 도는 데 걸린 시간이다. |
| 표시 지연 | 처리가 끝난 뒤 바뀐 화면이 그려질 때까지. 페이지 요소가 많거나 HTML 을 스크립트로 크게 그리면 길어집니다. | The presentation delay, which is the time it takes for the browser to present the next frame which contains the visual result of the interaction.표시 지연은 상호작용의 결과가 담긴 다음 화면을 브라우저가 보여 주기까지 걸린 시간이다. |
| 재는 입력 | 원문 |
|---|---|
| 마우스 클릭 | Clicking with a mouse.마우스로 클릭하기. |
| 터치 화면 탭 | Tapping on a device with a touchscreen.터치 화면 기기에서 탭하기. |
| 키보드 입력 | Pressing a key on either a physical or onscreen keyboard.실제 키보드나 화면 키보드의 키 누르기. |
| 재지 않는 것 | Users may also interact with the page in other ways, like hovering, zooming, or scrolling. These interactions are not observed for the purposes of INP.사용자는 마우스 올리기, 확대, 스크롤로도 페이지와 상호작용한다. 이런 상호작용은 INP 에서 재지 않는다. |
발견 02
반응이 늦는 주된 원인은 50ms 를 넘는 긴 작업이고, 고치는 법은 구간마다 갈립니다
The main thread can only process one task at a time. Any task that takes longer than 50 milliseconds is a long task.
기본 스레드는 한 번에 작업 하나만 처리한다. 50밀리초보다 오래 걸리는 작업이 긴 작업이다.
| 고치는 법 | 회사 사이트에서 하는 일 | 줄이는 구간 | 원문 |
|---|---|---|---|
| 로딩 중 스크립트 줄이기 | 처음에 꼭 필요하지 않은 스크립트는 늦게 받거나 뺍니다. | 입력 지연 | Depending on the size of a script, this work can introduce long tasks on the main thread, which will delay the browser from responding to other user interactions.스크립트 크기에 따라 이 작업이 기본 스레드에 긴 작업을 만들고, 브라우저가 다른 사용자 상호작용에 반응하는 것을 늦춘다. |
| 긴 작업 나누기 | 50ms 를 넘는 작업을 여러 작업으로 쪼개 중간에 입력을 받을 틈을 냅니다. | 입력 지연 | Any task that takes longer than 50 milliseconds is a long task. To prevent the main thread from being blocked for too long, you can break up a long task into several smaller ones.50밀리초보다 오래 걸리는 작업이 긴 작업이다. 기본 스레드가 너무 오래 붙잡히지 않도록 긴 작업을 여러 작은 작업으로 나눌 수 있다. |
| 처리 코드 가볍게 | 클릭 처리 코드에서는 화면 갱신만 하고 저장·집계는 다음 작업으로 미룹니다. | 처리 시간 | The best general advice in optimizing event callbacks is to do as little work as possible in them. If you find this is the case for your website, the next thing you can try is to break up the work in event callbacks into separate tasks.이벤트 처리 코드 최적화의 가장 일반적인 조언은 그 안에서 가능한 한 적은 일을 하는 것이다. 그래도 많다면 처리 코드의 일을 별도 작업으로 나눈다. |
| 스타일 바꾼 직후 읽지 않기 | 같은 작업에서 스타일을 바꾸고 바로 크기·위치를 읽는 코드를 고칩니다. | 처리 시간 | Layout thrashing is a performance bottleneck because by updating styles and then immediately requesting the values of those styles in JavaScript, the browser is forced to do synchronous layout work it otherwise could have waited to perform asynchronously later on after event callbacks have finished running.자바스크립트에서 스타일을 바꾸고 바로 그 값을 읽으면, 브라우저가 나중에 해도 될 레이아웃 작업을 즉시 하게 되어 병목이 된다. |
| 페이지 요소 수 줄이기 | 한 페이지에 요소가 지나치게 많으면 화면 갱신이 무거워집니다. | 표시 지연 | However, when DOMs get very large, rendering work tends to scale with increasing DOM size.DOM 이 매우 커지면 렌더링 작업도 DOM 크기에 따라 늘어난다. |
| 큰 HTML 을 스크립트로 그리지 않기 | 목록·표 같은 큰 덩어리는 서버에서 HTML 로 보냅니다. | 표시 지연 | This is generally fine, so long as you're not rendering large amounts of HTML on the client, which can delay presentation of the next frame.클라이언트에서 큰 HTML 을 그리지만 않으면 대체로 괜찮다. 큰 HTML 을 그리면 다음 화면 표시가 늦어질 수 있다. |
입력 지연의 원인은 스크립트 로딩만이 아닙니다. 원문은 타이머와 겹친 다른 입력까지 꼽았습니다(원문: This could be due to activity occurring on the main thread (perhaps due to scripts loading, parsing and compiling), fetch handling, timer functions, or even from other interactions that occur in quick succession and overlap with one another.)
iframe 안에서 느린 클릭도 그 페이지의 INP 에 들어갑니다. 지도·영상·채팅 위젯이 원인일 때는 그 프레임의 스크립트를 봅니다.
발견 03
느린 클릭은 실제 사용자 데이터로 찾고, 실험실에서 직접 눌러 재현합니다
| 단계 | 원문 |
|---|---|
| 실제 사용자 데이터부터 | Ideally, your journey in optimizing INP will start with field data.INP 최적화는 실제 사용자 데이터에서 시작하는 것이 가장 좋다. |
| CrUX 의 한계 | However, while CrUX can tell you if there is a problem, it can't tell you what caused the problem.CrUX 는 문제가 있는지는 알려 주지만 무엇이 원인인지는 알려 주지 못한다. |
| 자체 측정(RUM) | A RUM solution can help you uncover more details about pages, users, or user interactions that are experiencing responsiveness issues.자체 실사용자 측정(RUM)은 반응성 문제를 겪는 페이지, 사용자, 상호작용을 더 자세히 찾는 데 도움이 된다. |
| 실험실 도구의 한계 | Tools like Lighthouse that load pages in a simulated environment without a user cannot measure INP, as there is no user input.Lighthouse 처럼 사용자 없이 모의 환경에서 페이지를 불러오는 도구는 사용자 입력이 없어 INP 를 잴 수 없다. |
| 실제 데이터가 없을 때 | In the absence of field data, there are some strategies for identifying slow interactions in the lab.실제 사용자 데이터가 없을 때도 실험실에서 느린 상호작용을 찾는 방법이 있다. |
PageSpeed Insights 와 서치 콘솔은 INP 가 나쁘다는 것까지 알려 줍니다. 어떤 버튼이 느린지는 방문자 브라우저에서 직접 모은 데이터나 직접 눌러 보는 시험으로 찾습니다.
한 번 고치면 다음 느린 클릭이 드러납니다(원문: Improving your site's INP is an iterative process.) 자주 쓰는 클릭부터 차례로 손봅니다.
발견 04
INP 는 2024년 3월 12일에 FID 를 대신했고, 첫 입력이 아니라 모든 입력을 봅니다
| 때 | 일 | 원문 |
|---|---|---|
| 바꾼 이유 | FID 가 담지 못하는 반응성이 있었습니다. | First Input Delay (FID) represented the responsiveness aspect of the program, but over time, it became clear that a new metric was needed to capture aspects of interactivity on the web that FID did not.FID 는 반응성을 대표했지만, FID 가 담지 못하는 상호작용의 측면을 담을 새 지표가 필요하다는 것이 분명해졌다. |
| 2024년 1월 31일 공지 | 3월 12일에 INP 가 FID 를 대신한다고 알렸습니다. | Interaction to Next Paint will officially become a Core Web Vital and will replace First Input Delay on March 12.INP 가 3월 12일에 정식 코어 웹 바이탈이 되어 FID 를 대신한다. |
| 3월 12일(2024년) | 서치 콘솔에서 FID 가 빠졌습니다. | FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12. This is exactly what happened to FID as INP became a stable Core Web Vital metric in 2024.INP 가 코어 웹 바이탈이 되는 3월 12일에 구글 서치 콘솔에서 FID 가 빠진다. INP 가 2024년에 안정된 코어 웹 바이탈이 되면서 FID 가 바로 이렇게 바뀌었다. |
| 지금 | INP 가 정식 코어 웹 바이탈입니다. | Interaction to Next Paint (INP) is now a stable Core Web Vital metric, and has officially replaced First Input Delay (FID).INP 는 이제 안정된 코어 웹 바이탈 지표이고, FID 를 공식적으로 대신했다. |
| FID 와 INP 의 차이 | 원문 |
|---|---|
| 후속 지표 | INP is the successor metric to First Input Delay (FID).INP 는 FID 의 후속 지표다. |
| FID 가 잰 것 | While both are responsiveness metrics, FID only measured the input delay of the first interaction on a page.둘 다 반응성 지표지만, FID 는 페이지의 첫 상호작용의 입력 지연만 쟀다. |
| 좋음 기준 | An INP below or at 200 milliseconds means a page has good responsiveness.INP 가 200밀리초 이하이면 페이지의 응답성이 좋다는 뜻이다. |
발견 05
같은 INP 200ms 초과라도 B2B·B2C·B2G 는 느린 클릭의 자리가 다릅니다
예시 ① 제품 필터와 견적 계산기가 있는 기업 사이트(B2B)
사양 필터를 누를 때마다 수백 개 제품 목록을 스크립트로 다시 그립니다. 처리 시간과 표시 지연이 함께 깁니다.
필터 결과는 바뀐 부분만 그리고, 집계·저장은 화면 갱신 뒤로 미룹니다.
예시 ② 광고·분석 태그가 많은 쇼핑몰(B2C)
페이지가 뜨자마자 장바구니 버튼을 누르면 반응이 늦습니다. 로딩 중 외부 태그의 긴 작업 때문에 입력 지연이 깁니다.
꼭 필요한 태그만 남기고, 나머지는 늦게 받도록 순서를 바꿉니다.
예시 ③ 전체 메뉴와 검색창이 무거운 공공기관 누리집(B2G)
전체 메뉴 버튼을 누르면 수백 개 링크를 한 번에 펼칩니다. 페이지 요소가 많아 표시 지연이 깁니다.
메뉴 HTML 은 서버에서 미리 보내고, 열 때는 보이기만 바꿉니다.
그럼 INP 는 어떤 순서로 점검하나요?
- 서치 콘솔 Core Web Vitals 보고서에서 INP 가 「느림」·「개선이 필요함」인 URL 그룹과 예시 URL 을 봅니다.
- 그 페이지에서 방문자가 자주 누르는 버튼·메뉴·필터·입력칸을 적습니다.
- 크롬 개발자 도구 성능 패널을 켜고, 페이지가 뜨는 중과 뜬 뒤에 그 요소들을 직접 눌러 느린 클릭을 찾습니다.
- 느린 클릭의 시간을 3구간으로 나눠 가장 긴 구간을 정합니다.
- 위 고치는 법 표에서 그 구간의 줄을 골라 적용합니다. 긴 작업 나누기가 먼저입니다.
- 고친 뒤 다시 눌러 확인하고, 실제 사용자 값은 서치 콘솔에서 28일 확인을 거칩니다. 절차는 「코어 웹 바이탈 보고서 읽는 법」 편에 자세히 적었습니다.
조사 방법
- web.dev (Google Chrome) 「Interaction to Next Paint (INP)」 (문서 수정일 2025-09-02) · 최종 확인일 2026-10-25 · https://web.dev/articles/inp
- web.dev (Google Chrome) 「Optimize Interaction to Next Paint」 (문서 수정일 2025-09-02) · 최종 확인일 2026-10-25 · https://web.dev/articles/optimize-inp
- web.dev (Google Chrome) 「Optimize long tasks」 (문서 수정일 2024-12-19) · 최종 확인일 2026-10-25 · https://web.dev/articles/optimize-long-tasks
- web.dev (Google Chrome) 「Interaction to Next Paint becomes a Core Web Vital on March 12」 (문서 수정일 2024-01-31) · 최종 확인일 2026-10-25 · https://web.dev/blog/inp-cwv-march-12
- web.dev (Google Chrome) 「Web Vitals」 (문서 수정일 2024-10-31) · 최종 확인일 2026-10-25 · https://web.dev/articles/vitals
- 고치는 법 6가지는 위 문서들이 적은 개선 방법을 줄이는 구간별로 묶은 것입니다. 묶는 방식은 편집 판단입니다.
- 「3월 12일(2024년)」의 해는 공지 글의 작성일과 Web Vitals 문서의 「2024」 문장을 함께 읽은 것입니다.
- 예시 ①②③은 이해를 돕기 위해 만든 가상 상황이며, 실제 기업·기관의 사례가 아닙니다.
- 원문은 영어판(hl=en)이고, 도구·보고서·상태 이름은 같은 문서 한국어판(hl=ko) 표기를 따랐습니다.