워드프레스 INP 개선하기 전에 먼저 확인할 부분

새로고침을 열 번 해도 화면은 그대로인데, PageSpeed Insights의 INP 점수는 다른 방식으로 매겨집니다. 클릭할 때마다 반응이 느리다고 느꼈던 그 체감은 사실 이 점수와 직접 연결되지 않을 수 있습니다. 그러면 이 숫자는 대체 어디서 나오는 값인지부터 짚어 보겠습니다.

먼저 결론부터 말씀드리면, INP는 PageSpeed Insights 결과 화면 위쪽의 ‘실제 사용자 경험’ 영역(필드 데이터)에서 확인합니다. 아래쪽 ‘진단’ 영역은 Lighthouse가 한 번 시뮬레이션한 랩 데이터라서 INP 값을 직접 보여 주지 않습니다. 개선 작업은 이 두 영역을 구분하는 데서 시작하고, 그 위에 어떤 상호작용이 느린지 직접 눌러 보며 찾는 단계가 따릅니다. 아래에서 순서대로 풀어 보겠습니다.

새로고침해도 그대로인 이 숫자의 정체

메인은 잘 열리는데 버튼을 눌렀을 때만 반응이 늦게 느껴지는 경우가 있습니다. 그럴 때 보통 F5를 몇 번 눌러 보게 되는데요, 화면이 눈에 띄게 달라지지 않는다면 애초에 그 방식으로는 확인이 안 되는 값일 수 있습니다.

INP는 내 브라우저 한 번의 클릭이 아니라 페이지 방문의 75번째 백분위 값으로 평가됩니다. 여러 방문자가 남긴 응답 속도 중에서 75번째에 해당하는 값을 가져온다는 뜻이라, 혼자 새로고침을 반복하는 방식으로는 이 점수가 어떻게 나오는지 가늠하기 어렵습니다. 새로고침은 페이지를 불러오는 속도를 보는 동작이고, INP는 불러온 뒤에 누른 버튼이 얼마나 빨리 화면에 반영되는지를 보기 때문입니다.

화면 속 그 숫자, 어디부터 문제로 봐야 할까

PageSpeed Insights를 열면 INP 항목 옆에 ms 단위 숫자와 색깔이 같이 표시됩니다. 이 숫자를 보는 기준은 정해져 있습니다. 200ms 이하는 좋음, 200ms 초과 500ms 이하는 개선 필요, 500ms를 넘으면 나쁨으로 나뉩니다. 화면에 뜬 숫자가 이 세 구간 중 어디에 걸리는지부터 눈으로 확인하고, 그 구간의 이름을 그대로 적어 두면 됩니다.

INP 값(75번째 백분위)	구간
200ms 이하	좋음
200ms 초과 500ms 이하	개선 필요
500ms 초과	나쁨

화면에서 같은 숫자를 찾으실 때는 세 가지만 확인해 보세요. 이 값이 어느 조건에서 나온 숫자인지 알아야 나중에 비교가 되기 때문입니다.

1. 결과 화면 위쪽의 ‘실제 사용자 경험’ 영역(필드 데이터)에서 INP를 봅니다. 아래쪽 ‘진단’ 영역은 Lighthouse가 한 번 돌린 랩 데이터입니다.
2. 모바일과 데스크톱 결과가 따로 나옵니다. INP는 두 환경을 나눠 평가하므로, 어느 쪽 숫자를 보고 있는지 같이 적어 둡니다.
3. URL 기준과 원본(origin, 사이트 전체) 기준이 다를 수 있습니다. 해당 글에 데이터가 충분하지 않으면 PSI가 원본 기준으로 대신 보여 주기도 하므로, 지금 보는 값이 이 글의 값인지 사이트 전체의 값인지 확인합니다.

실제 사용자 영역이 아예 비어 있거나 “데이터가 부족하다”는 취지로 나온다면, 최근 방문 표본이 적거나 글을 올린 지 얼마 안 된 경우입니다. CrUX에 포함되려면 공개된 URL이어야 하고 충분한 방문 표본이 필요하다고 공식 문서에 나와 있습니다. 이 경우의 대처는 아래 “필드 데이터가 없을 때는 직접 눌러 봅니다”에서 이어서 다루겠습니다.

