같은 워드프레스인데 휴대폰에서만 느리게 열리는 이유

워드프레스 관리자 화면에서는 사이트가 멀쩡한데, 휴대폰으로 열어보면 유독 느리게 뜨는 순간이 있습니다⠀

PC에서 PageSpeed Insights를 돌리면 점수가 괜찮게 나오는데, 모바일 탭만 유독 낮게 찍혀 있는 걸 보게 됩니다⠀

새로고침을 몇 번을 해도 달라지지 않는 이 숫자는, 사실 회선이 아니라 테스트 조건이 다르게 짜여 있는 탓일 수 있습니다⠀

먼저 결론부터 말씀드리면, 모바일 탭 점수가 낮은 이유는 대부분 도구가 모바일에 더 느린 회선과 4배 느린 CPU를 가정하기 때문입니다⠀

다만 이 점수는 실제 휴대폰에서 느끼는 속도와 같은 값이 아니라서, 이 글은 점수가 갈리는 이유를 먼저 풀고 뒤에서 실제 휴대폰으로 확인하는 방법과 줄이는 순서까지 이어서 정리합니다⠀

⠀⠀⠀

⠀⠀⠀

새로고침해도 안 바뀌는 진짜 이유⠀

⠀⠀⠀

처음에는 인터넷 문제인가 싶어서 새로고침을 몇 번 눌러보게 되는데, 숫자는 좀처럼 바뀌지 않습니다⠀

같은 와이파이로 다른 사이트를 열어보면 그쪽은 금방 뜨는 걸 보고서야 내 사이트만의 문제라고 느끼게 됩니다⠀

⠀⠀⠀

퇴근길 지하철에서 휴대폰으로 자기 사이트를 열어보는 운영자라면 이 답답함이 유독 크게 느껴질 수 있습니다⠀

플러그인을 줄이라거나 캐시를 깔라거나 호스팅을 바꾸라는 이야기를 검색해봐도, 방법이 제각각이라 뭐부터 손대야 할지 막막해지기도 합니다⠀

이때 봐야 할 곳은 휴대폰 회선 상태가 아니라, PageSpeed Insights가 모바일 점수를 잴 때 걸어두는 조건 쪽입니다⠀

⠀⠀⠀

⠀⠀⠀

이 도구는 지금 이 순간 휴대폰이 잡고 있는 실제 신호를 재는 게 아니라, 미리 정해둔 가상의 환경에서 페이지를 새로 불러와 시간을 잽니다⠀

결과 화면 위쪽에는 ‘모바일’과 ‘데스크톱’ 탭이 나란히 있고, 그 아래 ‘실험실 데이터’라는 이름으로 측정값이 묶여 있습니다⠀

화면을 더 내려보면 ‘필드 데이터’라는 항목도 따로 있는데, 이쪽은 실제 방문자의 크롬 브라우저에서 최근 28일간 모은 값입니다⠀

실험실 데이터는 도구가 정해진 조건으로 매번 새로 재는 값이고, 필드 데이터는 그동안 사이트를 열어본 사람들의 기록입니다⠀

이 구분은 PageSpeed Insights 공식 안내에도 나와 있습니다. 필드 데이터는 Chrome 사용자 경험 보고서(CrUX)에서 가져오고, 실험실 데이터는 Lighthouse가 통제된 환경에서 시뮬레이션한 값이라는 설명입니다⠀

⠀⠀⠀

새로고침을 반복해도 그대로인 숫자는 대부분 이 실험실 데이터 쪽이라서, 회선을 바꿔봐도 크게 달라지지 않습니다⠀

워드프레스는 모바일과 PC에 같은 코드를 내려주는 경우가 대부분이라, 사이트 설정이 둘을 다르게 갈라놓는 것도 아닙니다⠀

점수 차이의 실마리는 사이트 설정보다, 이 실험실 데이터가 어떤 조건으로 재는지에 있습니다⠀

⠀⠀⠀

모바일 테스트는 1.6Mbps로 잰다⠀

⠀⠀⠀

