PageSpeed API 429, 18번 요청이 모두 막힌 이유
블로그 속도를 숫자로 남기려고 PageSpeed Insights API를 스크립트로 호출했다. 2026년 10월 13일, 홈과 최신 글 2개를 mobile과 desktop으로 나눠 6개 조합을 만들고 조합마다 3번씩, 모두 18번 요청했다. 18번 모두 HTTP 429 RESOURCE_EXHAUSTED 였고, 응답에는 quota_limit_value: "0" 이 들어 있었다. 이 글은 PageSpeed API에서 429를 받고 "블로그가 문제인가" 하고 멈춘 사람을 위한 판독 순서다. 목표는 응답 필드로 사이트 문제와 측정 도구의 quota 문제를 가르고, 점수를 추정하지 않고 미측정으로 남긴 뒤, 다음 측정 경로를 고르는 것이다. 먼저 범위를 밝힌다. 이 글은 차단을 해결한 기록이 아니다. 이 날 점수는 끝내 얻지 못했고, 아래의 다음 경로도 아직 시도하지 않았다. 무슨 일이 있었나 호출한 것은 PageSpeed Insights API v5의 runPagespeed 메서드였고, 요청 경로는 /pagespeedonline/v5/runPagespeed?url=<인코딩한 URL>&strategy=mobile|desktop 형식이었다. 요청 주소에는 url 과 strategy 두 파라미터만 있었다. 스크립트는 429를 받으면 2초, 다시 받으면 4초를 기다렸다가 재시도했다. 조합마다 3번, 6개 조합이라 18번이다. 결과는 하나도 다르지 않았다. 18번 모두 429였고, Lighthouse 점수도, LCP·INP·CLS도, CrUX 실사용 값도 받지 못했다. 같은 날 같은 블로그의 공개 페이지는 정상이었다. Chrome 일반 UA와 Googlebot UA로 표본 11개 URL과 모바일 변형을 요청한 44번이 모두 HTTP 200이었다. 1단계: 응답의 service·reason·quota 필드를 읽는다 받은 응답 하나를 옮긴다. consumer와 project 번호는 지웠고, 반복되는 mess...