“충분한 표본”이 몇 번의 방문인지는 제가 확인한 공식 문서에 숫자로 적혀 있지 않았습니다. 그래서 숫자를 외우기보다 화면이 어떤 상태로 나오는지를 보고 판단하는 편이 현실적입니다. PageSpeed Insights 문서가 설명하는 상황은 크게 세 가지입니다.

화면에 보이는 상태	뜻	이럴 때 합니다
해당 URL의 INP 값이 나옴	이 글만의 필드 데이터가 있음	그 값을 기준으로 기록합니다.
사이트 전체(원본) 값으로 대신 나옴	이 글의 표본은 부족하지만 사이트 전체에는 충분함	이 글의 값이 아니라 사이트 평균에 가까운 값이므로, 기록할 때 “원본 기준”이라고 적어 둡니다.
실제 사용자 영역이 비어 있음	URL과 원본 모두 표본이 부족함	필드 숫자는 포기하고 아래의 직접 측정으로 갑니다.

INP는 무엇을 재는 값일까

숫자를 읽는 법을 알았으니, 이 숫자가 무엇을 잰 것인지도 알아 두면 원인을 찾기 쉬워집니다. INP는 방문 중에 일어난 클릭, 탭, 키보드 입력이 눌린 순간부터 화면에 결과가 그려지기까지 걸린 시간을 보고, 그중 가장 느린 상호작용을 기준으로 삼습니다(상호작용이 아주 많은 페이지는 이상치를 일부 제외합니다). 한 번의 상호작용은 세 구간으로 나뉩니다.

구간	의미	워드프레스에서 흔한 원인
입력 지연	눌렀을 때부터 이벤트 처리가 시작되기까지	페이지 로드 중이거나 다른 스크립트가 메인 스레드를 오래 잡고 있을 때(플러그인이 추가한 JS, 광고·분석 같은 외부 스크립트)
처리 시간	이벤트 핸들러가 실행되는 시간	버튼 하나에 무거운 스크립트가 연결된 슬라이더, 팝업, 필터 같은 위젯
표시 지연	처리가 끝난 뒤 다음 화면이 그려지기까지	DOM이 지나치게 크거나 한꺼번에 많은 요소를 다시 그려야 하는 구조

같은 INP 300ms라도 입력 지연이 큰지 처리 시간이 큰지에 따라 손볼 곳이 완전히 달라집니다. 저는 그래서 플러그인을 끄기 전에 어느 구간이 긴지를 먼저 보는 쪽이 순서에 맞다고 생각합니다. 플러그인 쪽 점검은 워드프레스 플러그인 몇 개가 적당한지보다 중요한 것에서 따로 정리해 두었습니다.

이 숫자, 내 컴퓨터가 잰 값이 아니었다

여기서 한 가지 놓치기 쉬운 부분이 있습니다. PageSpeed Insights와 Search Console의 Core Web Vitals 리포트는 둘 다 CrUX라는 실사용자 데이터를 씁니다. CrUX는 구글이 크롬 사용자의 실제 방문 데이터를 모아 두는 곳으로, 두 도구 모두 이 데이터를 가져와 화면에 보여 주는 역할만 합니다. 내가 지금 이 화면에서 클릭해 보는 속도가 아니라, 실제로 그 페이지를 방문했던 사람들의 기록이 이 숫자를 만든다는 점이 다릅니다. 그래서 개발자 도구로 직접 재는 값과 이 화면의 숫자가 똑같이 움직이지 않을 수 있습니다.

두 데이터는 쓰임새가 다르니 따로 보시면 됩니다. web.dev의 설명을 기준으로 정리하면 아래와 같습니다.

구분	필드 데이터	랩 데이터
측정 방식	실제 방문자의 기기·네트워크에서 수집(CrUX 등)	통제된 환경에서 한 번 측정(Lighthouse 등)
값의 성격	분포이며, 보통 75번째 백분위 값을 사용	그 실행 한 번의 측정값
이럴 때 씁니다	실제로 문제가 있는지 판단하고 우선순위를 정할 때	원인을 찾거나 수정 전후를 재현해서 확인할 때
INP에서의 한계	어떤 상호작용이 느렸는지는 알려 주지 않음	사용자가 언제 무엇을 누를지 알 수 없어 INP를 그대로 재현하기 어렵고, TBT로 경향만 짐작

