코어 웹 바이탈 INP, 2026년 진짜 달라진 3가지

결론부터 말하면 INP(다음 페인트와의 상호작용) 기준값 자체는 2026년에도 바뀌지 않았다. 여전히 200밀리초 이내면 좋음, 500밀리초를 넘으면 나쁨이다. "2026년에 INP 기준이 강화됐다"는 식의 소문은 사실이 아니다.

진짜 바뀐 것은 숫자가 아니라 측정 범위와 확인 도구다. 사파리가 처음으로 INP·LCP를 지원하기 시작했고, 전 세계 "좋음" INP 비율은 원인 불명으로 계속 떨어지고 있으며, 공개 통계를 확인하던 CrUX 대시보드는 아예 사라졌다.

이 소식이 지금 중요한 이유는 간단하다. 임계값 자체가 바뀌었다는 오해가 퍼지면 엉뚱한 곳에 시간을 쓰게 되고, 반대로 실제로 달라진 세 가지를 놓치면 이미 방문자 3분의 1 이상을 차지하는 사파리 사용자의 실제 경험을 계속 못 보고 지나칠 수 있다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• INP 좋음 200밀리초 · 나쁨 500밀리초 기준은 2026년에도 그대로다
• 사파리 26.2(2025년 12월)부터 INP·LCP를 사파리에서도 측정할 수 있게 됐다
• 다만 구글 서치 콘솔·PageSpeed Insights·CrUX는 여전히 크롬 데이터만 반영한다
• 전 세계 "좋음" INP 비율이 2026년 하반기 들어 원인 불명으로 계속 하락 중이다
• 공개 통계를 확인하던 CrUX 대시보드가 폐지되고 대체 도구로 넘어갔다

이 글은 이미 다룬 코어 웹 바이탈이란? 검색 순위를 좌우하는 속도 지표 가이드에서 다시 LCP·INP·CLS의 정의를 반복하지 않는다. 그 글이 세 지표가 무엇인지 처음부터 설명하는 기본 가이드였다면, 이 글은 2026년 들어 실제로 무엇이 바뀌었는지에만 집중한다.

INP 기준값, 2026년에도 정말 그대로인가?

그렇다. 구글 크롬 팀은 2026년 릴리스 노트 어디에서도 INP 임계값·측정 방식·새 지표 추가를 발표한 적이 없다. 여전히 좋음은 200밀리초 이내, 개선 필요는 200밀리초에서 500밀리초 사이, 나쁨은 500밀리초를 넘는 경우다.

구간	기준	의미
좋음	200밀리초 이내	클릭·탭 직후 화면이 즉각 반응
개선 필요	200밀리초 초과, 500밀리초 이내	반응이 다소 늦게 느껴짐
나쁨	500밀리초 초과	눌러도 반응이 없다고 느낄 정도로 느림

계산 방식도 그대로다. 구글은 방문자의 상호작용 중 75번째 백분위수 값을 대표값으로 쓴다. 한 페이지에서 상호작용이 아주 많이 발생하는 경우(예: 무한 스크롤 목록에서 계속 클릭)를 감안해, 상호작용 50회마다 가장 느린 값 1개는 이상치로 보고 계산에서 제외한다.

INP는 "몇 초 만에 화면이 뜨는가"가 아니라 "누르면 얼마나 빨리 반응하는가"를 잰다. LCP를 아무리 잘 잡아도, 버튼을 눌렀을 때 반응이 느리면 INP는 여전히 나쁠 수 있다.

2026년에 임계값 자체가 바뀌었다는 이야기를 어디선가 들었다면, 그건 사실이 아니라는 것부터 확인하고 넘어가자. 아래부터는 실제로 달라진 세 가지를 순서대로 짚는다.

그렇다면 2026년에 실제로 무엇이 바뀌었나?

정리하면 세 가지다. 첫째, 사파리가 INP와 LCP를 처음으로 지원하기 시작했다. 둘째, 전 세계 "좋음" INP 비율이 원인 불명으로 계속 떨어지고 있다. 셋째, 공개 통계를 확인하던 CrUX 대시보드가 폐지됐다.

세 변화 모두 기준값 자체가 아니라 "어떻게, 어디서 데이터를 확인하느냐"에 관한 변화라는 공통점이 있다. 실무자 입장에서는 임계값 뉴스보다 이 세 가지가 훨씬 더 중요하다.