PageSpeed Insights 모바일 테스트는 실제 4G 신호가 아니라 ‘Slow 4G’라는 이름이 붙은 가상 환경에서 진행됩니다⠀

다운로드 속도는 약 1.6Mbps로 맞춰져 있고, 지연 시간은 150ms로 고정한 채로 페이지를 처음부터 다시 불러옵니다⠀

업로드 속도 역시 750Kbps로 함께 정해져 있어, 세 가지 값이 한 세트로 묶여 있습니다⠀

⠀⠀⠀

⠀⠀⠀

이 수치는 Lighthouse 공식 스로틀링 문서가 권장하는 값으로, 4G 회선 중 하위 25%, 3G 회선 중 상위 25% 수준에 해당한다고 적혀 있습니다⠀

실제로 쓰는 휴대폰이 LTE든 5G든 상관없이, 도구 안에서는 이 정도로 느린 회선을 가정하고 로딩 시간을 잽니다⠀

⠀⠀⠀

사무실이나 집 와이파이가 아무리 빠르더라도, PageSpeed Insights 모바일 탭 점수에는 그 속도가 반영되지 않습니다⠀

스피드테스트 앱으로 잰 실제 회선 속도와는 완전히 별개로, 이 값은 도구 안에 고정되어 있습니다⠀

이 조건은 결과 화면 ‘실험실 데이터’ 아래, 네트워크 처리량이 적힌 자리에서 볼 수 있습니다⠀

페이지 안에 있는 사진과 스크립트를 이 느린 회선으로 하나씩 내려받는 시간까지 합쳐서 전체 로딩 시간이 계산됩니다⠀

⠀⠀⠀

사진 용량이 크거나 외부 스크립트가 많이 걸려 있을수록, 이 구간에서 걸리는 시간이 눈에 띄게 늘어나게 됩니다⠀

서버가 지원할 경우, 사진을 WebP나 AVIF 형식으로 새로 올리면 같은 화면이라도 받아야 할 용량이 줄어듭니다⠀

서버가 지원하는지는 관리자 화면의 ‘도구 > 사이트 상태 > 정보’에서 미디어 처리 항목을 보거나, 호스팅 업체에 문의해서 확인할 수 있습니다. 워드프레스 버전과 서버 환경에 따라 지원 범위가 다를 수 있습니다⠀

이미 올려둔 사진은 새로 올리지 않아도 이미지 최적화 플러그인의 일괄 변환 기능으로 처리할 수 있는 경우가 많습니다. 변환 뒤에는 실제로 내려받는 용량이 줄었는지를 같은 URL에서 다시 봐야 하는데, 이 과정은 사진 많은 워드프레스 속도 개선하는 방법에서 따로 다뤘습니다⠀

⠀⠀⠀

CPU는 4배 느려진다⠀

⠀⠀⠀

네트워크만 느리게 잡아놓는 게 아니라, Lighthouse는 모바일 측정에서 CPU 처리 속도까지 기본 4배 낮춰서 계산합니다⠀

데스크톱 컴퓨터에서 100ms 만에 끝나는 자바스크립트 실행이, 모바일 시뮬레이션에서는 약 400ms짜리 작업으로 바뀌어 잡힙니다⠀

워드프레스 페이지 하나가 여러 플러그인과 테마 스크립트를 합쳐 1메가바이트에서 3메가바이트가량의 자바스크립트를 불러오는 경우도 있습니다. 참고로 HTTP Archive의 2024 Web Almanac에서 모바일 페이지의 자바스크립트 전송량 중앙값은 약 558KB였고, 제3자 스크립트만 따져도 상위 10% 페이지는 약 1.3MB였습니다. 워드프레스 사이트만 따로 센 수치는 아니므로, 플러그인이 많은 사이트가 평균보다 무거워지기 쉽다는 정도로 참고하시면 됩니다⠀

데스크톱 CPU라면 200ms에서 500ms 안에 처리될 양이, 이 4배 감속 아래에서는 800ms에서 2초까지 늘어나 잡힙니다⠀

⠀⠀⠀

⠀⠀⠀

