FID가 INP로 바뀐 이유를 알면 블로그 반응 속도 진단이 달라집니다

PageSpeed Insights를 한 번이라도 돌려봤다면 이런 순간이 있었을 거예요. LCP는 뭔지 알겠고 CLS도 대충 잡았는데, 갑자기 INP라는 항목이 등장했을 때 "이거 새로 생긴 건가?" 싶어서 그냥 넘겼던 거요.

2024년 3월 12일, 구글은 Core Web Vitals의 상호작용 지표를 FID에서 INP로 공식 교체했습니다. 이름이 바뀐 게 아니라 측정 원리 자체가 달라졌습니다. 예전 방식으로 진단하면 같은 문제를 못 잡을 수 있어요.

FID는 뭘 놓쳤을까

FID(First Input Delay)는 이름 그대로 "첫 번째 입력"의 지연만 쟀습니다. 사용자가 페이지에서 처음 클릭하거나 키를 눌렀을 때, 브라우저가 처리를 시작하기까지의 대기 시간이요.

문제는 실제 독자의 행동 방식과 안 맞는다는 거였습니다. 독자는 글을 읽다가 중간에 목차를 클릭하고, 댓글을 달고, 공유 버튼을 누릅니다. 첫 클릭 반응이 빨라도 그다음 클릭이 느리면 "이 블로그 느리다"는 인상을 받아요. FID는 그 나머지 상호작용을 전부 무시했습니다.

게다가 FID는 지연 구간만 봤어요. 입력을 받기 시작하는 시점까지의 대기만 쟀고, 이후 브라우저가 실제로 처리해서 화면을 다시 그리기까지 걸린 시간은 포함하지 않았습니다. 사용자가 체감하는 "느림"은 그 처리와 렌더링까지 다 합친 전체 시간인데도요.

구글은 2022년 5월 INP를 실험 지표로 도입하고, 2023년 5월에 2024년 3월 공식 전환을 예고했습니다. 그리고 2024년 3월 12일, INP가 FID를 대체했고 FID는 구글 서치콘솔에서 즉시 삭제됐어요.

FID와 INP, 실제로 뭐가 달라졌나

두 지표를 나란히 놓고 보면 차이가 선명해집니다.

FID는 첫 클릭 한 번을 봤습니다. 그 클릭을 처리하기 시작할 때까지의 대기만요. 임계값은 없었고, 100ms 이하면 Good으로 분류됐습니다.

INP는 세 가지를 바꿨습니다. 첫째, 방문 세션 전체를 봅니다. 사용자가 페이지에 머무는 동안 일어난 모든 클릭, 탭, 키 입력을 기록해요. 둘째, 상호작용의 처음부터 끝까지 다 잽니다. 사용자가 입력한 순간부터 브라우저가 다음 프레임을 그릴 때까지 — 입력 지연 + 처리 시간 + 표시 지연을 합산합니다. 셋째, 75번째 백분위수를 최종 값으로 씁니다. 극단적인 이상값 한 번에 끌려가지 않도록 하는 장치예요.

임계값은 이렇습니다: Good은 200ms 이하, Needs Improvement는 201ms~500ms, Poor는 500ms 초과. 방문자의 75%가 200ms 이내로 반응을 받아야 Good 등급이 됩니다.

PageSpeed Insights에서 INP 값 찾는 법 🔍

pagespeed.web.dev에서 블로그 URL을 입력하면 바로 돌릴 수 있습니다.

필드 데이터 먼저. 결과 화면 상단의 "필드 데이터(Field Data)" 섹션에서 INP 항목을 찾으세요. 실제 방문자가 크롬에서 남긴 CrUX 데이터로, 초록·주황·빨강으로 표시됩니다. 필드 데이터가 아예 없다고 나오면 방문자 수가 적어 아직 집계에 들어갈 만큼 데이터가 쌓이지 않은 상태입니다. 이럴 때는 실험실 데이터의 TBT(Total Blocking Time)를 참고 지표로 쓰세요. TBT가 높으면 메인 스레드가 막혀 있다는 신호이고, INP가 나쁠 가능성이 높습니다.