항목	2025년까지	2026년 현재
INP 임계값	좋음 200밀리초 · 나쁨 500밀리초	동일(변화 없음)
사파리 지원	INP·LCP 측정 불가	사파리 26.2부터 측정 가능(CLS는 아직 미지원)
좋음 INP 비율	상대적으로 안정적	매달 소폭 하락 중(원인 불명)
공개 데이터 확인 도구	CrUX 대시보드(룩커 스튜디오)	CrUX 대시보드 폐지, CrUX Vis·History API·BigQuery로 대체

사파리 26.2로 INP·LCP 측정 사각지대가 메워졌다

2025년 12월 출시된 사파리 26.2부터 INP와 LCP를 사파리 브라우저에서도 측정할 수 있게 됐다. 그동안 이 두 지표는 사실상 크로미움 계열 브라우저(크롬, 엣지 등)에서만 측정 가능했다. 웹 표준 진영에서는 이를 두고 "베이스라인 신규 사용 가능(Baseline Newly available)" 상태가 됐다고 발표했다. 크롬·파이어폭스·사파리라는 3대 브라우저 엔진 모두에서 같은 지표를 잴 수 있게 됐다는 뜻이다.

국내 사업자에게는 이 변화가 생각보다 크다. 스탯카운터 집계 기준 2026년 8월 한국의 모바일 운영체제 비중은 안드로이드 약 64%, 아이오에스(아이폰) 약 35%로, 국내 방문자 셋 중 한 명 이상이 사파리 사용자라는 뜻이다. 그동안 이 사용자들의 실제 반응 속도는 확인할 방법이 없었다.

다만 이 변화가 구글 서치 콘솔이나 PageSpeed Insights, CrUX 보고서에 자동으로 반영되는 것은 아니다. 이 세 도구는 여전히 크롬 사용자 데이터만 수집한다. 사파리 사용자의 INP·LCP를 확인하려면 GA4의 웹 바이탈 리포트나 데이터독·뉴렐릭 같은 별도의 RUM(실사용자 모니터링) 도구, 혹은 구글의 web-vitals 자바스크립트 라이브러리를 직접 붙여 자체 수집하는 방법을 써야 한다. GA4 자체 설정이 익숙하지 않다면 GA4 완벽 가이드를 먼저 참고해도 좋다.

한 가지 더 짚을 것은 사파리가 아직 CLS(누적 레이아웃 이동)는 지원하지 않는다는 점이다. 세 지표 중 두 개만 먼저 열린 셈이라, 사파리 사용자의 레이아웃 흔들림 정도는 여전히 크롬 데이터로 짐작하는 수밖에 없다.

좋은 예와 나쁜 예로 정리하면 이렇다. 나쁜 예는 "우리 서치 콘솔 코어 웹 바이탈 보고서에는 문제가 없으니 속도는 괜찮다"고 단정하는 것이다. 이 보고서는 크롬 사용자만 반영하므로, 아이폰 사용자 비중이 높은 업종(패션, 뷰티, 프리미엄 상품군 등)일수록 실제 체감 속도와 차이가 클 수 있다. 좋은 예는 GA4나 RUM 도구로 사파리 사용자의 INP·LCP를 별도로 확인하고, 두 데이터를 함께 놓고 판단하는 것이다.

서치 콘솔 코어 웹 바이탈 보고서가 전부 초록불이라고 방심하지 말자. 그 보고서는 크롬 사용자만 보고 있는 것이지, 사파리 사용자까지 다 괜찮다는 뜻은 아니다.

사파리 데이터를 놓치면 실제로 어떤 문제가 생기나?

흔히 벌어지는 상황을 예로 들면 이렇다. 온라인 편집숍을 운영하는 사업자가 매달 서치 콘솔 코어 웹 바이탈 보고서를 확인하는데, 몇 달째 URL 대부분이 "좋음"으로 표시된다. 이 사업자는 "우리 사이트는 속도 문제가 없다"고 판단하고 다른 업무로 넘어간다.

문제는 이 보고서가 크롬 사용자만 반영한다는 데 있다. 패션·뷰티처럼 아이폰 사용자 비중이 평균보다 높은 업종이라면, 방문자의 상당수가 서치 콘솔에 아예 잡히지 않는 사파리 사용자일 수 있다. 이 사용자들이 실제로는 상품 상세 페이지에서 이미지 갤러리를 넘길 때마다 버벅임을 겪고 있었다 해도, 그 데이터는 지금까지 어디에도 나타나지 않았을 가능성이 크다.