정리하면 필드 데이터로 “문제가 있는가”를 판단하고, 랩 환경에서 직접 눌러 보며 “무엇이 느린가”를 찾는 순서가 됩니다. 그리고 랩에서는 보통 캐시가 빈 상태로 재기 때문에, 캐시가 쌓인 실제 방문자의 INP는 랩보다 나을 수도 있다는 점도 기억해 두세요.

이 말의 근거는 앞에서 인용한 web.dev 문서입니다. 이 문서는 랩 테스트가 보통 캐시 없는 상태로 페이지를 불러온다고 설명하고, INP에 대해서는 캐시된 JavaScript는 처리에 걸리는 시간이 짧아질 수 있고, 뒤로 가기·앞으로 가기 캐시(bfcache)로 복원되는 페이지는 처리가 거의 필요 없을 수 있다고 적고 있습니다. 다만 이것이 필드 값이 항상 더 좋다는 뜻은 아닙니다. 필드는 여러 방문의 75번째 백분위라서, 느린 기기의 방문자가 많으면 오히려 랩보다 나쁘게 나올 수도 있습니다.

필드 데이터가 없을 때는 직접 눌러 봅니다

방문자가 적은 블로그라면 PSI의 실제 사용자 영역이 비어 있을 수 있습니다. 이때는 숫자를 기다리기보다 느리다고 느끼는 버튼을 직접 눌러 보며 어느 구간이 긴지 보는 편이 빠릅니다. 이 값은 CrUX의 INP와 같은 값은 아니고 원인을 찾기 위한 단서라는 점만 감안하세요. Chrome DevTools의 성능(Performance) 패널을 쓰는 방법은 다음과 같습니다.

1. 시크릿 창에서 점검할 글을 열어 확장 프로그램의 영향을 뺍니다.
2. F12로 개발자 도구를 열고 성능 탭에서 기록을 시작합니다.
3. 메뉴 열기, 검색, 댓글 버튼, 팝업 닫기처럼 느리다고 느꼈던 동작을 한두 번 누릅니다. 페이지 로드 직후처럼 메인 스레드가 바쁜 때 눌러 보면 입력 지연이 드러나기 쉽습니다.
4. 기록을 멈추고 클릭한 시점 근처에서 메인 스레드가 길게 점유된 구간을 찾습니다. 그 구간에 어떤 스크립트 파일이 걸려 있는지가 원인 후보입니다.
5. 크롬의 CPU 속도 제한 같은 옵션으로 느린 기기를 흉내 내면 차이가 더 잘 보입니다.

5번의 배율은 저라면 4x slowdown 하나로 정해 두겠습니다. 어떤 배율이 정답이라서가 아니라, 수정 전후 비교에서 이 값이 바뀌면 다른 실험이 되기 때문입니다. Chrome 문서는 이 배율이 내 컴퓨터를 기준으로 상대적으로 느리게 만드는 것이라 실제 휴대폰과 같지 않다고 설명하고, 선택지는 버전에 따라 다를 수 있습니다. 4x가 목록에 없다면 가장 가까운 값을 고르고 그 값을 기록해 두세요. 내 기기에 맞춰 보고 싶다면 Capture settings의 CPU 항목에서 Calibrate로 저·중급 휴대폰에 가까운 사용자 지정 값을 만들 수도 있습니다. 기기 모드도 데스크톱이나 모바일 중 하나로 고정하고, 이 글처럼 모바일 점수가 문제라면 모바일 쪽으로 맞추는 편이 PSI 모바일 숫자와 비교하기 좋습니다.

4번의 “길게 점유된 구간”이 어디를 말하는지, 몇 ms부터 문제로 봐야 하는지가 초보자에게는 가장 막막한 부분이라 조금 더 풀어 보겠습니다. 아래 위치와 기준은 Chrome DevTools 공식 문서를 기준으로 했고, 크롬 버전에 따라 화면 배치는 조금 다를 수 있습니다.