페이지 빌더나 모든 글에 스크립트를 붙이는 플러그인을 쓰고 있다면, 이 구간에서 모바일 점수가 유독 더 낮게 나올 수 있습니다⠀

이 CPU 감속은 결과 화면 진단 항목 가운데 ‘기본 실행 스레드 작업’ 부근에 걸린 시간으로 나타납니다⠀

그 항목 옆 세부 내역을 펼쳐보면, 어떤 스크립트가 시간을 얼마나 쓰고 있는지 이름과 함께 적혀 있습니다⠀

이름만 봐서는 어느 플러그인인지 헷갈릴 수 있는데, 주소에 /wp-content/plugins/폴더이름/ 이 들어 있으면 그 폴더 이름이 곧 플러그인입니다. 테마 스크립트는 /wp-content/themes/ 아래에 있고, 주소가 다른 도메인이면 광고나 분석 도구 같은 외부 스크립트입니다⠀

몇 ms부터 문제라고 딱 잘라 말하기는 어렵습니다. 저는 목록 맨 위 한두 개가 나머지를 합친 것보다 눈에 띄게 크면 그쪽부터 의심하는 편이 낫다고 봅니다. 목록 전체가 고르게 짧다면 개별 스크립트보다 전체 용량이나 서버 응답 쪽을 따로 보는 게 맞습니다⠀

그래도 지금 내 숫자가 어느 정도인지 가늠할 기준이 하나쯤은 있어야 하니, 스크립트 때문에 화면이 멈춘 시간을 보여주는 총 차단 시간(TBT)의 공식 구간을 적어둡니다. Lighthouse의 TBT 문서는 모바일 기준으로 0~200ms를 좋음, 200~600ms를 개선 필요, 600ms 초과를 나쁨으로 나눕니다. 데스크톱은 기준이 더 엄격해서 150ms 이하, 350ms 초과로 갈립니다. LCP는 앞에서 본 것처럼 2.5초 이하가 좋음이고, 4초를 넘으면 나쁨 구간입니다⠀

이 기준을 아래 예시 표에 대 보면, 모바일 TBT 1,150ms는 ‘나쁨’ 구간이고 스크립트를 하나 껐다는 420ms는 ‘개선 필요’ 구간까지 내려온 셈입니다. 숫자가 구간 안에 들어왔는지를 보면 아직 더 손댈 가치가 있는지 판단하기 쉽습니다. 다만 이 구간은 실험실 값에 대한 기준이라서, 실제 방문자 체감과는 따로 봐야 합니다⠀

⠀⠀⠀

플러그인 목록에서 최근에 새로 설치한 것들을 살펴보면, 페이지마다 스크립트를 붙이는 항목이 눈에 띄기도 합니다⠀

백업을 해둔 뒤, 최근 설치한 플러그인 하나를 잠깐 꺼보고 같은 페이지를 다시 재는 방식으로 영향을 가늠해볼 수 있습니다⠀

한 번에 여러 플러그인을 껐다 켜면 무엇 때문에 시간이 줄었는지 알기 어려워지니, 하나씩 바꿔가며 다시 재는 쪽이 원인을 가려내는 데 도움이 됩니다⠀

이 작업 시간이 유독 큰 페이지일수록, 모바일 탭 점수가 데스크톱보다 크게 벌어지는 경우가 많습니다⠀

플러그인 개수 자체보다 각 플러그인이 붙이는 스크립트의 양이 중요하다는 이야기는 워드프레스 플러그인 몇 개가 적당한지보다 중요한 것에서 더 자세히 다뤘습니다⠀

⠀⠀⠀

데스크톱은 봐주고 모바일은 안 봐준다⠀

⠀⠀⠀

같은 페이지를 데스크톱 탭으로 재면 전혀 다른 조건이 적용됩니다⠀

데스크톱 테스트는 다운로드 약 10Mbps, 지연 40ms 수준의 광대역 환경에서 진행됩니다⠀

여기에는 CPU 감속도 걸리지 않아서, 자바스크립트 실행이든 화면 렌더링이든 컴퓨터가 가진 처리 속도 그대로 계산됩니다⠀