나쁜 예는 서치 콘솔 보고서 하나만 보고 "속도는 이미 괜찮다"고 결론 내린 뒤 더 이상 점검하지 않는 것이다. 좋은 예는 사파리 26.2 업데이트를 계기로 GA4나 RUM 도구에 웹 바이탈 이벤트를 새로 추가해, 사파리 사용자의 INP 값이 크롬 사용자와 얼마나 차이 나는지 한 번은 직접 비교해 보는 것이다.

가상의 사례로 그림을 그려 보면 이렇다. 패션 쇼핑몰 A(가상 사례)의 서치 콘솔 코어 웹 바이탈 보고서에는 INP가 180밀리초로 좋음 구간에 있었다. 그런데 GA4에 웹 바이탈 이벤트를 새로 추가해 사파리 사용자만 따로 필터링해 보니, 같은 페이지의 INP가 340밀리초로 개선 필요 구간에 있었다. 원인을 찾아보니 상품 상세 페이지의 이미지 캐러셀 스크립트가 유독 사파리에서 무겁게 동작하고 있었던 것이다. 크롬 데이터만 봤다면 끝까지 몰랐을 문제였다.

두 값의 차이가 크지 않다면 안심해도 된다. 하지만 사파리 쪽 INP가 눈에 띄게 나쁘다면, 그동안 서치 콘솔만 보고 "문제없다"고 여겨 온 판단 자체를 다시 봐야 한다. 보이지 않던 문제는 없는 문제가 아니라, 아직 측정되지 않았던 문제였을 뿐이다.

사파리 데이터를 직접 수집하려면 어떻게 시작하나?

개발 리소스가 있다면 구글이 공식 제공하는 web-vitals 자바스크립트 라이브러리를 페이지에 붙이는 것이 가장 확실한 방법이다. 이 라이브러리는 사파리를 포함한 모든 주요 브라우저에서 LCP·INP·CLS 값을 읽어 원하는 곳으로 전송할 수 있게 해 준다.

기본적인 사용법은 다음과 같다.

import {onINP, onLCP, onCLS} from 'web-vitals';

function sendToAnalytics(metric) {
  // GA4 커스텀 이벤트로 전송하는 예시
  gtag('event', metric.name, {
    value: Math.round(metric.value),
    metric_id: metric.id,
    metric_rating: metric.rating, // 'good' | 'needs-improvement' | 'poor'
  });
}

onINP(sendToAnalytics);
onLCP(sendToAnalytics);
onCLS(sendToAnalytics);

이렇게 수집한 데이터를 GA4에서 브라우저별로 나눠 보면, 크롬 사용자와 사파리 사용자의 INP 값을 직접 비교할 수 있다. 개발자가 없는 소규모 사업자라면 처음부터 코드를 직접 짜기보다는, 이미 이런 기능을 갖춘 RUM 서비스(데이터독, 뉴렐릭, 혹은 국내 웹 에이전시가 제공하는 모니터링 플러그인)를 붙이는 방법도 현실적이다.

RUM 도구를 새로 고를 때는 이미 쓰고 있는 분석 도구와의 연동성부터 확인하는 것이 좋다. GA4를 이미 쓰고 있다면 별도 유료 도구를 새로 붙이기보다, GA4 안에서 커스텀 이벤트로 웹 바이탈을 태깅하는 쪽이 관리 부담도 적고 비용도 들지 않는다.

코드를 직접 짤 여력이 없다면 이 단계는 건너뛰어도 괜찮다. 다만 최소한 GA4에 웹 바이탈 이벤트를 태깅하는 정도는 개발 담당자에게 한 번쯤 요청해 볼 만한 가치가 있다.

업종별로 사파리 데이터 확인 우선순위는 다르다

모든 업종이 사파리 데이터를 똑같은 긴급도로 챙길 필요는 없다. 아이폰 사용자 비중과 페이지의 상호작용 빈도를 함께 고려해 우선순위를 정하는 것이 현실적이다.

업종	사파리 확인 긴급도	이유
패션·뷰티 커머스	높음	아이폰 사용자 비중이 평균보다 높고, 이미지 갤러리·옵션 선택 등 상호작용이 많음
프리미엄·명품 브랜드	높음	구매력이 높은 고객층에서 아이폰 비중이 특히 높은 경향
병원·의료 홈페이지	중간	예약·상담 폼 클릭이 핵심 상호작용이라 반응성이 중요함
B2B·기업 홈페이지	낮음	상호작용 자체가 적고 데스크톱 방문 비중이 높은 편
로컬 매장(식당·미용실 등)	중간	지도·전화 걸기 버튼처럼 단순 상호작용 위주라 임팩트는 크지 않지만 확인은 필요