• 기록 방식은 두 가지입니다. 페이지를 연 뒤 버튼을 누르는 상황을 보려면 Record를 누르고 동작한 다음 다시 눌러 멈춥니다. 로드 중 입력 지연을 보려면 Record and reload로 새로 불러오며 기록하고, 로드 직후에 눌러 봅니다.
• 기록이 끝나면 타임라인에 Interactions 트랙이 나타납니다. 여기서 내가 누른 동작이 막대로 보이고, 마우스를 올리면 입력 지연·처리 시간·표시 지연이 각각 몇 ms인지 말풍선으로 나옵니다. 앞의 세 구간 표를 실제 숫자로 확인하는 곳이 바로 여기입니다.
• 판단 기준은 두 가지로 잡으면 됩니다. 200ms를 넘는 상호작용에는 막대 오른쪽 위에 빨간 삼각형이 붙습니다. 이 기준은 INP의 “좋음” 경계와 같습니다. 그 아래 Main 트랙에서는 50ms를 넘는 긴 작업(Long task)의 초과분이 빨간 음영으로 표시되므로, 눌렀을 때 그 음영이 겹치는 작업을 클릭해 어떤 스크립트 파일에서 오래 걸렸는지 봅니다.
• 어느 구간이 긴지에 따라 읽는 곳이 달라집니다. 입력 지연이 길면 누르기 전에 이미 돌고 있던 작업을, 처리 시간이 길면 눌린 뒤 실행된 핸들러를, 표시 지연이 길면 핸들러 이후의 Recalculate Style이나 Layout 같은 렌더링 작업을 봅니다.
• CPU 제한은 성능 패널 상단의 Capture settings를 열어 CPU 항목에서 고릅니다. 배율은 내 컴퓨터를 기준으로 상대적으로 느리게 만드는 것이라 실제 휴대폰과 같지는 않고, 선택지도 버전에 따라 다를 수 있습니다. 그래도 제한을 건 상태가 느린 환경을 가늠하기에는 낫습니다.

여기에도 출처가 있습니다. 위 기준은 Chrome for Developers, Performance features reference에서 확인한 내용입니다.

찾은 결과는 아래처럼 기록해 두면 좋습니다. 아래 표는 형식을 보여 드리기 위한 가상 예시입니다.

느린 상호작용 기록표(예시)	느린 구간(예시)	의심 원인(예시)
상단 메뉴 버튼 탭	입력 지연이 김	로드 직후 외부 스크립트가 실행 중
검색창 열기	처리 시간이 김	검색 플러그인의 스크립트
댓글 펼치기	표시 지연이 김	한꺼번에 많은 요소를 그림

모바일에서는 화면을 뷰포트에 맞게 설정하지 않으면 탭 직후 지연이 생겨 INP에 반영될 수 있다고 web.dev가 설명합니다. 모바일 기기 모드로도 한 번 눌러 보세요.

이 지연이 어느 정도인지 궁금하실 텐데, web.dev는 모바일에 최적화되지 않은 페이지에서 탭 후 이벤트 처리 전에 300ms가 더해질 수 있다고 적고 있습니다. 이 값만으로도 INP의 “좋음” 기준 200ms를 넘기는 크기입니다. 이 지연은 INP에는 잡히지만 TBT에는 잡히지 않아서, Lighthouse의 TBT가 괜찮은데 INP만 나쁜 이유가 될 수 있습니다. 확인은 어렵지 않습니다. 글을 연 상태에서 페이지 소스 보기(Ctrl+U)를 열고 “viewport”를 검색해 <meta name="viewport" content="width=device-width, initial-scale=1"> 같은 줄이 있는지 봅니다. 대부분의 테마는 헤더 출력에서 이 줄을 넣어 주지만, 위치는 테마마다 다릅니다. 줄이 없거나 width가 고정 픽셀 값으로 되어 있다면 테마 설정이나 테마 제작자에게 먼저 확인할 만합니다. 참고: web.dev, Why lab and field data can be different

원인 후보를 찾은 뒤에는 느린 구간에 따라 방향이 갈립니다. 입력 지연은 로드 중 스크립트 실행을 줄이고, 처리 시간은 핸들러의 작업을 나누고, 표시 지연은 DOM 크기를 줄이는 쪽이라고 공식 문서가 안내합니다. 이미지나 LCP가 같이 걸리는 글이라면 워드프레스 이미지 최적화 후 느릴 때 확인하는 방법과 워드프레스 사이트 느릴 때 이미지를 살펴보는 이유도 함께 보시면 좋습니다.