⠀⠀⠀

⠀⠀⠀

모바일 탭은 1.6Mbps 회선에 CPU 4배 감속까지 얹어 재고, 데스크톱 탭은 10Mbps 회선에 감속 없이 잽니다⠀

앞서 본 100ms짜리 자바스크립트 작업이 데스크톱에서는 그대로 100ms로 남지만, 모바일 조건에서는 400ms로 늘어나 잡힙니다⠀

100KB 정도인 CSS 파일 하나도 대역폭만 단순 계산하면 데스크톱(10Mbps)에서는 약 80ms, 모바일(1.6Mbps)에서는 약 500ms가 걸립니다. 여기에 지연 시간(150ms 대 40ms)이 요청마다 더해지니 실제 시뮬레이션 값은 이보다 더 벌어질 수 있습니다⠀

Lighthouse는 기본값으로 ‘시뮬레이션 스로틀링’이라는 방식을 써서, 실제 느린 환경을 통째로 재현하는 대신 계산으로 그 상황을 다시 만들어냅니다⠀

⠀⠀⠀

렌더링을 막는 CSS가 있는 페이지라면, 이 계산 방식 위에서 대기 시간이 한 번 더 쌓이게 됩니다⠀

결과 화면에서 데스크톱 탭과 모바일 탭을 나란히 눌러보면, 같은 항목이라도 걸린 시간이 몇 배씩 차이 나는 것을 눈으로 보게 됩니다⠀

사이트 코드를 한 줄도 바꾸지 않았는데도, 어느 탭을 누르느냐에 따라 이만큼 다른 조건 위에서 시간이 매겨지고 있습니다⠀

Core Web Vitals 항목인 LCP나 CLS 값도 이 두 탭에서 서로 다른 조건 위에서 각각 계산됩니다⠀

⠀⠀⠀

같은 사이트인데 점수는 왜 다를까⠀

⠀⠀⠀

결국 같은 워드프레스 사이트라도 모바일 탭과 데스크톱 탭이 서로 다른 환경을 가정하고 점수를 매기기 때문에 성적표가 갈리게 됩니다⠀

다만 이 차이를 전부 측정 조건 탓으로 돌리기는 어렵습니다⠀

⠀⠀⠀

반응형 이미지 없이 데스크톱용 원본 사진을 그대로 올려두면, 휴대폰이 그 큰 파일을 받아 줄여서 표시하느라 시간이 더 걸립니다⠀

내 사이트가 여기에 해당하는지는 감으로 짐작하기보다 두 군데에서 직접 보는 편이 확실합니다. Lighthouse의 이미지 크기 감사 문서를 보면, 화면에 표시되는 크기(기기 픽셀 비율 반영)보다 실제 파일이 4KiB 이상 클 때 이 항목에 걸립니다⠀

1. PSI 모바일 탭의 진단 항목에서 ‘이미지 크기 조정’ 또는 이와 비슷한 이름의 항목을 찾아 펼칩니다. 걸려 있는 이미지 주소와 줄일 수 있는 용량이 나옵니다. Lighthouse 13부터는 이 감사가 ‘이미지 전송 개선’ 인사이트로 합쳐져 이름이 다르게 보일 수 있습니다⠀
2. PC 크롬에서 그 글을 열고 F12로 개발자 도구를 연 뒤, 요소 탭에서 해당 이미지에 마우스를 올려 ‘표시 크기’와 ‘원본 크기’를 비교합니다. 예를 들어 화면에는 360px 폭으로 보이는데 원본이 2000px 폭이라면 휴대폰이 필요 이상으로 큰 파일을 받고 있는 것입니다⠀
3. 같은 요소의 img 태그에 srcset 속성이 있는지도 봅니다. 워드프레스는 미디어 라이브러리로 올린 이미지에 보통 srcset을 자동으로 붙이지만, 테마나 빌더가 원본 크기 이미지를 직접 불러오거나 HTML에 주소를 고정해 넣었다면 빠져 있을 수 있습니다⠀
4. 네트워크 탭에서 페이지를 새로고침하고 이미지 필터로 좁힌 뒤, 크기 열의 다운로드 용량이 큰 파일 순으로 봅니다. 표시 크기에 비해 용량이 유난히 큰 파일이 위쪽에 모여 있다면 개선 대상입니다⠀