패션·뷰티나 프리미엄 브랜드처럼 상세 페이지 안에서 이미지를 넘기고, 옵션을 고르고, 장바구니에 담는 상호작용이 잦은 업종일수록 사파리 데이터의 가치가 크다. 상호작용이 많다는 것은 그만큼 INP가 나빠질 여지도 많다는 뜻이기 때문이다.

반대로 상호작용이 단순한 로컬 매장이나 정보 전달 위주의 B2B 홈페이지는 상대적으로 우선순위가 낮다. 다만 우선순위가 낮다고 아예 확인하지 않아도 된다는 뜻은 아니며, 예약 폼이나 전화 버튼처럼 핵심 전환 지점만이라도 사파리 기준으로 한 번은 점검해 두는 편이 안전하다.

표에 나온 업종 평균보다 더 정확한 기준이 필요하다면, GA4의 "기술" 보고서에서 운영체제별 방문자 수를 직접 확인하면 된다. 업종 평균치는 어디까지나 참고용이고, 우리 사이트의 실제 방문자 데이터를 보는 것이 우선순위를 정하는 데 훨씬 정확하다.

전 세계 "좋음" INP 비율이 계속 떨어지고 있다

두 번째 변화는 수치로 확인된다. 크롬 UX 리포트 기준, 전 세계 "좋음" INP 비율을 가진 사이트 비중이 2026년 하반기 들어 매달 조금씩 낮아지고 있다. 크롬 팀은 이 흐름을 공식 릴리스 노트에서 "우려스럽다"고 언급하면서도, 뚜렷한 원인은 아직 특정하지 못했다고 밝혔다.

월(2026년)	좋음 INP 비율	전월 대비
6월	85.9%	하락 0.8퍼센트포인트
7월	85.7%	하락 0.2퍼센트포인트
8월	85.3%	하락 0.5퍼센트포인트

같은 기간 LCP는 상반기 하락 이후 부분적으로 회복해 8월 기준 약 68.1%가 "좋음" 구간에 있고, CLS는 약 81.5%로 비교적 안정적인 편이었다. 세 지표를 모두 통과한 전체 코어 웹 바이탈 "좋음" 비율은 8월 기준 약 55.6%로 집계됐다.

원인이 공식적으로 밝혀지지는 않았지만, 업계에서는 챗봇 위젯이나 광고 스크립트처럼 무거운 서드파티 자바스크립트가 계속 늘어난 것을 유력한 배경으로 추정한다. 다만 이는 어디까지나 실무자들의 정황적 추정이며, 크롬 팀 차원의 공식 결론은 아니라는 점은 분명히 해 둘 필요가 있다.

한두 달 수치가 떨어졌다고 우리 사이트만의 문제로 오해하지 말자. 전 세계적인 흐름이라는 점을 먼저 확인한 다음, 우리 사이트의 원인을 따로 점검하는 순서가 맞다.

실무적으로는 이 하락 추세가 오히려 기회일 수도 있다. 전체적으로 INP가 나빠지는 흐름이라면, 반대로 INP를 잘 관리하는 사이트는 상대적으로 더 눈에 띄기 쉬워진다는 뜻이기도 하다. 무거운 서드파티 스크립트 정리나 이미지·폰트 최적화를 다시 점검하려면 CDN과 웹사이트 속도 SEO 가이드도 함께 참고할 만하다.

전체 통과율이 8월 기준 약 55.6%라는 것은, 다르게 말하면 나머지 44.4%에 해당하는 사이트는 세 지표 중 하나 이상에서 아직 개선 여지가 있다는 뜻이기도 하다. 절반에 가까운 경쟁 사이트가 코어 웹 바이탈을 완전히 통과하지 못했다는 사실은, 지금 이 지표를 착실히 관리하는 쪽에는 오히려 상대적인 기회로 읽을 수 있다.

CrUX 대시보드가 사라졌다 — 이제 어디서 확인해야 하나?

