블로그 주소를 PageSpeed Insights에 넣으면 숫자 하나로 속도를 판정해 줄 것 같지만, 결과는 그렇게 단순하지 않았습니다. 2026년 10월 18일 오후 7시에 히든픽 홈페이지를 직접 검사하니 휴대전화 성능은 55점, 데스크톱은 66점이었습니다. 같은 주소라도 측정 환경이 달랐고, 실제 사용자 데이터가 없는 상태에서 나온 실험실 결과였습니다.
Google PageSpeed Insights는 공개 웹페이지의 모바일·데스크톱 사용자 경험을 살피고 개선 단서를 찾는 도구입니다. 이번 분석에는 회원가입·프로그램 설치·결제가 필요 없었습니다. 다만 한 번의 점수는 합격증이 아닙니다. 먼저 어떤 데이터인지 구분하고, 반복 검사에서 계속 나타나는 느린 구간을 찾아야 합니다.
같은 주소가 모바일 55점, 데스크톱 66점으로 갈렸다
https://hiddenpick.kr/을 한 번 분석한 결과는 다음과 같았습니다.
| 측정 항목 | 휴대전화 | 데스크톱 |
|---|---|---|
| 성능 점수 | 55 | 66 |
| FCP | 13.4초 | 2.9초 |
| LCP | 14.0초 | 3.2초 |
| TBT | 0밀리초 | 0밀리초 |
| CLS | 0 | 0.002 |
| Speed Index | 13.4초 | 2.9초 |
휴대전화 쪽은 에뮬레이션된 Moto G Power와 느린 4G 조건으로 표시됐고, 데스크톱은 별도의 에뮬레이션 환경을 사용했습니다. 따라서 55와 66의 차이는 실제 내 휴대전화와 PC를 같은 와이파이에서 재 본 값이 아닙니다. 서로 다른 조건에서 실행된 한 차례 진단값입니다.
URL 하나 넣고 기다린 뒤, 위쪽 두 줄부터 읽었다
첫 화면의 입력칸에 검사할 공개 주소를 붙여 넣고 분석을 누르면 됩니다. 결과가 나오면 휴대전화와 데스크톱 탭을 각각 열어 봅니다. 이번에는 분석 시각, 실제 사용자의 경험 확인하기, 성능 문제 진단하기 순서로 읽었습니다.
위쪽의 실제 사용자 영역은 최근 방문자 경험을 보여 주고, 아래쪽 진단 영역은 Lighthouse가 정해진 조건에서 페이지를 불러 본 결과입니다. 두 영역을 섞으면 “내 실제 방문자는 14초를 기다렸다”처럼 과한 결론을 내리기 쉽습니다.
화면은 한국어로 표시됐지만 FCP, LCP, TBT, CLS 같은 약어는 그대로였습니다. 콘텐츠가 처음 보이는 시점, 가장 큰 콘텐츠가 뜨는 시점, 입력을 막는 시간, 화면이 밀리는 정도로 나눠 보면 됩니다.
데이터 없음 아래의 숫자는 무엇을 뜻하나
이번 보고서의 실제 사용자 경험 영역에는 모바일과 데스크톱 모두 데이터 없음이 표시됐습니다. 오류라고 단정할 상황은 아닙니다. Google 공식 설명에 따르면 PageSpeed의 필드 데이터는 Chrome 사용자 환경 보고서인 CrUX를 사용하며, 최근 28일 동안 공개 페이지나 출처에 충분한 표본이 있어야 표시됩니다.
필드 데이터가 없어도 아래의 실험실 진단은 실행됩니다. 히든픽의 55점과 66점은 이 한 번의 시뮬레이션 값이며, 실제 방문자의 28일 경험을 뜻하는 Core Web Vitals 평가와 같지 않습니다.
이번 실행에서 먼저 손댈 후보는 세 가지였다
모바일 결과의 상위 인사이트에는 렌더링 차단 요청, 캐시 수명, 이미지 전송 개선이 차례로 보였습니다. 표시된 예상 절감값은 각각 12,730밀리초, 428KiB, 257KiB였습니다. 데스크톱에서도 같은 세 항목이 나타났고 예상값은 2,690밀리초, 721KiB, 407KiB였습니다.
이 예상값만큼 정확히 빨라진다고 단정할 수는 없습니다. 공식 Lighthouse 설명상 기회와 진단은 점수에 직접 더해지는 항목이 아니라 관련 지표를 개선할 단서입니다. 반복 측정에서도 같은 항목이 남는지 먼저 확인합니다.
이미지 전송 문제가 계속 보인다면 새 글의 이미지를 올리기 전부터 크기와 형식을 줄이는 편이 안전합니다. 히든픽의 Squoosh 이미지 압축 확인기와 iLoveIMG 이미지 크기 조절 가이드는 이 다음 작업을 직접 확인할 때 참고할 수 있습니다.
TBT와 CLS가 0이어도 빠르다는 뜻은 아니었다
모바일 결과에서 TBT는 0밀리초, CLS는 0이었습니다. 입력을 오래 막는 작업과 예기치 않은 화면 이동이 이번 실행에서는 크게 잡히지 않았다는 뜻에 가깝습니다. 동시에 FCP 13.4초와 LCP 14.0초는 콘텐츠가 보이기까지 오래 걸렸다는 신호였습니다.
한두 항목이 좋아도 전체 로딩이 빠르다고 볼 수 없습니다. 성능 점수는 여러 지표의 가중 평균이고 환경에 따라 달라집니다. 수정 전후에는 같은 URL과 기기 탭에서 여러 번 실행해 중앙값과 반복되는 문제를 봅니다.
공개 주소 점검에는 맞지만 비공개 페이지에는 맞지 않는다
PageSpeed Insights는 가입 없이 공개 페이지를 빠르게 진단하고, 개발자에게 전달할 개선 후보를 찾는 운영자에게 잘 맞습니다. 접근성·권장사항·검색엔진 최적화 항목도 함께 보여 주지만, 자동 검사가 사이트 품질 전체를 보장하지는 않습니다.
로그인 뒤에만 열리는 관리자 화면, 아직 외부에서 접근할 수 없는 개발 서버, URL에 토큰이나 민감한 쿼리가 들어간 페이지는 입력하지 않는 편이 안전합니다. 이번에는 누구나 볼 수 있는 히든픽 홈 주소만 사용했습니다. 정확한 원인을 코드 수준에서 찾으려면 브라우저 개발자 도구의 Lighthouse·Performance 패널과 서버 로그를 함께 봐야 합니다.
PageSpeed를 쓸 때 헷갈리기 쉬운 세 가지
90점이 안 나오면 공개하면 안 되나요? 90점 이상은 실험실 점수의 좋음 구간이지만 공개·AdSense 승인·검색 순위를 정하는 단일 합격선은 아닙니다.
왜 다시 누르면 점수가 달라지나요? 네트워크 경로, 기기 자원, 광고 같은 조건이 변동을 만듭니다. 한 번의 최고점보다 같은 조건의 반복 결과를 봅니다.
데이터 없음이면 끝인가요? 실제 사용자 표본은 없을 수 있지만 Lighthouse 실험실 진단과 개선 후보는 확인할 수 있습니다.
이번 측정에서 가장 중요한 결과는 55점이나 66점 자체보다, 모바일에서 콘텐츠 표시가 늦고 렌더링 차단·캐시·이미지 항목이 함께 나타났다는 점이었습니다. 다음 점검에서는 실제 수정 전 같은 조건으로 세 번 재고, 한 가지 변경 뒤 다시 측정해야 개선 효과를 비교할 수 있습니다.