PageSpeed 점수가 매번 다를 때｜3회 중간값으로 원인 찾기

같은 주소를 PageSpeed Insights에서 검사해도 모바일 점수가 52점, 68점, 61점처럼 달라질 수 있습니다. 이때 최고 점수만 믿거나 최저 점수만 보고 플러그인을 삭제하면 원인을 놓치기 쉽습니다. 점수는 서버 응답, 광고와 외부 요청, 캐시 상태, 테스트 순간의 실행 시간이 합쳐진 결과입니다.

PageSpeed 점수가 매번 다를 때는 점수 하나를 목표로 삼지 말고 같은 조건에서 세 번 측정해 중간값과 변동 폭을 기록하세요. 세 번 모두 반복된 LCP 요소, TBT와 CLS 문제를 찾으면 일시적 흔들림과 실제 병목을 구분할 수 있습니다.

10초 요약

• 위쪽 28일 현장 데이터와 아래쪽 Lighthouse 점수를 구분합니다.
• URL·기기·로그인·캐시 상태를 기록하고 같은 조건으로 세 번 측정합니다.
• 평균보다 가운데 값과 최고·최저의 차이를 봅니다.
• 세 번 반복된 지표와 원인 요소 한 가지를 우선합니다.
• 한 항목만 바꾼 뒤 기능 확인과 세 번의 재측정을 반복합니다.

현장 데이터와 실험실 점수 구분하기

Google 공식 안내에 따르면 현장 데이터는 다양한 실제 기기·네트워크의 분포이고, 실험실 데이터는 하나의 모의 환경에서 생성됩니다. 현장 데이터가 부족하면 URL 대신 출처 데이터가 나오거나 표시되지 않을 수 있습니다. 오늘 수정한 효과는 실험실과 개발자 도구로 먼저 확인하고 28일 데이터는 추세로 판단하세요.

실험실 90점이 실제 사용자 경험 통과를 보장하지 않으며, 현장 데이터가 좋다고 현재 배포에 문제가 없다는 뜻도 아닙니다. 두 영역이 다르면 오류가 아니라 서로 다른 질문의 답입니다. Search Console의 반영 시점은 Core Web Vitals 28일 데이터 읽는 법에서 확인할 수 있습니다.

점수가 흔들리는 원인 5가지

• 서버 상태: 캐시 미스, PHP·DB 작업과 순간 트래픽으로 TTFB가 달라집니다.
• 가변 콘텐츠: 광고, 추천, A/B 테스트로 요청과 LCP 요소가 바뀝니다.
• 외부 서비스: 광고·통계·폰트 제공사의 응답 경로와 시간이 달라집니다.
• 캐시 계층: CDN·페이지·객체 캐시가 차갑거나 예열된 결과가 섞입니다.
• 실행 환경: 테스트 위치와 순간 자원 경쟁으로 실험실 값도 변동할 수 있습니다.

첫 회만 느리고 다음 두 번이 비슷하면 캐시 미스와 서버 생성 시간을 분리해 보세요. 세 번마다 광고 요청과 LCP 요소가 달라지면 가변 콘텐츠를 기록합니다. 변동을 없애려 하기보다 어떤 조건에서 느린지를 찾는 것이 목적입니다.

세 번 측정하기 전 조건표

• 슬래시와 쿼리 문자열까지 동일한 공개 URL을 사용합니다.
• 모바일과 데스크톱 결과를 섞지 않습니다.
• 로그아웃 상태이며 우회·미리보기 주소가 아닌지 확인합니다.
• 캐시 삭제 직후의 첫 요청과 예열 상태를 별도 실험으로 나눕니다.
• 테스트 사이에 플러그인·광고·이미지 설정을 바꾸지 않습니다.
• 측정 시각과 배포·서버 장애 여부를 함께 기록합니다.

3회 측정 기록표

세 값을 크기순으로 놓고 가운데 값을 기준값으로 사용합니다. 최고와 최저 차이도 남기세요. 예를 들어 60·62·85점이면 가운데 값은 62점이고, 85점은 일시적으로 유리한 실행일 수 있습니다. 평균만 쓰면 한 번의 극단값이 기준을 끌어올릴 수 있습니다.

반복 패턴으로 원인 구분하기

TBT와 INP를 같은 값으로 보지 않기

Lighthouse는 실제 사용자 입력이 없는 페이지 로드이므로 INP를 직접 측정하지 않습니다. TBT는 로드 중 메인 스레드가 긴 작업에 막힌 시간을 보여주며 INP 문제를 찾는 실험실 대리 신호로 사용할 수 있습니다. TBT가 좋아져도 클릭·탭·키보드 입력의 INP 개선을 확정하지 말고 배포 후 현장 데이터나 직접 사용자 흐름으로 확인하세요.

한 번에 하나만 바꾸는 재측정

1. 현재 세 번의 결과와 화면을 저장합니다.
2. 반복된 지표와 진단 항목 하나만 고릅니다.
3. 원래 설정과 되돌릴 위치를 기록합니다.
4. 이미지 한 장 또는 스크립트 하나처럼 범위를 제한합니다.
5. 같은 캐시 조건과 URL에서 다시 세 번 측정합니다.
6. 메뉴·검색·폼·광고·모바일 화면을 직접 시험합니다.
7. 중간값이 좋아지고 기능이 정상일 때만 유지합니다.

첫 이미지가 반복 원인이면 워드프레스 이미지 최적화 점검법을, 첫 회만 느리다면 캐시 플러그인 설정과 오류 복구를 참고하세요. 점수가 올라도 기능이 깨졌다면 성공한 최적화가 아닙니다.

TIP

“모바일 점수 60점” 대신 “세 번의 중간값 62점, LCP 요소는 모두 대표 이미지, 첫 회 TTFB만 높음”처럼 기록하세요. 숫자와 반복 요소를 함께 남기면 다음 변경의 성공·실패와 원복 기준이 명확해집니다.

자주 묻는 질문

세 번이면 충분한가요?

빠른 운영 점검의 최소 비교 단위입니다. 변동 폭이 크거나 중요한 배포라면 횟수와 시간대를 늘리고 자체 RUM·서버 지표를 함께 봐야 합니다.

점수와 Core Web Vitals 중 무엇이 중요할까요?

점수는 진단을 요약하는 실험실 값입니다. 실제 사용자 경험은 LCP·INP·CLS 현장 데이터로 판단하되, 실험실 감사 항목으로 원인을 찾는 방식이 좋습니다.

공식 자료

• Google PageSpeed Insights 데이터 안내
• web.dev 현장·실험실 데이터 차이
• web.dev Total Blocking Time 안내
• web.dev INP 진단과 개선 안내

마무리

PageSpeed 점수 변동은 한 번의 숫자로 해결할 문제가 아닙니다. 현장 데이터와 실험실 결과를 구분하고 같은 조건의 세 번 중간값과 변동 폭을 기록하세요. 반복되는 LCP·TBT·CLS 원인 하나를 수정한 뒤 기능과 수치를 다시 비교하면 점수에 흔들리지 않고 실제 병목을 줄일 수 있습니다.