세 번째 변화는 확인 도구 자체의 변화다. 룩커 스튜디오 기반으로 운영되던 공개용 CrUX 대시보드가 2025년 11월 말 이후 완전히 종료됐다. 구글은 2025년 9월 크롬 개발자 블로그를 통해 이 사실을 미리 공지했다.

구글이 밝힌 폐지 이유는 인프라 문제였다. 매달 둘째 주 화요일 새 데이터가 갱신될 때마다 대시보드를 떠받치던 연결 커넥터에서 반복적으로 장애가 발생했고, 대규모 사용을 감당하기에는 애초에 적합한 기술 구조가 아니었다는 것이 구글의 설명이다.

필요한 데이터	대체 도구
지금 이 순간의 최신 필드 데이터	PageSpeed Insights, 구글 서치 콘솔 코어 웹 바이탈 보고서
최근 수개월 추세(주간 단위)	CrUX Vis
실시간·프로그래밍 방식 조회	CrUX History API
장기 보관·커스텀 분석	BigQuery의 CrUX 공개 데이터셋

다행히 이 폐지는 서치 콘솔이나 PageSpeed Insights 사용에는 영향을 주지 않는다. 두 도구 모두 최신 28일치 롤링 데이터를 보여주는 별도 서비스이기 때문이다. 서치 콘솔에서 사이트 데이터를 점검하는 기본기가 아직 익숙하지 않다면 서치 콘솔 크롤링 통계 보고서 읽는 법도 함께 살펴보면 좋다. 없어진 것은 어디까지나 과거 추이를 무료로 조회하던 별도의 공개 대시보드였고, 이제는 CrUX Vis나 히스토리 API로 그 역할을 대신해야 한다는 점만 기억하면 된다.

경쟁사 비교 목적으로 CrUX 데이터를 활용해 온 사업자라면 이 변화가 더 크게 느껴질 수 있다. 예전에는 대시보드에 경쟁사 도메인을 나란히 입력해 몇 달 치 추이를 한눈에 비교하는 것이 가능했는데, 지금은 CrUX Vis나 History API로 도메인을 하나씩 조회해야 하는 번거로움이 늘었다. 다만 데이터 자체가 사라진 것은 아니므로, 확인하는 습관만 새로 들이면 큰 문제는 아니다.

앞으로 사파리에 CLS까지 추가될 가능성은?

아직 공식 일정은 없지만, 업계에서는 사파리가 조만간 CLS까지 지원할 가능성을 열어 두고 있다. LCP와 INP가 먼저 열린 것을 감안하면, 세 번째 지표인 CLS도 시간문제일 뿐이라는 관측이 나온다. 다만 이는 어디까지나 전망일 뿐이며, 애플이 CLS 지원에 대한 공식 일정을 발표한 적은 없다는 점은 분명히 해 둘 필요가 있다.

CLS까지 사파리에서 지원되면, 그때는 정말로 3대 브라우저 엔진에서 코어 웹 바이탈 세 지표를 모두 확인할 수 있는 환경이 완성된다. 지금 GA4나 RUM 도구에 INP·LCP 수집 체계를 미리 만들어 두면, CLS가 추가됐을 때도 같은 구조에 지표 하나만 얹으면 되므로 그때 가서 처음부터 새로 설계하는 수고를 덜 수 있다.

지금 당장 CLS까지 사파리에서 볼 수는 없지만, INP·LCP 수집 체계를 미리 갖춰 두는 것 자체가 다음 변화에 대비하는 가장 효율적인 방법이다.

이 변화들이 실제 검색 순위에 어떤 영향을 주나?

결론부터 말하면 이 세 가지 변화가 검색 순위 알고리즘 자체를 바꾸지는 않는다. 코어 웹 바이탈은 여전히 콘텐츠 품질이나 검색 의도 부합도보다 후순위인 보조 신호이고, 이 점은 2026년에도 달라지지 않았다.

다만 순위에 직접 반영되지 않는다고 해서 무시해도 된다는 뜻은 아니다. 구글이 순위 계산에 쓰는 코어 웹 바이탈 데이터는 여전히 크롬 기반 CrUX이므로, 사파리 26.2로 사파리 데이터를 볼 수 있게 됐다고 해서 서치 콘솔의 순위 신호 계산 방식이 함께 바뀌는 것은 아니다. 이 부분은 오해하기 쉬운 지점이라 짚어 둘 필요가 있다.