“줄인다”, “나눈다”만으로는 워드프레스에서 어디를 만져야 하는지 알기 어려우니, 구간별로 실제 손댈 곳을 하나씩 적어 보겠습니다. 어디까지나 방향을 잡기 위한 예이고, 쓰는 플러그인과 테마에 따라 메뉴 이름은 다릅니다.

• 입력 지연이 길 때: 로드 중에 돌아가는 스크립트를 뒤로 미루는 쪽입니다. 캐시·최적화 플러그인으로 WP Rocket을 쓴다면 File Optimization 탭의 Delay JavaScript execution이 이 역할을 합니다. 스크립트를 방문자가 마우스를 움직이거나 스크롤하거나 키를 누를 때까지 미루는 기능입니다. 다만 이 기능은 켜는 순간 Combine JavaScript files가 꺼지고, 페이지 HTML에 들어 있는 스크립트만 대상이 됩니다. 켠 뒤에 메뉴나 폼, 분석 코드가 멈추면 같은 화면의 Excluded JavaScript Files에 해당 파일 경로나 고유한 문자열을 넣어 예외로 돌립니다. 원인이 잡히기 전에 한꺼번에 예외를 늘리면 효과가 줄어드니, 하나 넣고 다시 확인하는 식으로 진행하세요. 출처: WP Rocket 문서, Delay JavaScript execution
• 처리 시간이 길 때: 한 번의 클릭에 한꺼번에 하는 일을 쪼개는 쪽입니다. web.dev는 핸들러에서 꼭 필요한 화면 갱신만 먼저 하고 나머지 작업은 setTimeout 등으로 별도 작업으로 나눠 메인 스레드에 숨 쉴 틈을 주라고 안내합니다. 워드프레스 운영자가 직접 코드를 고치기는 어려우니, 현실적인 첫 단계는 그 버튼에 연결된 플러그인(슬라이더, 필터, 검색 위젯 등)의 옵션을 줄이거나 가벼운 대체 기능으로 바꾸는 일입니다. 어느 파일이 오래 걸렸는지는 앞의 성능 패널 Main 트랙에서 이미 확인했을 겁니다.
• 표시 지연이 길 때: 눌렀을 때 한꺼번에 다시 그려야 하는 요소를 줄이는 쪽입니다. web.dev는 DOM을 작게 유지하고, 화면 밖 요소는 CSS의 content-visibility로 나중에 그리게 하는 방법을 안내합니다. 워드프레스에서는 한 글에 댓글을 전부 펼쳐 두거나 위젯과 블록을 지나치게 많이 쌓은 구조가 대표적인 후보입니다. 댓글 페이지 나누기를 켜거나(설정 메뉴의 토론 항목) 같은 내용이 중복된 블록을 정리하는 것이 먼저입니다. 출처: web.dev, Optimize Interaction to Next Paint

처리 시간과 표시 지연은 “어느 정도면 많은 건지” 기준이 없으면 손댈 곳을 정하기 어렵습니다. 그래서 확인하는 곳과 기준값을 같이 적어 둡니다.

• 처리 시간: 성능 패널의 Interactions 트랙에서 해당 막대의 처리 시간 값을 봅니다. 별도의 공식 기준값은 확인하지 못했지만, 막대 전체가 200ms를 넘는데 처리 시간이 가장 큰 비중이라면 그 핸들러가 우선 후보입니다. Main 트랙에서 같은 시점의 긴 작업을 눌러 어느 플러그인 파일(/wp-content/plugins/ 경로)인지 확인하고, 그 플러그인의 기능을 끄거나 줄인 뒤 같은 조건으로 다시 재서 처리 시간이 줄었는지 봅니다.
• 표시 지연(DOM 크기): Lighthouse의 DOM 크기 항목(버전에 따라 “Optimize DOM size” 인사이트로 합쳐져 있습니다)에서 전체 요소 수, 최대 깊이, 최대 자식 수를 확인합니다. Lighthouse 문서는 body 요소가 약 800개를 넘으면 경고, 약 1,400개를 넘으면 오류로 표시한다고 설명합니다. 내 글이 이 범위에 걸린다면 댓글, 위젯, 중복 블록부터 줄이고, 다시 측정해 표시 지연이 줄었는지 비교합니다. 참고: Chrome for Developers, Lighthouse DOM size

설정 바꾼 다음 날 숫자가 안 바뀐 이유