고친 뒤에는 같은 URL로 PSI를 다시 돌려 그 항목에서 이미지가 빠졌는지, 네트워크 탭의 용량이 줄었는지를 같은 방식으로 확인하면 됩니다⠀

렌더링을 막는 CSS나 무거운 플러그인 스크립트도 느린 조건 위에서는 그 무게가 훨씬 크게 드러나게 됩니다⠀

필드 데이터 칸에는 LCP 2.5초 이하, INP 200ms 이하, CLS 0.1 이하를 ‘좋음’ 구간으로 나눈 표도 함께 뜹니다⠀

⠀⠀⠀

⠀⠀⠀

이 표는 앞서 본 28일치 실제 방문자 값을 백분위수로 묶어 판정한 결과라서, 실험실 데이터와는 따로 봐야 합니다⠀

web.dev의 Core Web Vitals 안내에 따르면 이 판정은 모바일과 데스크톱을 구분해, 페이지 로드의 75번째 백분위수 값이 세 지표 모두 기준을 넘길 때 통과로 봅니다⠀

개인적으로는 자바스크립트 용량이 1메가바이트를 넘는 페이지라면, 점수 차이를 테스트 조건 탓만으로 보기는 어렵다고 봅니다⠀

이 기준은 제 판단이고 공식 수치는 아닙니다. 다만 앞서 본 HTTP Archive 수치에서 모바일 페이지 자바스크립트 전송량 중앙값이 558KB 정도이니, 그 두 배 가까이 되는 페이지는 4배 감속 아래에서 부담이 클 수밖에 없다는 계산이 깔려 있습니다⠀

⠀⠀⠀

실험실 점수와 필드 데이터가 서로 다른 말을 할 때는 이렇게 읽어볼 수 있습니다⠀

• 실험실 모바일 점수는 낮은데 필드 데이터는 ‘좋음’인 경우: 실제 방문자의 기기와 회선이 도구의 가정보다 좋거나 캐시 덕을 보고 있을 가능성이 큽니다. 이때는 점수 숫자에 너무 겁먹지 않아도 됩니다⠀
• 실험실 점수는 괜찮은데 필드 데이터가 나쁜 경우: 실제 방문자 중 오래된 기기나 느린 회선이 많거나, 광고·분석 스크립트가 방문 때마다 다르게 로드될 수 있습니다. 이쪽이 더 신경 써야 할 신호입니다⠀
• 필드 데이터 칸이 비어 있는 경우: 페이지별 방문 기록이 부족해서일 수 있고, 안내에 따르면 이때는 사이트 전체 단위 데이터로 대신 보여주기도 합니다⠀

⠀⠀⠀

WP Rocket이라는 캐시 플러그인에는 모바일 기기에 별도 캐시 파일을 만드는 옵션이 있어, 반응형 테마가 아니거나 모바일 전용 요소를 쓰는 사이트에 도움이 된다고 안내되어 있습니다⠀

이 이야기를 꺼낸 이유는, 모바일에서만 달라 보이는 느림이 점수 조건 때문만이 아니라 모바일에만 나오는 요소 때문일 수도 있어서입니다⠀

WP Rocket 모바일 캐시 문서에 따르면 이 옵션은 플러그인을 활성화하면 기본으로 켜지며, 휴대폰에만 모바일 캐시를 주고 태블릿에는 데스크톱 캐시를 줍니다. 문서에 특정 버전은 적혀 있지 않으니 사용 중인 버전에 따라 화면 구성이 다를 수 있습니다⠀

플러그인을 쓰고 있다면 설정 화면의 ‘모바일 캐시’ 항목이 켜져 있는지 그 화면에서 살펴볼 수 있습니다⠀