그렇다면 왜 신경 써야 할까. 이유는 순위가 아니라 매출과 이탈률에 있다. 검색 알고리즘이 사파리 데이터를 직접 보지 않더라도, 실제 사파리 사용자는 이 사이트에서 매일 물건을 사고 문의를 남긴다. 반응이 느린 페이지에서는 이 사용자들이 그냥 이탈해 버릴 뿐이고, 이는 검색 순위와 무관하게 사업 손해로 이어진다.

순위 신호로서의 가치와 실제 고객 경험으로서의 가치를 구분해서 봐야 한다. 서치 콘솔 보고서는 전자를 보여주고, GA4나 RUM 도구는 후자를 보여준다. 2026년 이후로는 이 두 가지를 함께 챙겨야 한다는 점이 이전과 달라진 부분이다.

검색 순위만 보고 안심하는 것과, 실제 방문자 경험까지 챙기는 것은 다른 문제다. 코어 웹 바이탈은 원래 이 둘을 최대한 가깝게 만들기 위해 만들어진 지표라는 점을 기억하면 판단이 쉬워진다.

AI 검색(챗GPT, 구글 AI 모드 등)에서 링크를 타고 들어온 방문자에게도 같은 논리가 그대로 적용된다. AI 검색이 사이트를 추천해 트래픽을 보내 준다 해도, 정작 도착한 페이지의 반응이 느리면 그 트래픽은 전환으로 이어지지 못하고 그대로 흩어진다. 코어 웹 바이탈은 유입 경로가 일반 검색이든 AI 검색이든 상관없이, 도착한 이후의 경험을 책임지는 지표라는 점은 변하지 않는다.

이 세 가지 변화, 사이트 운영자는 무엇을 해야 하나?

정리하면 임계값이 아니라 확인 방법을 바꿔야 한다. 아래 체크리스트로 오늘 바로 점검할 수 있다.

• 서치 콘솔·PageSpeed Insights만 보지 말고, GA4나 RUM 도구로 사파리 사용자의 INP·LCP도 함께 확인한다. 두 데이터를 나란히 놓고 차이가 큰지부터 살펴본다.
• 아이폰 사용자 비중이 높은 업종(패션·뷰티·프리미엄 상품군)이라면 사파리 데이터 확인을 우선순위에 둔다. 이미지 갤러리, 옵션 선택, 장바구니 버튼처럼 상호작용이 많은 페이지부터 점검한다.
• CLS는 아직 사파리에서 확인할 수 없으므로, 크롬 데이터만으로 전체를 판단하지 않는다. 레이아웃 흔들림은 당분간 크롬 기준으로 보수적으로 관리하는 수밖에 없다.
• 과거 CrUX 대시보드 즐겨찾기를 쓰고 있었다면 CrUX Vis로 북마크를 옮긴다. 도메인만 입력하면 별도 설정 없이 바로 주간 추이를 볼 수 있다.
• "2026년 INP 기준이 강화됐다"는 이야기가 들리면 출처부터 확인한다. 크롬 개발자 블로그나 web.dev 공식 문서에 없는 내용이라면 근거 없는 소문일 가능성이 높다.
• 챗봇 위젯·광고 스크립트 등 무거운 서드파티 스크립트부터 우선 점검한다. 최근에 새로 추가한 위젯이나 배너가 있다면 그 시점 전후로 INP 변화를 비교해 본다.
• 한두 달 수치 변동에 일희일비하지 말고, 최소 2개월에서 3개월 추세로 판단한다. 전 세계적으로도 하락 추세가 이어지고 있는 만큼, 우리 사이트만의 문제인지부터 구분해서 봐야 한다.

결국 2026년의 핵심은 "숫자를 더 엄격하게 맞추라"가 아니라 "더 넓은 범위의 사용자를 놓치지 말라"는 것이다. 크롬 사용자만 보고 안심하던 방식에서, 사파리 사용자까지 챙기는 방식으로 넘어가야 할 시점이다.

이 체크리스트, 어떤 순서로 실행하면 좋을까?

막막하다면 아래 순서대로 4주 안에 끝내는 것을 목표로 삼아 보자.

1주차, 현황 파악. 서치 콘솔 코어 웹 바이탈 보고서에서 현재 상태를 스크린샷으로 남겨 두고, GA4에 웹 바이탈 이벤트 태깅이 되어 있는지 확인한다. 안 되어 있다면 이번 주 안에 개발 담당자에게 요청한다.