플러그인 하나를 끄거나 스크립트를 지연 설정으로 바꾼 뒤 바로 다음 날 PageSpeed Insights를 열어 보는 경우가 있습니다. 숫자가 그대로여도 설정을 잘못 건드린 건 아닐 수 있습니다. PageSpeed Insights의 필드 데이터는 최근 28일 수집 기간을 기준으로 합니다. 어제까지의 방문 기록이 여전히 이 28일 안에 섞여 있어서, 오늘 바꾼 설정의 효과가 숫자에 바로 나타나지 않을 수 있습니다.

PSI 문서는 필드 데이터가 직전 28일의 경험을 보여 주고 매일 갱신된다고 설명합니다. 그래서 수정 직후의 효과는 필드 숫자보다 위에서 말한 직접 측정으로 먼저 확인하고, 필드 숫자는 28일 정도 지난 뒤 비교하는 것이 맞습니다.

이 “직접 측정”이 그냥 한 번 눌러 보는 것으로 끝나면 좋아졌는지 알 수 없습니다. 눌러 볼 때마다 값이 흔들리고, 조건이 달라지면 비교 자체가 안 되기 때문입니다. 그래서 수정 전과 후를 같은 조건에서 여러 번 재는 편이 안전합니다. 저는 아래 정도면 최소한의 비교가 된다고 봅니다.

1. 조건을 먼저 정해 적어 둡니다. 시크릿 창, 같은 글 주소, 같은 기기 모드(데스크톱 또는 모바일), 같은 CPU 제한 배율, 같은 동작(예: 로드 직후 메뉴 버튼 한 번 탭)입니다. 하나라도 바뀌면 다른 실험이 됩니다.
2. 설정을 바꾸기 전에 그 조건으로 3번 기록하고, 각 기록의 Interactions 트랙에서 해당 상호작용의 전체 시간과 세 구간 값을 적습니다.
3. 캐시 플러그인을 썼다면 캐시를 비운 뒤 설정을 하나만 바꾸고, 같은 조건으로 3번 다시 기록합니다. 첫 로드는 캐시를 새로 만드는 중이라 느리게 나올 수 있으니, 한 번 열어 준 뒤에 기록을 시작하세요.
4. 3번 중 가운데 값(중앙값)끼리 비교합니다. 평균보다 한 번 튄 값의 영향을 덜 받습니다. 줄어든 구간이 내가 손댄 구간과 같은지도 같이 봅니다. 입력 지연을 줄이려고 바꿨는데 처리 시간만 줄었다면 다른 요인일 가능성이 큽니다.

같은 조건 3회 재측정(예시)	1회차	2회차	3회차	중앙값	가장 긴 구간
변경 전: 로드 직후 메뉴 탭, CPU 제한 적용	410ms	360ms	385ms	385ms	입력 지연(약 250ms)
변경 후: 검색 플러그인 스크립트 지연 로드	230ms	195ms	210ms	210ms	처리 시간(약 90ms)

이렇게 중앙값이 줄고, 줄어든 구간이 바꾼 설정과 맞아떨어지면 개선 방향이 맞다고 볼 수 있습니다. 반대로 값이 비슷하거나 오히려 늘었다면 그 설정을 되돌리고 다른 후보를 확인합니다. 이 비교는 내 컴퓨터에서의 단서일 뿐이어서, 실제 방문자의 INP가 같이 줄었는지는 28일 뒤 필드 숫자로 확인해야 합니다.

3번이면 충분한지 궁금하실 텐데, 이 횟수는 공식 문서에서 가져온 기준이 아니라 제가 최소한으로 잡은 경험칙입니다. 3번의 값이 서로 많이 다르다면(예를 들어 가장 큰 값이 가장 작은 값의 1.5배를 넘는 정도) 횟수를 5번으로 늘려 중앙값을 다시 구하는 편이 낫습니다. 그래도 흔들리면 측정 조건이 새고 있다는 신호입니다. 로드 직후에 누르는 타이밍이 매번 다른지, 다른 탭이나 프로그램이 CPU를 쓰고 있는지, 광고나 분석 스크립트가 늦게 도는지부터 확인하세요. 이때 변경 전후의 중앙값 차이가 이 흔들림 폭보다 작으면, 좋아졌다고 말하기는 이릅니다.