반응형 테마를 쓰고 있고 모바일 전용 요소가 따로 없다면, 이 옵션을 굳이 켜두지 않아도 되는 경우가 많다고 문서에 적혀 있습니다⠀

⠀⠀⠀

실제 휴대폰에서 직접 확인하는 방법⠀

⠀⠀⠀

PageSpeed Insights 점수는 가상 환경 값이라, 지하철에서 느꼈던 그 느림을 확인하려면 실제 휴대폰으로 한 번은 봐야 합니다. 어렵지 않은 방법부터 순서대로 적어봅니다⠀

1. 와이파이를 끄고 모바일 데이터로 같은 글을 열어봅니다. 와이파이에서는 빠르고 데이터에서만 느리다면 사이트보다 회선 쪽 영향이 큽니다⠀
2. 시크릿 탭으로 열어 처음 방문하는 사람과 같은 조건을 만듭니다. 캐시가 남아 있으면 평소엔 빠르게 느껴지기 때문입니다⠀
3. 모바일에서만 나타나는 요소가 있는지 봅니다. 하단 고정 배너, 팝업, 모바일 전용 메뉴나 광고 영역은 데스크톱에서는 보이지 않아서 놓치기 쉽습니다⠀
4. 안드로이드 폰이라면 PC 크롬에 USB로 연결해 실제 기기의 로딩 과정을 DevTools로 볼 수 있습니다⠀

네 번째 방법은 크롬 원격 디버깅 문서를 기준으로 하면 이렇게 진행합니다. 휴대폰의 개발자 옵션에서 USB 디버깅을 켜고, PC 크롬 주소창에 chrome://inspect/#devices 를 입력합니다. 휴대폰을 케이블로 연결해 화면에 뜨는 허용 창을 승인하면 기기 이름이 나타납니다. 이후 휴대폰 크롬에서 연 탭 아래의 ‘Inspect’를 누르면 네트워크 탭에서 어떤 요청이 오래 걸리는지 실제 기기 기준으로 볼 수 있습니다⠀

이렇게 보면 시뮬레이션 점수에서는 안 보이던 것, 예를 들어 모바일에서만 늦게 도는 광고 스크립트 같은 것이 드러나기도 합니다. 제목의 상황이 점수 때문인지 실제 요소 때문인지를 여기서 가릴 수 있습니다⠀

⠀⠀⠀

점수를 줄이는 순서와 예시 측정표⠀

⠀⠀⠀

정리하면 줄이는 순서는 이렇습니다. 한 번에 여러 개를 바꾸지 않는 것이 핵심입니다. 무엇이 효과가 있었는지 알 수 없게 되기 때문입니다⠀

1. PSI 모바일 탭에서 진단 항목의 ‘기본 실행 스레드 작업’ 세부 내역을 열어 시간이 큰 스크립트 한두 개를 고릅니다⠀
2. 주소의 폴더 이름으로 어느 플러그인이나 테마 소속인지 찾습니다⠀
3. 백업 후 그 플러그인 하나만 비활성화합니다. 꼭 필요한 기능이라면 가벼운 대체 플러그인이 있는지 먼저 살펴봅니다⠀
4. 같은 URL을 같은 탭(모바일)에서 다시 재고, 숫자를 기록합니다. 같은 페이지도 실행할 때마다 점수가 달라질 수 있으니 서너 번 재서 비슷한 값인지 보는 편이 안전합니다⠀
5. 효과가 없다면 다시 켜고 다음 후보로 넘어갑니다⠀

3번의 백업과 비활성화는 운영 중인 사이트라면 조금 더 조심해서 하시는 편이 좋습니다. 백업은 호스팅 업체가 제공하는 백업 기능이나 백업 플러그인으로 하되, 글과 설정이 들어 있는 데이터베이스와 업로드한 파일이 있는 wp-content 폴더가 함께 담기는지 확인해 두세요. 백업 파일이 사이트 밖에 따로 내려받아져 있어야 문제가 생겼을 때 되돌릴 수 있습니다⠀