2주차, 사파리 데이터 확보. web-vitals 라이브러리나 RUM 도구를 통해 사파리 사용자의 INP·LCP 데이터를 수집하기 시작한다. 데이터가 유의미하게 쌓이기까지 최소 1주에서 2주 정도는 필요하므로, 이 시점에 미리 심어 두는 것이 중요하다.

3주차, 비교와 진단. 쌓인 사파리 데이터와 기존 크롬 데이터를 나란히 비교한다. 차이가 크게 벌어지는 페이지가 있다면 PageSpeed Insights의 실험실 데이터로 원인을 진단한다.

4주차, 개선과 재확인. 진단된 원인(무거운 서드파티 스크립트, 캐러셀·갤러리 스크립트 등)을 우선순위대로 개선하고, 2주 뒤 다시 필드 데이터를 확인해 실제로 좋아졌는지 점검한다.

한 번에 모든 페이지를 완벽하게 만들려 하지 말고, 방문이 가장 많은 핵심 페이지 몇 개부터 이 로드맵을 적용해 보는 것이 현실적이다.

체크리스트를 실행할 때 자주 놓치는 함정은?

가장 흔한 함정은 사파리 데이터를 한 번만 확인하고 끝내는 것이다. 사파리 26.2 업데이트는 이제 막 퍼지기 시작한 단계라, 초기 몇 주간 수집된 데이터는 표본이 적어 들쭉날쭉할 수 있다. 한 번의 스냅샷으로 결론 내리기보다, 최소 한 달 이상 데이터를 쌓은 뒤 판단하는 것이 안전하다.

두 번째 함정은 사파리 데이터가 나쁘게 나왔다고 곧바로 대대적인 리뉴얼부터 검토하는 것이다. 대부분의 경우 원인은 크롬에서도 이미 존재하던 무거운 스크립트 하나가 사파리에서 더 두드러지게 나타난 것뿐이다. 전면 개편보다 원인이 되는 스크립트 하나를 지연 로딩하거나 제거하는 것으로 해결되는 경우가 많다.

세 번째 함정은 CrUX 대시보드 폐지 소식만 보고 필요 이상으로 불안해하는 것이다. 앞서 살펴봤듯 서치 콘솔과 PageSpeed Insights는 전혀 영향을 받지 않으며, 없어진 것은 보조적으로 쓰던 별도 공개 도구 하나일 뿐이다.

네 번째 함정은 체크리스트의 모든 항목을 한꺼번에 처리하려는 것이다. 여러 가지를 동시에 바꾸면 나중에 무엇이 실제로 효과가 있었는지 구분하기 어려워진다. 항목 하나를 적용한 뒤 필드 데이터가 갱신되는 2주에서 4주 정도를 기다렸다가 다음 항목으로 넘어가는 순서가 원인 파악에 훨씬 유리하다.

새로운 도구나 데이터가 생겼다고 매번 전면적으로 대응할 필요는 없다. 지금 우리 사이트에 실제로 영향을 주는 부분이 무엇인지부터 가려내는 것이 먼저다.

자주 묻는 질문

INP 기준이 2026년에 더 엄격해졌다는 게 사실인가요?

아니다. 크롬 팀이 2026년 릴리스 노트에서 INP 임계값이나 계산 방식을 바꿨다고 발표한 적은 없다. 좋음 200밀리초, 나쁨 500밀리초 기준은 그대로이며, 75번째 백분위수를 쓰는 방식도 동일하다.

사파리 26.2로 업데이트하지 않은 사용자는 어떻게 되나요?

해당 사용자의 데이터는 아직 반영되지 않는다. 브라우저 업데이트는 점진적으로 퍼지기 때문에, 사파리 사용자 전체의 INP·LCP 데이터가 곧바로 다 잡히는 것은 아니다. 최근에 기기를 업데이트한 사용자부터 순차적으로 반영된다고 보면 된다.

CrUX 대시보드가 없어지면 서치 콘솔 코어 웹 바이탈 보고서도 못 쓰나요?

아니다. 서치 콘솔과 PageSpeed Insights는 CrUX 대시보드와는 별개의 서비스라 영향을 받지 않는다. 없어진 것은 과거 추이를 무료로 조회하던 별도의 공개 대시보드일 뿐이다.

INP 좋음 비율이 떨어지는 이유가 정확히 뭔가요?

구글도 아직 공식적으로 원인을 특정하지 못했다. 업계에서는 챗봇 위젯이나 광고 스크립트 같은 무거운 서드파티 자바스크립트 증가를 유력한 배경으로 추정하지만, 이는 정황적 추정이지 크롬 팀의 공식 결론은 아니다.

