스마트폰으로 어떤 사이트의 메뉴를 눌렀는데 화면이 잠깐 굳어버린 경험, 한 번쯤 있으시죠? 그 짧은 순간이 실제로 고객을 잃는 결정적 원인이 됩니다.
홈페이지 제작을 고민 중인 마케팅 담당자나 경영자라면, 디자인과 콘텐츠만큼 중요한 기술 지표가 있다는 사실을 꼭 알아야 합니다. 바로 구글이 공식 검색 순위 기준으로 삼고 있는 INP(Interaction to Next Paint) 입니다.
INP란 "사용자가 화면을 탭하거나 클릭한 순간부터, 브라우저가 그 결과를 화면에 실제로 그려내기까지 걸리는 시간"입니다.
쉽게 비유하면 이렇습니다. 카페에서 주문 버튼을 눌렀는데 직원이 5초 동안 아무 반응도 없다면 손님은 '고장났나?' 하고 자리를 뜹니다. 웹사이트도 똑같습니다. 클릭 후 반응이 늦으면 사용자는 사이트가 망가진 것으로 판단하고 뒤로 가기를 누릅니다.
| 등급 | 기준 시간 | 의미 |
|---|---|---|
| Good (좋음) | 200ms 이하 | 즉각 반응, 사용자 만족 |
| Needs Improvement | 201ms ~ 500ms | 개선 필요, 감점 위험 |
| Poor (나쁨) | 500ms 초과 | 구글 감점 + 사용자 이탈 |
💡 핵심 포인트: 500ms는 단 0.5초입니다. 눈 깜짝할 사이지만, 이 짧은 지연이 구글 검색 순위와 고객 이탈률을 동시에 악화시킵니다.
INP는 다음 세 구간의 합산으로 계산됩니다.
① 입력 지연 (Input Delay) 사용자가 탭한 순간부터 브라우저가 그 신호를 받아들이기까지의 대기 시간입니다. 브라우저가 다른 무거운 작업을 처리 중이면 이 시간이 길어집니다.
② 처리 시간 (Processing Time) 클릭에 연결된 자바스크립트 코드가 실행되는 시간입니다. 코드가 복잡하거나 무거울수록 길어집니다.
③ 표시 지연 (Presentation Delay) 처리 결과를 화면에 실제로 그려내는 시간입니다. 화면 구조 계산(레이아웃)이 복잡할수록 지연됩니다.
이전에는 FID(First Input Delay) 라는 지표를 사용했습니다. FID는 사용자의 '첫 번째' 클릭에 대한 대기 시간만 측정했습니다.
반면 INP는 페이지를 사용하는 동안 발생하는 모든 클릭, 탭, 키보드 입력을 종합적으로 평가합니다. 처음 클릭은 빨라도 장바구니 추가 버튼이나 폼 제출 버튼에서 느리면 INP 점수가 나빠집니다. 훨씬 현실적인 지표인 셈입니다.
홈페이지를 오픈한 뒤 INP 문제를 발견하면, 프론트엔드 구조 자체를 뜯어고쳐야 하는 경우가 많습니다. 처음 제작할 때 INP를 기준으로 설계하면 이 리스크를 원천 차단할 수 있습니다.
구글 통계에 따르면 모바일 사용자의 약 53%는 페이지 반응이 3초를 넘으면 이탈합니다. 그리고 Web Almanac 데이터 기준으로 전 세계 모바일 페이지의 약 52%가 코어 웹 바이탈 기준을 통과하지 못하고 있습니다. 경쟁사 절반이 기준 미달이라는 뜻이기도 합니다. 지금 INP를 잡으면 검색 순위와 사용자 경험에서 동시에 앞서나갈 수 있습니다.
먼저 내 사이트의 현재 상태를 파악해야 합니다.
⚠️ 주의: 내 PC에서 측정한 Lighthouse 점수가 높아도, 실제 저사양 스마트폰 사용자의 현장 데이터(Field Data)는 크게 다를 수 있습니다. 반드시 Search Console의 실사용자 데이터를 기준으로 판단하세요.
긴 작업(Long Task) 분할하기
자바스크립트 코드 하나가 50ms 이상 실행되면 브라우저가 클릭 신호를 처리하지 못합니다. 이를 '긴 작업(Long Task)'이라고 합니다.
최신 기법으로는 scheduler.yield() API를 활용해 브라우저에 주기적으로 제어권을 돌려주는 방식을 씁니다. 크롬 129 버전 이상에서 정식 지원됩니다.
async function performHeavyWork() {
for (let i = 0; i < largeDataset.length; i++) {
processItem(largeDataset[i]);
if (i % 100 === 0) {
await scheduler.yield(); // 브라우저에 양보
}
}
}서드파티 스크립트 정리하기
Google Analytics, 채팅 위젯, 히트맵 도구(Hotjar 등)는 페이지 전체의 클릭을 감시하며 입력 지연을 유발합니다. 반드시 defer 또는 async 속성을 추가해 우선순위를 낮추세요.
불필요한 화면 재계산(리렌더링) 막기
React 같은 SPA(단일 페이지 앱) 환경에서는 버튼 하나를 클릭했을 때 관련 없는 수백 개의 화면 요소가 함께 다시 그려지는 경우가 많습니다. React.memo, useMemo 같은 최적화 도구로 불필요한 재계산을 차단해야 합니다.
클릭 시 처리 로직 분리하기
버튼을 눌렀을 때 즉시 화면에 반영해야 하는 일(UI 변경)과, 나중에 처리해도 되는 일(서버 데이터 저장 등)을 분리해서 설계해야 합니다.
먼저 보여주고 나중에 처리하기 (Optimistic UI)
사용자가 버튼을 눌렀을 때, 서버 응답을 기다린 뒤 화면을 바꾸면 화면이 굳은 것처럼 보입니다. 대신 클릭 즉시 로딩 스피너나 스켈레톤 화면을 먼저 보여주고, 데이터는 뒤에서 처리하세요. 이것이 INP 개선의 핵심 원리입니다.
CSS 애니메이션 활용하기
자바스크립트로 width, height, top 같은 크기·위치 값을 직접 바꾸는 애니메이션은 매 프레임마다 브라우저가 레이아웃을 다시 계산하게 만들어 렌더링을 막습니다. 대신 하드웨어 가속이 되는 CSS transform과 opacity 속성을 사용하세요.
코드를 개선하고 배포한 뒤, Google Search Console에 반영되기까지 최소 28~30일이 걸립니다. 실사용자 데이터가 누적되어야 점수가 업데이트되기 때문입니다. 조급하게 판단하지 말고 한 달 이상 데이터를 트래킹하세요.
제작 전 또는 개발 완료 직후 아래 항목을 점검하세요.
defer/async 적용 여부transform/opacity 기반인지, JS 직접 조작인지 확인Q1. INP가 나쁘면 구글 검색 순위에 얼마나 영향을 미치나요?
INP는 2024년 3월부터 구글의 3대 핵심 웹 지표(LCP, CLS, INP) 중 하나로 공식 편입되었습니다. 직접적인 랭킹 팩터로 작동하며, 특히 모바일 우선 색인(Mobile-First Indexing) 환경에서 가중치가 높습니다. 단독으로 순위를 결정하지는 않지만, 경쟁 사이트와 콘텐츠 품질이 비슷할 때 INP가 우열을 가르는 요인이 됩니다.
Q2. Lighthouse 점수가 90점 이상인데 INP가 나쁠 수 있나요?
네, 충분히 가능합니다. Lighthouse는 개발자 PC의 실험실 환경에서 측정합니다. 실제 사용자는 저사양 스마트폰, 느린 모바일 네트워크를 사용하기 때문에 현장 데이터(Field Data)가 훨씬 나쁜 경우가 많습니다. Google Search Console의 실사용자 기반 리포트를 반드시 병행해서 확인해야 합니다.
Q3. 워드프레스나 Wix로 만든 사이트도 INP 개선이 가능한가요?
가능하지만 한계가 있습니다. 워드프레스는 플러그인을 최소화하고 경량 테마를 사용하면 어느 정도 개선됩니다. 그러나 구조적인 한계로 인해 INP를 200ms 이하로 유지하기 어려운 경우가 많습니다. 전환율이 중요한 랜딩페이지나 커머스 사이트라면 Next.js 같은 프레임워크 기반 커스텀 개발을 검토할 필요가 있습니다.
Q4. INP 개선 작업은 얼마나 걸리나요?
사이트 규모와 현재 코드 상태에 따라 다릅니다. 서드파티 스크립트 정리와 같은 간단한 조치는 1~2일 안에 적용 가능합니다. 반면 SPA 구조의 리렌더링 최적화나 번들 분할 같은 작업은 2~4주가 소요될 수 있습니다. 처음 제작 단계부터 INP를 기준으로 설계하면 이 비용을 크게 줄일 수 있습니다.
Q5. 모바일 INP만 신경 쓰면 되나요, PC도 봐야 하나요?
구글은 모바일 우선 색인을 적용하고 있어 모바일 INP가 더 중요합니다. 그러나 B2B 업종처럼 PC 트래픽 비중이 높은 사이트라면 PC INP도 함께 관리해야 합니다. Google Search Console에서 모바일/데스크톱 탭을 분리해서 각각 확인하는 것을 권장합니다.
INP (Interaction to Next Paint) 사용자의 클릭·탭·키보드 입력부터 브라우저가 다음 화면을 그려내기까지의 시간. 구글 핵심 웹 지표 중 하나.
Long Task (긴 작업) 자바스크립트 코드가 50ms 이상 메인 스레드를 독점하는 상황. 이 동안 사용자 입력이 처리되지 않아 INP가 악화됨.
메인 스레드 (Main Thread) 브라우저가 화면 렌더링, 자바스크립트 실행, 사용자 입력 처리를 담당하는 단일 작업 흐름. 이 스레드가 막히면 화면이 굳는 것처럼 보임.
scheduler.yield() 브라우저에 일시적으로 제어권을 반환해 렌더링과 입력 처리가 가능하도록 하는 최신 JavaScript API. 크롬 129 이상에서 지원.
Optimistic UI 서버 응답을 기다리지 않고 클릭 즉시 화면을 먼저 변경해 보여주는 UX 패턴. INP 개선과 체감 속도 향상에 효과적.
LoAF (Long Animation Frames) API 렌더링을 방해하는 긴 애니메이션 프레임을 감지하고 원인을 진단하는 브라우저 성능 분석 도구.
CrUX (Chrome UX Report) 실제 크롬 사용자들의 성능 경험을 수집한 구글의 공개 데이터셋. Google Search Console과 PageSpeed Insights의 현장 데이터 기반.
FID (First Input Delay) 사용자의 첫 번째 입력에 대한 대기 시간만 측정했던 구 지표. 2024년 3월 INP로 완전 대체됨.
홈페이지 제작을 준비하고 있다면, 디자인과 콘텐츠 기획만큼 INP 최적화 설계가 중요합니다.
처음 홈페이지를 만들 때부터 INP를 설계 기준으로 삼으면, 나중에 성능 문제를 뜯어고치는 비용과 시간을 아낄 수 있습니다. 무엇보다, 빠르게 반응하는 사이트는 고객이 떠나지 않습니다.
에이달(ADALL)은 INP를 포함한 코어 웹 바이탈 기준을 홈페이지 제작 초기 설계 단계부터 반영합니다. 디자인이 아무리 훌륭해도 느리게 반응하면 고객은 떠납니다. 제작 전 기술 구조 진단부터 최적화 설계까지, 궁금한 점은 언제든지 문의해 주세요.
📞 02-2664-8631 | ✉️ master@adall.co.kr
👉 [프로젝트 문의하기] — 현재 운영 중인 사이트의 INP 진단부터 신규 홈페이지 제작 상담까지 함께 검토해 드립니다.
무료 컨설팅 받아보고 싶다면?
무료 컨설팅 신청하기