진단 섹션에서 Long Tasks 확인. "메인 스레드 작업 최소화" 또는 "JavaScript 실행 시간 절감" 항목이 보이면 INP에 직접 영향을 주는 문제입니다. Long Tasks는 메인 스레드를 50ms 이상 점유하는 자바스크립트 작업이에요. 사용자가 클릭하는 순간 이 작업이 실행 중이면, 클릭 처리는 그 뒤로 밀립니다.

모바일 탭으로 재확인. 블로그 독자는 모바일 비중이 높기 때문에 모바일 INP를 기준으로 진단하는 게 현실적이에요. 데스크톱에서 Good으로 나와도 모바일에서 Poor가 되는 경우가 흔합니다.

광고 스크립트가 초기화 중인 순간 클릭이 들어오면

블로그 INP를 망치는 원인 중 가장 흔한 건 서드파티 스크립트입니다.

독자가 글을 절반쯤 읽다가 공유 버튼을 누른다고 상상해보세요. 그 순간 광고 스크립트가 배너를 불러오는 중이라면, 브라우저는 클릭 처리를 그 뒤로 밀어놓습니다. 독자 입장에서는 버튼이 안 눌리는 것처럼 느껴지고, 0.3초쯤 지나서야 반응이 오는 거예요. 그 0.3초가 INP에 그대로 쌓입니다.

댓글 위젯, 소셜 공유 버튼, 광고 스크립트 모두 이 구조로 동작해요. PageSpeed Insights의 "서드파티 코드 영향 줄이기" 항목을 열면 어떤 도메인 스크립트가 메인 스레드를 얼마나 점유하는지 목록으로 보여줍니다.

JS 번들도 흔한 원인이에요. 블로그 테마나 플러그인이 불필요한 자바스크립트를 한꺼번에 로드하면, 방문자가 쓰지 않는 기능 코드까지 포함해 메인 스레드가 오래 막힙니다. "사용하지 않는 자바스크립트 제거" 항목이 뜨면 이 문제입니다.

레이아웃 재계산도 있습니다. 클릭 이벤트 핸들러가 DOM을 변경할 때 브라우저가 강제로 레이아웃을 다시 계산하면 처리 시간이 길어져요. 광고 배너가 콘텐츠 사이에 삽입되거나 댓글 섹션이 동적으로 펼쳐지는 구조에서 발생하기 쉽습니다.

INP 개선, 손 대는 순서

가장 먼저 손 댈 곳은 서드파티 스크립트 지연 로딩이에요. 광고나 댓글 위젯 스크립트를 defer 또는 async 속성으로 로드하거나, 사용자가 해당 섹션에 스크롤할 때까지 로드를 미루는 방식으로 초기 메인 스레드 부담을 줄입니다. 투자 대비 효과가 가장 큰 방법이고요.

그다음은 쓰지 않는 스크립트를 아예 지우는 거예요. 최적화보다 삭제가 효과가 더 큽니다. PageSpeed Insights의 서드파티 목록을 보며 하나씩 필요성을 검토해보세요.

수정 후에는 PageSpeed Insights를 다시 돌립니다. 필드 데이터(CrUX)는 실제 방문자가 쌓는 데이터라 변경 효과가 반영되는 데 수 주가 걸려요. 실험실 데이터의 TBT 감소를 단기 지표로 쓰고, 필드 데이터 INP 개선을 장기 목표로 보는 게 맞습니다.

FID 시대와 달라진 진단의 핵심

FID로 진단할 때는 첫 클릭 반응만 보면 됐습니다. 페이지 로드 직후 메인 스레드가 얼마나 빨리 비워지는지가 핵심이었어요.

INP로 진단할 때는 페이지 전체 수명 동안의 반응성을 봐야 합니다. 초기 로드뿐 아니라 사용자가 계속 상호작용하는 동안 메인 스레드가 적시에 비워지는지가 기준이에요. 블로그 입장에서는 댓글 작성, 공유 버튼 클릭, 목차 탐색 같은 "로드 이후 동작"이 새로운 진단 대상으로 들어온 셈입니다.

INP를 알고 나면 PageSpeed 결과를 보는 눈이 달라집니다. 초록불 하나에 안심했던 FID 시절이 지나고, 이제는 방문자가 페이지를 떠날 때까지 모든 순간이 채점 대상이 됐거든요.

참고자료

• Google Web Dev - Interaction to Next Paint (web.dev/articles/inp)
• Google Search Central - INP becomes a Core Web Vital (web.dev/blog/inp-cwv-march-12)