우리 사이트 INP가 나쁘면 검색 순위가 바로 떨어지나요?

그렇게 단정할 수는 없다. 코어 웹 바이탈은 절대적인 순위 요소라기보다, 콘텐츠 품질이 비슷한 경쟁 페이지 사이에서 우선순위를 가르는 신호에 가깝다. 다만 순위와 무관하게 반응이 느린 사이트는 방문자 이탈로 실제 매출에 영향을 준다.

사파리 사용자의 INP를 확인하려면 구체적으로 무엇을 써야 하나요?

GA4의 웹 바이탈 관련 이벤트, 데이터독·뉴렐릭 같은 RUM 도구, 또는 구글이 제공하는 web-vitals 자바스크립트 라이브러리를 직접 붙여 자체 수집하는 방법이 있다. 예산이 크지 않은 사업자라면 GA4에 웹 바이탈 이벤트를 태깅하는 방식부터 시작하는 것이 현실적이다.

CrUX Vis와 BigQuery, 뭐가 다른가요?

CrUX Vis는 별도 설정 없이 도메인만 입력하면 바로 그래프를 보여주는 웹 도구이고, BigQuery는 SQL로 직접 데이터를 조회해야 하는 대신 훨씬 세밀한 커스텀 분석이 가능하다. 대부분의 사업자는 CrUX Vis만으로 충분하고, BigQuery는 개발 리소스가 있는 팀에게 더 적합하다.

사파리 26.2 업데이트가 국내 사용자 대부분에게 반영되려면 얼마나 걸리나요?

정확한 기간이 공식적으로 발표되지는 않았지만, 브라우저 업데이트는 통상 몇 달에 걸쳐 서서히 퍼진다. 자동 업데이트를 켜 둔 아이폰 사용자는 비교적 빠르게 반영되지만, 수동으로 업데이트하는 사용자도 있어 전체 사용자에게 완전히 반영되기까지는 시간이 걸린다고 보는 것이 안전하다.

INP 말고 2026년에 새로 생긴 코어 웹 바이탈 지표가 있나요?

없다. 2026년에도 코어 웹 바이탈은 여전히 LCP·INP·CLS 세 가지 그대로다. 네 번째 지표가 추가됐다거나 기존 지표가 다른 지표로 교체됐다는 이야기 역시 사실이 아니다.

개발자가 없는 소규모 사업자도 이 변화에 대응해야 하나요?

전부 직접 대응할 필요는 없지만, 아이폰 사용자 비중이 높은 업종이라면 한 번쯤은 확인해 보는 것이 좋다. GA4에 웹 바이탈 이벤트를 태깅하는 작업은 개발 지식이 없어도 대행사나 프리랜서에게 비교적 짧은 시간 안에 맡길 수 있는 수준의 작업이다. 사이트 전체를 개편하는 것보다 훨씬 적은 비용으로 현황부터 확인할 수 있다.

사파리 26.2가 나온 뒤에는 CrUX 데이터에도 사파리 사용자가 포함되나요?

아니다. CrUX는 여전히 크롬 브라우저 사용자 데이터만 수집하는 구글의 공식 데이터셋이다. 사파리 26.2가 지원하기 시작한 것은 사파리 자체의 측정 기능이며, 이 데이터가 구글의 CrUX 데이터셋에 합쳐지는 것은 아니다. 두 가지를 혼동하지 않아야 한다.

결국 2026년 코어 웹 바이탈 INP를 둘러싼 변화는 "더 어려운 기준을 통과하라"는 압박이 아니라 "더 많은 손님의 실제 경험을 놓치지 말라"는 신호에 가깝습니다. 코어 웹 바이탈 INP는 숫자 기준이 아니라 누가 측정되고, 어디서 확인하느냐가 2026년의 진짜 화두입니다. 사파리 사용자까지 포함해 실제 방문자의 체감 속도를 챙기고 계신지, 지금 한번 점검해 보시길 권해 드립니다. 사이트 속도 진단부터 개선까지 한 번에 정리하고 싶으시다면 이루웹의 SEO 최적화 홈페이지 제작 서비스가 도움을 드릴 수 있습니다. 지금 우리 사이트의 코어 웹 바이탈 상태가 궁금하시다면 이루웹 상담 문의로 편하게 여쭤봐 주시길 바랍니다.