스크립트 지연은 효과가 큰 만큼 부작용도 잦은 설정이라 예외 상황도 함께 알아 두면 좋습니다. WP Rocket 문서가 설명하는 동작에 비추면, 지연된 스크립트는 방문자가 첫 입력을 하기 전까지 실행되지 않습니다. 그래서 페이지가 열리자마자 동작해야 하는 코드(첫 화면 슬라이더, 메뉴, 폼 검증, 방문 기록을 보내는 분석 코드)가 멈추거나 늦게 반응할 수 있습니다. 이런 일이 생기면 설정 전체를 끄기보다 멈춘 기능에 해당하는 파일 하나만 예외로 넣고 다시 측정하세요. 예외를 넣을수록 입력 지연이 다시 늘 수 있어서, 예외를 하나 추가할 때마다 INP 중앙값도 함께 확인하는 것이 좋습니다.

다음에 이 화면을 열 때 비교할 것

여러 설정을 한꺼번에 만지기 전에 지금 화면에 뜬 값부터 적어 두는 편이 나중에 도움이 됩니다. PageSpeed Insights 필드 데이터에 나온 INP 값(ms)과 그 값이 속한 구간(좋음·개선 필요·나쁨)을 확인한 날짜와 함께 메모장이나 스프레드시트에 남겨 둡니다. 28일 기준으로 갱신되는 데이터이다 보니 날짜를 같이 적어 둬야 이후에 찍힌 값과 비교할 때 어느 시점의 변화인지 구분이 됩니다. 개인적으로는 숫자 하나만 적기보다 확인한 날짜를 같이 적어야 28일 뒤에 이 기록이 의미가 있다고 봅니다.

기록은 아래처럼 남기면 나중에 읽기 편합니다. 값과 날짜는 모두 형식을 보여 드리기 위한 예시입니다.

기록 예시	확인일(예시)	기준(예시)	INP(예시)	구간	그때 바꾼 것(예시)
변경 전	10월 1일	모바일 / URL	320ms	개선 필요	없음
변경 직후	10월 2일	모바일 / URL	320ms	개선 필요	검색 플러그인 스크립트 지연 로드
28일 뒤	10월 30일	모바일 / URL	190ms	좋음	추가 변경 없음

예시에서 보듯 변경 직후에는 값이 그대로이고, 오래 지난 뒤에야 달라지는 모양이 정상일 수 있습니다. 여기서 “변경한 것” 칸을 비워 두지 않아야 어떤 설정이 효과가 있었는지 나중에 되짚을 수 있습니다. 다음번 PageSpeed Insights 화면을 열 때는 오늘 적어 둔 날짜 옆에 새 INP 값을 나란히 적는 것부터 시작하면 됩니다.

참고한 자료

아래 문서를 2026년 10월 10일에 다시 열어 확인하고 정리했습니다. 구글의 문서와 화면 이름은 바뀔 수 있으니, 보시는 화면과 다르면 공식 문서를 우선하세요.

• web.dev, Interaction to Next Paint (INP): INP의 정의, 구성 요소, 200ms/500ms 기준, 75번째 백분위
• web.dev, Optimize Interaction to Next Paint: 구간별 최적화 방향
• web.dev, Why lab and field data can be different: 필드·랩 데이터의 차이와 쓰임새, 캐시 상태 차이, 모바일 뷰포트와 탭 지연
• Google, PageSpeed Insights 소개: 필드 데이터 28일 기간, URL/원본 대체, 데이터 부족 조건
• Chrome for Developers, CrUX methodology: CrUX에 포함되는 사용자와 페이지 조건
• Chrome for Developers, Performance features reference: Interactions 트랙, 긴 작업 표시, CPU 제한 위치와 Calibrate
• Chrome for Developers, Lighthouse DOM size: DOM 요소 수 경고·오류 기준
• WP Rocket 문서, Delay JavaScript execution: 스크립트 지연 로드 위치, 예외 처리, 유의점

• 워드프레스 플러그인 몇 개가 적당한지보다 중요한 것
• 워드프레스 이미지 최적화 후 느릴 때 확인하는 방법
• 워드프레스 사이트 느릴 때 이미지를 살펴보는 이유
• 사진 많은 워드프레스 속도 개선하는 방법