워드프레스 속도, 도구마다 점수가 다른 이유
Table of contents
도구마다 점수가 다르면 한쪽이 고장 났다고 여기기 쉽지만, 한 도구 화면 안에서도 숫자는 두 갈래로 계산됩니다.⠀
한 주소를 PageSpeed Insights, GTmetrix, WebPageTest에 넣으면 숫자가 제각각이라 무엇이 맞는지 막막해집니다.⠀
플러그인 하나를 끄고 다시 쟀더니 점수는 올랐는데 PageSpeed Insights 위쪽 칸은 그대로라면, 어느 숫자를 믿어야 할까요?⠀
먼저 답부터 적어 두면, 세 도구는 측정 서버의 위치, 흉내 내는 기기, 네트워크 속도 제한이 서로 달라서 같은 주소도 다른 점수가 나옵니다. 거기에 PageSpeed Insights는 실제 방문자 기록이라는 전혀 다른 종류의 데이터를 위쪽에 함께 보여 줍니다. 그래서 이 글은 점수를 올리는 방법보다 숫자를 읽는 법에 무게를 둡니다. 사진이나 플러그인을 손보는 절차는 아래에서 걸리는 부분만 짚고, 자세한 내용은 따로 쓴 글로 넘깁니다.⠀
⠀⠀⠀
⠀⠀⠀
PSI 결과 화면의 두 가지 데이터⠀
⠀⠀⠀
잘 열리던 사이트가 어느 날부터 굼떠지면 처음엔 회선 탓인가 싶어 새로고침부터 몇 번 누르게 됩니다.⠀
다른 사이트는 멀쩡히 열리는데 내 사이트만 답답하다면 새로고침을 더 눌러도 달라지는 것이 없습니다.⠀
검색 결과마다 플러그인을 줄이라거나 캐시를 깔라거나 호스팅을 바꾸라는 말이 달라 손이 멈추게 됩니다.⠀
⠀⠀⠀
그쯤 PageSpeed Insights에 주소를 넣어 보면 결과 화면에 두 종류의 데이터가 함께 나옵니다.⠀
위쪽은 Chrome UX Report(CrUX)가 실제 방문자에게서 모은 실사용자 데이터입니다.⠀
아래쪽은 Lighthouse로 한 번 측정한 실험실 데이터입니다.⠀
⠀⠀⠀
둥근 원 안의 성능 점수는 아래쪽 실험실 데이터로만 계산됩니다.⠀
위쪽 실사용자 영역은 최근 28일 동안 쌓인 방문 기록을 p75 기준으로 보여 줍니다.⠀
p75는 방문의 75%가 이 값 이하라는 뜻입니다.⠀
나머지 25%의 방문은 그 값보다 나쁜 쪽에 있습니다.⠀
PageSpeed Insights 문서도 실사용자 데이터를 최근 28일, 75번째 백분위로 보여 준다고 설명합니다. 페이지 단위 데이터가 부족하면 사이트 전체(origin) 값으로 대신 보여 주기도 합니다. 출처: PageSpeed Insights 소개
⠀⠀⠀
원 안의 점수와 위쪽 값은 계산에 쓰는 데이터도 묶는 기간도 달라서 한 화면 안에서도 어긋나 보일 수 있습니다.⠀
내가 새로고침하며 느끼는 속도는 내 기기와 회선에서 겪은 한 번의 경험이라 위아래 어느 쪽과도 같은 기준이 아닙니다.⠀
결과 화면을 처음 열었다면 원 안의 점수보다 위쪽 영역의 LCP·INP·CLS 값을 먼저 봅니다.⠀
⠀⠀⠀
두 데이터의 차이를 표로 줄이면 이렇습니다.
| 구분 | 위쪽 (실사용자) | 아래쪽 (실험실) |
|---|---|---|
| 데이터 출처 | CrUX, 실제 방문자 | Lighthouse가 한 번 돌린 측정 |
| 기간 | 최근 28일 | 측정 버튼을 누른 그 순간 |
| 표시 방식 | p75 값 | 0~100점 성능 점수 |
| 바꾼 직후 반영 | 방문이 쌓이는 만큼 천천히 | 바로 반영 |
| 잘 맞는 용도 | 실제 방문자가 느린지 판단 | 원인을 찾고 전후 비교 |
⠀⠀⠀
도구별 측정 조건 차이⠀
세 도구가 모두 실험실 쪽이라고 해서 같은 조건에서 재는 것은 아닙니다. 서버가 어디에 있는지, 어떤 기기를 흉내 내는지, 네트워크를 얼마나 느리게 만드는지에 따라 같은 사이트도 점수가 크게 갈립니다. 기본값을 문서에서 확인해 보면 이렇습니다.
| 도구 | 측정 위치 | 기기 | 네트워크 |
|---|---|---|---|
| PageSpeed Insights | Google 데이터센터. 북미·유럽·아시아 중 한 곳이고 Lighthouse 보고서의 환경(environment) 항목에 표시됩니다 | 모바일은 중급 기기(Moto G4급) 에뮬레이션, 데스크톱은 유선 환경 에뮬레이션 | 모바일은 모바일 네트워크 스로틀링 적용 |
| GTmetrix | 클라우드 데이터센터. 로그인하면 위치를 바꿀 수 있습니다 | Chrome 브라우저. 기기 크기는 결과 화면의 분석 옵션에서 확인합니다 | 기본은 스로틀링 없는 빠른 연결. 로그인하면 속도를 바꿀 수 있습니다 |
| WebPageTest | 기본 Dulles(미국 버지니아) | 기본 Chrome. 모바일 기기와 에뮬레이션은 직접 고릅니다 | 기본 Cable 프로필(5Mbps 다운로드, 1Mbps 업로드, 지연 28ms). 느린 3G 같은 프로필을 고를 수 있습니다 |
출처: PageSpeed Insights 소개, DebugBear의 GTmetrix 설명, WebPageTest Legacy API 문서. WebPageTest 기본값은 이 API 문서 기준이어서 화면의 기본 선택이나 버전에 따라 다를 수 있으니, 측정 전 설정 화면에서 한 번 확인하세요.
이 표에서 제가 먼저 보는 곳은 네트워크 칸입니다. GTmetrix가 속도 제한 없는 연결에서 재는 동안 PageSpeed Insights 모바일은 느린 모바일 연결을 흉내 내니, 같은 사이트라도 GTmetrix 쪽이 좋게 나오기 쉽습니다. 서버가 멀리 있으면 응답이 늦어지는 것도 한 이유라서, 방문자 대부분이 한국에 있다면 측정 위치가 한국과 먼 도구일수록 불리하게 나올 수 있습니다.
GTmetrix 쪽 근거는 서드파티 글에만 기대지 않으려고 GTmetrix 공식 블로그도 확인했습니다. 공식 블로그는 기본 연결을 제한 없는 Unthrottled로 두고, 이 속도가 실제 방문자와 맞지 않을 수 있다고 안내합니다. WebPageTest는 기본이 Cable이고, PageSpeed Insights는 연결 속도를 직접 바꿀 수 없다고도 비교해 둡니다. 다만 기본 측정 위치는 안내 글마다 서술이 달라서 이 글에서는 단정하지 않으니, 측정 전에 분석 옵션 화면에서 직접 확인하세요. 출처: GTmetrix, Set Default Analysis Options
예를 들어 같은 글 주소를 같은 날 잰다면 다음과 같은 모양으로 나올 수 있습니다. 아래 수치는 조건 차이를 보여 주려고 만든 예시이며 실제 측정 결과가 아닙니다.
| 도구 (예시) | 측정 조건 | 점수·등급 | LCP |
|---|---|---|---|
| PageSpeed Insights 모바일 | 중급 기기, 모바일 스로틀링 | 58점 | 4.1초 |
| PageSpeed Insights 데스크톱 | 유선 에뮬레이션 | 91점 | 1.3초 |
| GTmetrix | 스로틀링 없는 연결 | B 등급 | 1.8초 |
| WebPageTest | Dulles, Chrome, Cable | (점수 대신 지표별 평가) | 2.4초 |
이럴 때 어느 쪽이 틀렸다고 볼 수는 없습니다. 모바일 조건에서 4초 넘게 걸리는 사이트가 속도 제한 없는 연결에서는 2초 안팎으로 열린 것뿐입니다. 방문자가 주로 쓰는 환경에 가까운 조건을 기준 삼아 하나를 골라 두고, 그 도구 안에서만 전후를 비교하는 편이 덜 헷갈립니다.
연결 설정마다 무엇이 잘 보이고 무엇을 놓치는지도 나눠 두면 어떤 조건을 고를지 정하기 쉽습니다. 이 표는 위 기본값과 각 조건의 성격을 정리한 것입니다.
| 연결 설정 | 잘 보이는 것 | 놓치기 쉬운 것 |
|---|---|---|
| 제한 없음(GTmetrix 기본) | 서버 응답과 렌더링처럼 네트워크와 무관한 병목 | 용량이 큰 사진이나 스크립트가 느린 회선에서 주는 부담 |
| PSI 모바일 스로틀링 | 모바일 방문자가 겪는 큰 파일과 요청 수의 영향 | 빠른 회선을 쓰는 방문자의 체감, 연결 조건을 바꿔 볼 여지 |
| WebPageTest Cable(기본) | 일반 가정 회선 수준에서의 중간 지점 | 모바일 방문자가 많을 때 실제보다 낙관적일 수 있음 |
| WebPageTest 느린 3G 등 | 최악에 가까운 조건에서 무엇이 먼저 터지는지 | 대부분의 방문자와 동떨어진 조건이라 점수를 그대로 믿기는 어려움 |
GTmetrix는 무엇이 사이트를 느리게 하는지 구체적으로 짚어 보는 실험실 도구로 소개됩니다.⠀ 클라우드 데이터센터에서 브라우저로 페이지를 열어 재는 방식이라는 설명은 DebugBear의 GTmetrix 소개 글에서 확인할 수 있습니다.
도구끼리 조건을 최대한 맞추고 싶다면 이 순서로 합니다.
- 방문자가 주로 쓰는 기기(모바일/데스크톱)를 먼저 정합니다. 위쪽 실사용자 영역도 모바일과 데스크톱이 따로 나뉘기 때문입니다.
- GTmetrix는 로그인해서 연결 속도와 위치를 PageSpeed Insights 모바일에 가깝게 고릅니다. 기본값은 속도 제한이 없어 가장 좋게 나오는 쪽입니다.
- WebPageTest에서는 기본 Cable 대신 느린 3G 같은 프로필을 고르고, 가능하면 방문자와 가까운 위치를 고릅니다.
- 세 도구 모두 같은 주소, 같은 시간대에 재고, 점수가 흔들리니 여러 번 재서 중간값을 봅니다.
- 그래도 숫자가 똑같아지지는 않습니다. 측정 위치와 브라우저 버전, 점수 계산 방식이 다르기 때문이니, 조건을 맞추는 목적은 숫자를 일치시키는 것이 아니라 방향이 같은지 보는 것입니다.
조건을 맞췄는데도 숫자가 이상하게 나오는 경우가 있어서, 자주 만나는 예외도 적어 둡니다.
- 방문이 적은 글은 위쪽 실사용자 영역이 비어 있거나 사이트 전체 값으로 대신 나올 수 있습니다. 이때는 그 글만의 값으로 읽으면 안 됩니다.
- 캐시가 비어 있을 때의 첫 측정은 느리게 나오고 바로 다시 재면 빨라질 수 있습니다. 그래서 첫 결과 하나로 판단하지 않고 몇 번 잰 중간값을 봅니다.
- 쿠키 동의창이나 팝업, 지역별 리다이렉트가 있는 사이트는 도구가 보는 첫 화면과 방문자가 보는 첫 화면이 다를 수 있습니다. LCP 요소가 팝업이나 배너로 바뀌어 잡히는 경우가 여기에 해당합니다.
- CDN이나 캐시 플러그인을 쓰면 측정 위치마다 캐시에 걸리는지가 달라서, 같은 시각에 재도 도구별 서버 응답 시간이 어긋납니다.
⠀⠀⠀
잴 때마다 점수가 달라지는 이유와 조건 맞추기⠀
⠀⠀⠀
같은 주소를 연달아 재도 성능 점수는 한 번의 실험실 측정으로 매겨져 매번 조금씩 흔들릴 수 있습니다.⠀
PageSpeed Insights와 GTmetrix, WebPageTest는 모두 실험실 쪽이지만 측정 위치와 조건이 도구마다 다릅니다.⠀
실험실 데이터는 통제된 환경에서 모아 원인을 찾는 데 쓸모가 있습니다.⠀
실제 환경의 병목은 놓칠 수 있어서 위쪽 실사용자 값과 결과가 다를 수 있습니다.⠀
⠀⠀⠀
위쪽 실사용자 영역은 여러 방문자의 기록을 p75로 묶은 값이라 한 번 잰 점수보다 덜 흔들립니다.⠀
서버 응답이 느린지 가늠할 때는 오르내리는 점수보다 이 위쪽 값을 기준으로 삼습니다.⠀
서버 응답은 TTFB로 따로 봅니다. web.dev는 TTFB가 0.8초 이하면 좋음, 1.8초를 넘으면 나쁨으로 보고, Core Web Vitals 지표는 아니어서 다른 지표에 영향이 없다면 반드시 맞출 필요는 없다고 안내합니다. PageSpeed Insights의 실사용자 영역에는 실험적 지표로 TTFB가 함께 나오기도 합니다. 이 값이 높은데 LCP도 같이 나쁘다면 사진보다 서버 응답이나 캐시를 먼저 의심해 볼 만합니다. LCP와 TTFB를 나눠 보는 방법은 워드프레스 이미지 최적화 후 느릴 때 확인하는 방법에 적어 두었습니다. 출처: web.dev TTFB
⠀⠀⠀
점수가 잴 때마다 달라도 위쪽 값까지 계속 나쁜 쪽에 머문다면 실제 방문자들도 같은 느림을 겪고 있을 수 있습니다.⠀
반대로 위쪽 값은 괜찮은데 점수만 오르내린다면 서버나 PHP 설정에는 손대지 않고 그대로 둡니다.⠀
⠀⠀⠀
WebPageTest는 Catchpoint가 지원하는 오픈소스 실험실 도구로, 느린 3G나 구형 기기 조건을 흉내 낼 수 있습니다.⠀
위쪽 값은 나쁜데 아래쪽 점수만 좋게 나온다면 WebPageTest에서 느린 3G 조건을 골라 같은 주소를 넣어 봅니다.⠀
느린 조건에서도 빠른 조건에서도 똑같이 늦게 열리기 시작한다면 서버 응답 쪽일 수도 있습니다.⠀
조건을 바꿔 재도 위쪽 값만큼 느리고 플러그인을 하나씩 꺼 봐도 차이가 없다면 그때 호스팅 업체에 문의합니다.⠀
⠀⠀⠀
⠀⠀⠀
사진 교체 전후 비교하기⠀
⠀⠀⠀
Google Search Console의 Core Web Vitals 보고서도 CrUX 실사용자 데이터를 바탕으로 합니다.⠀
모바일과 데스크톱으로 나뉜 ‘개선 필요’·’나쁨’ URL 그룹에 사진이 많은 글이 몰려 있는지 훑어봅니다.⠀
모바일 쪽에만 그룹이 잡혀 있다면 그 글을 스마트폰으로 직접 열어 사진이 뜨는 모습을 봅니다.⠀
⠀⠀⠀
메인 화면은 멀쩡한데 그 그룹에 든 글 하나가 무겁게 열린다면 본문 사진의 용량을 미디어 라이브러리에서 살펴봅니다.⠀
다른 사진보다 용량이 눈에 띄게 큰 파일이 있다면 그 파일이 첫 후보가 될 수 있습니다.⠀
여러 장이 모두 크다면 글 첫머리에 놓인 사진부터 교체 후보로 둡니다.⠀
휴대폰 원본을 그대로 올린 사진이라면 WebP나 AVIF로 줄인 파일로 바꿔 올려 볼 수 있습니다.⠀
어느 크기와 품질로 줄일지는 글의 표시 크기와 화면 배율에 따라 달라서 이 글에서 하나의 숫자로 정해 드리기는 어렵습니다. 표시 크기에 맞는 파일을 고르고 교체하는 과정은 사진 많은 워드프레스 속도 개선하는 방법에, 큰 사진에 붙는 -scaled 파일과 원본 보존은 워드프레스 -scaled 파일이 생기는 이유와 원본 보존 확인 방법에 정리해 두었습니다. 이 글은 교체한 뒤 숫자를 어떻게 읽을지에만 집중합니다.
⠀⠀⠀
PageSpeed Insights에는 메인 주소 대신 그 글의 주소를 넣어 따로 잽니다.⠀
성능 점수는 측정 버튼을 누를 때마다 그 순간의 페이지로 새로 계산됩니다.⠀
사진을 바꾸고 다시 재면 아래쪽 점수는 곧바로 오를 수 있습니다.⠀
⠀⠀⠀
위쪽 실사용자 영역에는 사진을 바꾸기 전의 방문 기록이 아직 섞여 있어 같은 날에는 달라지지 않을 수 있습니다.⠀
사진을 바꾼 뒤의 방문이 쌓일수록 위쪽 값도 새 사진 기준의 기록으로 채워집니다.⠀
⠀⠀⠀
⠀⠀⠀
플러그인을 하나씩 꺼서 비교하기⠀
⠀⠀⠀
느려졌다고 느낀 날짜를 떠올려 두고, 그 무렵 업데이트 날짜가 찍힌 플러그인을 목록에서 추려 봅니다.⠀
업데이트 날짜가 겹치는 플러그인이 없다면 그 무렵 새로 설치한 플러그인을 후보로 올립니다.⠀
사이트 전체를 백업해 둔 뒤 후보 가운데 하나만 비활성화하고 나머지는 그대로 둡니다.⠀
끄기 전에 PageSpeed Insights 성능 점수를 한 번 재 두고, 끈 직후 같은 주소로 다시 잽니다.⠀
⠀⠀⠀
이때 전후를 나란히 놓을 수 있는 숫자는 아래쪽 실험실 점수뿐입니다.⠀
위쪽 칸에는 아직 플러그인이 켜져 있던 날의 방문이 남아 있습니다.⠀
사진을 바꿀 때와 같은 이유로 위쪽 칸은 당일 비교에서 빼 두고, 28일 뒤 기록과 따로 비교합니다.⠀
⠀⠀⠀
GTmetrix 등급은 PageSpeed Insights 점수와 섞지 않고 끄기 전후의 GTmetrix 결과끼리만 나란히 놓습니다.⠀
⠀⠀⠀
두세 개를 한꺼번에 끄면 점수가 올라도 어느 플러그인의 몫인지 가려낼 수 없습니다.⠀
점수에 차이가 보였다면 그 플러그인은 꺼 둔 채 다음 날 한 번 더 재 봅니다.⠀
차이가 없다면 그 플러그인을 다시 켠 다음 목록의 다음 후보 하나로 넘어갑니다.⠀
하나씩 끌 때 기록이 어떤 모양이 되는지 예시로 보여 드립니다. 아래 값은 읽는 방법을 보여 주려는 예시이며 실제 측정 결과가 아닙니다.
| 단계 (예시) | 끈 것 | PSI 성능 점수 | 읽는 방법 |
|---|---|---|---|
| 0. 변경 전 | 없음 | 52, 55, 53 (중간값 53) | 같은 조건에서도 3점쯤 흔들리니 이 폭 안의 변화는 의미를 두지 않습니다 |
| 1. 후보 A 비활성화 | 후보 A | 54, 53, 55 (중간값 54) | 흔들림 폭 안이라 효과가 없다고 보고 A를 다시 켭니다 |
| 2. 후보 B 비활성화 | 후보 B | 66, 64, 67 (중간값 66) | 흔들림 폭을 넘는 변화라 B를 꺼 둔 채 다음 날 한 번 더 잽니다 |
이렇게 변경 전 값을 여러 번 재 두어야 “오른 건가, 흔들린 건가”를 가릴 수 있습니다. 플러그인은 개수보다 페이지마다 붙이는 스크립트와 쿼리의 양이 문제라서, 어떤 기준으로 후보를 거를지는 워드프레스 플러그인 몇 개가 적당한지보다 중요한 것에서 다룹니다. 이 글에서는 끈 뒤의 점수를 어떻게 읽는지까지만 봅니다.
⠀⠀⠀
⠀⠀⠀
순위 영향과 기준값, 기록표⠀
⠀⠀⠀
점수가 낮게 나온 날에는 검색 순위까지 떨어질까 걱정됩니다.⠀
Google이 원 안의 성능 점수를 순위에 쓴다고 밝힌 문서는 찾기 어렵습니다.⠀
실제 사용자 경험을 보는 기준에 가까운 쪽은 화면 위쪽에 28일치로 쌓이는 CrUX 실사용자 데이터입니다.⠀
Lighthouse 점수와 GTmetrix 등급, WebPageTest 지표는 고칠 곳을 찾는 진단용이라, 순위를 직접 정한다고 보기는 어렵습니다.⠀
다만 Google Search Central 문서는 Core Web Vitals를 실제 사용자 경험을 재는 지표 묶음으로 소개하고, 검색에서 성과를 내려면 좋은 상태를 유지하라고 권할 뿐입니다. 순위에 얼마나 반영되는지는 밝히지 않으니, 지표를 순위 보장 수단으로 읽기보다 방문자 경험을 점검하는 기준으로 보는 쪽이 안전합니다. 출처: Google Search Central, Core Web Vitals
⠀⠀⠀
Core Web Vitals의 ‘좋음’ 공식 기준은 LCP 2.5초 이하, INP 200ms 이하입니다.⠀
CLS는 0.1 이하가 기준이고, 세 지표 모두 p75 값에서 이 선을 넘지 않아야 통과로 봅니다.⠀
이 기준은 web.dev의 Web Vitals 문서에 나와 있고, 모바일과 데스크톱을 나누어 각각 평가합니다.
⠀⠀⠀
Site Kit은 Google이 만든 무료 워드프레스 플러그인입니다.⠀
Search Console과 PageSpeed Insights API를 대시보드에 이어 주니 관리자 화면에서 값을 열어 봅니다.⠀
⠀⠀⠀
기록표에는 성능 점수 칸과 실사용자 칸을 따로 나누고, 실사용자 칸에는 LCP·INP·CLS를 각각 적습니다.⠀
맨 앞 칸에는 측정 날짜를, 그 옆에는 그날 바꾼 사진이나 플러그인 이름을 적어 둡니다.⠀
GTmetrix 등급도 함께 본다면 점수 칸 옆에 한 칸을 따로 둡니다.⠀
⠀⠀⠀
Search Console에서 ‘나쁨’ 그룹에 든 글이 있다면 그 주소도 같은 날짜 줄에 옮겨 둡니다.⠀
개인적으로는 INP만 200ms를 넘는 사이트라면 기록표 실사용자 칸에서 INP 한 줄만 먼저 따라가도 된다고 봅니다.⠀
INP는 따라가기만 해서는 줄지 않으니, 숫자가 나쁠 때 어디를 볼지도 알아 둘 만합니다. web.dev는 INP를 입력 지연, 이벤트 처리 시간, 화면 표시 지연의 세 구간으로 나눠 봅니다. 구간별로 의심할 곳은 다음과 같습니다.
- 입력 지연이 길다면 페이지가 열리는 동안 스크립트를 내려받고 실행하느라 메인 스레드가 바쁜 경우입니다. 플러그인이 붙이는 자바스크립트가 많을 때 의심해 볼 수 있습니다.
- 처리 시간이 길다면 클릭이나 입력에 반응하는 코드가 한 번에 너무 많은 일을 하는 경우입니다.
- 표시 지연이 길다면 화면 구조(DOM)가 크거나 한꺼번에 많은 HTML을 그리는 경우입니다.
먼저 PageSpeed Insights 위쪽 실사용자 값으로 INP가 정말 나쁜지 확인한 뒤, 느린 상호작용을 직접 재현하고 Chrome DevTools 성능 패널에서 구간을 나눠 보는 순서를 권합니다. 출처: web.dev INP 최적화
⠀⠀⠀
기록표를 채우면 예를 들어 이런 모양이 됩니다. 아래 값은 작성 방법을 보여 주려는 예시이며 실제 측정 결과가 아닙니다.
| 측정일 (예시) | 바꾼 것 | 성능 점수 | GTmetrix 등급 | 실사용자 LCP | 실사용자 INP | 실사용자 CLS |
|---|---|---|---|---|---|---|
| 10월 1일 | 변경 전 | 54 | C | 3.4초 | 260ms | 0.08 |
| 10월 1일 | 첫머리 사진을 WebP로 교체 | 67 | B | 3.4초 (아직 이전 기록) | 260ms | 0.08 |
| 10월 29일 | 28일 뒤 재확인 | 66 | B | 2.7초 | 240ms | 0.07 |
교체 당일에는 성능 점수만 올랐고 실사용자 LCP는 그대로입니다. 28일이 지난 뒤에야 위쪽 값이 움직이는 모습이 이 글에서 말한 두 칸 구분입니다.
⠀⠀⠀
PageSpeed Insights의 실사용자 영역은 매일 갱신됩니다.⠀
기록표의 변경 날짜에서 28일이 지난 날, 같은 주소를 다시 넣어 위쪽 영역의 LCP·INP·CLS를 옮겨 적습니다.⠀
⠀⠀⠀
이 글의 기준값과 도구 설명은 2026년 10월 10일에 아래 문서에서 확인했습니다. 도구의 기본 설정과 화면은 바뀔 수 있으니 측정 전에 설정 화면을 한 번 더 확인하세요.