비활성화한 직후에는 점수를 재기 전에 먼저 기능이 깨지지 않았는지 봅니다. 슬라이더나 팝업이 사라졌는지, 문의 양식이 열리고 전송되는지, 메뉴와 검색이 동작하는지, 결제나 회원 기능이 있다면 그 화면이 정상인지를 모바일 화면으로 확인하는 정도면 충분합니다. 광고나 분석 코드를 넣어주던 플러그인이라면 수익이나 통계 수집이 멈출 수 있으니, 방문자가 적은 시간대에 짧게 끄고 확인하는 쪽을 권합니다. 가능하다면 운영 사이트보다 복사본(스테이징)에서 먼저 해보시는 것이 가장 안전합니다. 점수는 좋아졌는데 쓰던 기능이 없어진 것이라면 개선이 아니라 기능을 맞바꾼 것이니, 그 기능이 꼭 필요한지는 함께 따져 보셔야 합니다⠀

아래 표는 기록 방식을 보여드리기 위한 예시입니다. 제가 측정한 값이 아니고, 모바일과 데스크톱 점수가 이 정도로 벌어질 수 있다는 가정의 숫자입니다⠀

항목 (예시)	모바일 탭	데스크톱 탭
성능 점수	48	86
LCP	5.8초	1.6초
총 차단 시간(TBT)	1,150ms	120ms
자바스크립트 전송량	1.4MB	1.4MB

자바스크립트 전송량은 같은데 시간 항목만 몇 배씩 벌어지는 것이 이 글에서 말한 조건 차이의 모습입니다. 이어서 스크립트를 하나 껐을 때 어떻게 기록하면 되는지도 예시로 보겠습니다⠀

모바일 탭 (예시)	비활성화 전	슬라이더 플러그인 끈 후
성능 점수	48	63
TBT	1,150ms	420ms
자바스크립트 전송량	1.4MB	0.9MB

이렇게 한 가지만 바꾸고 전후를 적어두면, 나중에 어떤 변경이 도움이 됐는지 근거가 남습니다. 예시의 숫자는 실제 사이트 값으로 바꿔서 쓰시면 됩니다⠀

⠀⠀⠀

오늘 본 모바일 탭 점수와 옆에 있는 데스크톱 탭 점수를 화면 그대로 스크린샷으로 남겨두면, 나중에 무엇이 달라졌는지 비교할 기준이 됩니다⠀

결과 화면 맨 위에는 테스트를 돌린 날짜와 시각도 함께 찍혀 있어, 이 기록과 나란히 남겨두면 좋습니다⠀

한 가지 더, 이 기록은 실험실 값과 필드 값을 따로 남기셔야 합니다. 실험실 값은 고친 직후 다시 재면 바로 달라지지만, 필드 데이터는 최근 28일치 방문자 기록을 묶은 값이라 고친 날부터 서서히 섞여 들어갑니다. 고친 직후에 필드 데이터가 그대로라고 해서 효과가 없었다고 판단하면 안 됩니다⠀

• 고친 날짜를 적어두고, 그날 실험실 값(성능 점수, TBT, LCP)을 서너 번 재서 기록합니다⠀
• 2주쯤 뒤와 4주쯤 뒤에 같은 URL의 PSI 모바일 탭 필드 데이터 칸(LCP, INP, CLS)을 다시 열어 기록합니다. 4주가 지나면 28일 구간이 고친 뒤의 방문자로 거의 채워지므로 그때 값을 비교 기준으로 삼으면 됩니다⠀
• 그 사이에 다른 플러그인이나 테마를 바꾸면 어느 변경의 효과인지 가려내기 어려워지니, 필드 데이터를 지켜보는 동안에는 큰 변경을 미루는 편이 좋습니다⠀

⠀⠀⠀

이 글의 수치와 설명은 2026년 10월 10일에 위에 링크한 공식 문서를 다시 열어 확인한 내용입니다. 도구와 플러그인 화면은 버전에 따라 달라질 수 있고, 문서가 바뀌면 이 글도 함께 고치겠습니다. 수정 기록: 2026-10-10 실제 휴대폰 확인 방법, 해결 순서, 출처 링크 추가⠀