AI로 홈페이지를 만든 뒤 화면이 늦게 뜬다면, 속도 측정 도구를 돈 내고 살 필요는 없습니다. 구글이 무료로 열어 둔 도구 두 개로 원인이 있는 자리까지 좁혀집니다. 주소만 넣으면 되는 PageSpeed Insights 로 느린 항목을 먼저 보고, 크롬에 이미 들어 있는 개발자도구 Lighthouse 로 같은 항목이 또 지적되는지 확인한 다음, 가장 무거운 파일 하나부터 줄이면 됩니다.
다만 점수를 열기 전에 알아 둘 것이 하나 있습니다. 만든 지 얼마 안 된 사이트는 PageSpeed Insights 위쪽의 실사용자 데이터 칸이 비어 있습니다. 측정이 실패한 것도, 사이트가 잘못된 것도 아닙니다. 왜 비는지는 아래에서 조건과 함께 설명합니다.
핵심 요약
- 무료 도구 두 개로 시작하면 됩니다 - 주소만 넣는 PageSpeed Insights, 크롬에 포함된 개발자도구 Lighthouse.
- 점수보다 먼저 볼 숫자는 LCP 2.5초, INP 200밀리초, CLS 0.1 입니다. 이 셋이 양호 기준선입니다.
- 방문자가 적으면 실사용자 데이터는 아예 수집되지 않습니다. 그때는 실험실 측정만 보고 고치면 됩니다.
- 고칠 순서는 용량이 큰 파일부터입니다. 모바일 첫 화면 용량에서 가장 큰 덩어리는 사진입니다.
사이트가 느리다는 말은 어떤 숫자로 재나요?
느리다는 느낌은 세 가지 숫자로 나뉩니다. 구글이 코어 웹 바이탈이라고 부르는 값인데, 하는 일만 보면 단순합니다.
- LCP - 화면에서 가장 큰 사진이나 글이 눈에 보이기까지 걸린 시간입니다. 2.5초 이하면 양호입니다.
- INP - 버튼이나 메뉴를 눌렀을 때 화면이 반응하기까지 걸린 시간입니다. 200밀리초 이하면 양호입니다.
- CLS - 읽는 중에 화면이 덜컥 밀리는 정도입니다. 0.1 이하면 양호입니다.
세 숫자는 75번째 사용자를 기준으로 봅니다(web.dev 공식 기준, 2026년 10월 확인). 가장 잘 나온 한 번이 기준이 아니라, 들어온 사람 100명 중 75명이 그 안에 들어와야 양호로 잡힙니다. 그래서 내 휴대폰에서 한 번 빨랐다는 것만으로는 판단하기 어렵습니다.
이 세 숫자를 알면 말이 달라집니다. 「우리 사이트가 느려요」 라고 적으면 고칠 곳이 안 보이지만, 「큰 사진이 뜨는 데 4초가 걸립니다」 라고 적으면 고칠 곳이 사진 한 장으로 좁혀집니다. 측정을 먼저 하라는 말은 결국 할 일을 한 줄로 줄이라는 뜻입니다.
세 숫자는 서로 원인이 다릅니다. LCP 는 주로 큰 파일과 서버 응답 때문에 늘어나고, INP 는 외부에서 불러오는 스크립트가 많을 때 나빠지고, CLS 는 사진이나 광고 자리의 크기를 미리 잡아 두지 않았을 때 생깁니다. 그래서 어느 숫자가 기준 밖인지 보면 어느 쪽을 들여다볼지도 같이 정해집니다.
실험실 점수와 실사용자 점수는 무엇이 다른가요?
둘 다 진짜 값인데 재는 대상이 다릅니다. 실험실 측정은 도구가 정해진 조건에서 사이트를 한 번 열어 본 기록이고, 실사용자 측정은 크롬을 쓰는 사람들이 실제로 열었던 기록을 모은 값입니다.
차를 살 때 시험 주행과 한 달 출퇴근 기록의 차이와 비슷합니다. 시험 주행은 원할 때 몇 번이고 해 볼 수 있지만, 실제 길에서 어땠는지는 시간이 지나야 쌓입니다.
여기서 한 번 생각해 볼 질문이 있습니다. “실험실 점수가 95점인 사이트와, 실사용자 LCP 가 2.3초인 사이트 중 어느 쪽이 빠른 사이트일까요?” 비교 자체가 성립하지 않는 질문입니다. 95점은 아직 아무도 들어오지 않은 사이트의 시험 주행 기록일 수 있고, 2.3초는 이미 수천 명이 겪은 결과일 수 있습니다. 숫자가 높은 쪽이 좋은 게 아니라, 지금 필요한 쪽이 좋은 숫자입니다. 고칠 곳을 찾는 중이라면 실험실 값을, 검색에서 어떻게 평가받는지 보려면 실사용자 값을 봅니다.
이 구분을 모르면 엉뚱한 결론이 나옵니다. 사진을 다 줄였는데 실사용자 칸이 그대로라서 효과가 없다고 판단하는 경우가 그렇습니다. 실사용자 값은 최근 28일 수집분이라 어제 고친 내용이 바로 반영되지 않습니다.
| 무료 도구 | 나오는 숫자 | 데이터 종류 | 쓰는 조건 |
|---|---|---|---|
| PageSpeed Insights | 성능 점수 0~100 (90 이상 양호) | 최근 28일 실사용자 + 실험실 1회 | 로그인 없이 주소 입력 |
| 크롬 개발자도구 Lighthouse | 성능 점수 0~100, 파일별 용량 KB | 내 컴퓨터 실험실 1회 | 크롬에 기본 포함 |
| 서치콘솔 코어 웹 바이탈 보고서 | LCP 2.5초·INP 200ms·CLS 0.1 기준 통과 여부 | 최근 28일 실사용자 | 사이트 소유 확인 필요 |
| 크롬 UX 리포트 | 75번째 사용자 기준 값 | 실사용자 누적 | 색인 가능 + 최소 방문자 수 |
확인 기준 : 2026년 10월
1. PageSpeed Insights
구글이 운영하는 무료 측정 페이지입니다. 주소를 넣으면 모바일과 PC 결과가 각각 나오고, 위쪽에는 최근 28일 실사용자 데이터, 아래쪽에는 그 자리에서 돌린 실험실 결과가 함께 표시됩니다(구글 공식 안내, 2026년 10월 확인).
어떤 경우에 맞나 - 처음 한 번 재 볼 때 가장 빠릅니다. 설치도 로그인도 필요 없습니다.
주의점 - 실사용자 칸이 비어 있어도 아래 실험실 결과는 그대로 나옵니다. 두 칸을 같은 값으로 읽으면 고친 효과를 잘못 판단하게 됩니다.
2. 크롬 개발자도구 Lighthouse
크롬 브라우저에 이미 들어 있는 기능입니다. 사이트를 열고 개발자도구를 띄운 뒤 Lighthouse 에서 측정하면 점수와 함께 어떤 파일이 몇 KB인지까지 목록으로 보여 줍니다.
어떤 경우에 맞나 - 아직 공개하지 않은 임시 주소, 로그인 뒤 화면, 검색에 올라가지 않은 페이지를 잴 때입니다. 외부 도구로 접근이 안 되는 화면도 측정됩니다.
주의점 - 내 컴퓨터 성능과 인터넷 상태가 점수에 섞입니다. 다른 탭을 닫고 두세 번 재서 가운데 값을 쓰는 편이 안전합니다.
3. 구글 서치콘솔 코어 웹 바이탈 보고서
사이트 전체를 묶어서 LCP·INP·CLS 가 기준 안에 들어오는지 보여 줍니다. 비슷한 모양의 페이지끼리 묶어 주므로 어느 유형이 미달인지 한눈에 들어옵니다.
어떤 경우에 맞나 - 페이지가 여러 장이고, 이미 방문자가 쌓여 있을 때입니다.
주의점 - 사이트 소유 확인을 해야 열립니다. 여기 나오는 값도 실사용자 누적값이라 고친 효과가 바로 보이지 않습니다.
4. 크롬 UX 리포트
앞의 두 도구에 나오는 실사용자 숫자의 원천 자료입니다. 공개 데이터라 직접 조회해 비교해 볼 수도 있습니다.
어떤 경우에 맞나 - 같은 업종 다른 사이트의 실사용자 값을 같은 기준으로 견줄 때입니다.
주의점 - 포함 조건이 있습니다. 검색에 색인될 수 있는 공개 페이지여야 하고, 최소 방문자 수를 넘어야 들어갑니다. 그 기준 숫자는 공개되어 있지 않습니다(크롬 공식 문서, 2026년 10월 확인).
5. WebPageTest
측정 위치와 회선 속도, 기기 조건을 골라 잴 수 있는 도구입니다. 파일이 하나씩 받아지는 과정을 가로 막대로 펼쳐 보여 주기 때문에, 어떤 파일이 다른 파일을 기다리게 만드는지 보입니다.
어떤 경우에 맞나 - 특정 지역에서만 느리다는 말을 들었을 때, 또는 파일 순서를 봐야 할 때입니다.
주의점 - 무료로 쓸 수 있는 횟수와 조건은 서비스마다 다르고 수시로 바뀝니다. 쓰기 전에 가입 화면의 현재 안내를 확인하시면 됩니다.
6. GTmetrix
점수와 함께 개선 항목을 목록으로 정리해 주는 측정 서비스입니다. 보고서가 남아 고치기 전과 후를 같은 형식으로 비교하기 편합니다.
어떤 경우에 맞나 - 작업 기록을 남기면서 단계별로 비교하고 싶을 때입니다.
주의점 - 무료 계정은 측정 횟수와 지역, 보관 기간에 제한이 있습니다. 숫자는 서비스 정책에 따라 달라지니 안내 화면에서 확인하는 게 맞습니다.
7. 호스팅 쪽 무료 점검 도구
속도보다 먼저 걸러야 할 경우도 있습니다. 느린 게 아니라 간헐적으로 열리지 않는 상황입니다. 아이비전트도 무료 도구로 웹사이트 상태 점검, 도메인 후이즈 조회, 내 IP 주소 확인을 열어 두고 있습니다.
어떤 경우에 맞나 - 주소를 입력했는데 어떤 때는 열리고 어떤 때는 안 열릴 때입니다. 도메인 연결 문제부터 끊고 가야 측정이 의미가 있습니다.
주의점 - 상태 점검은 응답 여부를 보는 도구입니다. 화면 체감 속도는 위의 측정 도구와 같이 봐야 합니다.
속도 점수는 몇 점이면 괜찮은가요?
90점 이상이면 양호, 50~89점은 개선 필요, 50점 미만은 미흡입니다(구글 공식 안내 기준, 2026년 10월 확인). 다만 100점을 목표로 삼을 필요는 없습니다. 점수는 여러 측정값을 섞어 만든 요약이고, 검색 쪽에서 실제로 보는 값은 LCP·INP·CLS 세 개입니다.
보는 순서를 이렇게 정해 두면 헛일이 줄어듭니다.
- LCP·INP·CLS 가 기준 안에 들어오는지 먼저 확인합니다.
- 기준 밖인 항목만 골라 그 아래 원인 목록을 읽습니다.
- 점수는 고친 뒤 얼마나 움직였는지 비교하는 용도로만 씁니다.
점수 한 자리를 올리려고 코드 구조를 바꾸는 경우가 많은데, 그 시간에 사진 한 장을 줄이는 쪽이 체감이 큽니다. 점수는 결과이고, 숫자 세 개가 원인에 가깝습니다.
실사용자 데이터 칸이 비어 있으면 어떻게 하나요?
방문자가 적은 사이트는 그 칸이 채워지지 않습니다. 실사용자 값은 크롬 UX 리포트에서 오는데, 여기에 들어가려면 검색에 색인될 수 있는 공개 페이지여야 하고 최소 방문자 수를 넘어야 합니다. 기준 숫자는 공개되지 않았습니다. 새로 만든 소규모 사이트가 여기 안 들어가는 건 흔한 일입니다.
그러니 공개 직후라면 할 일은 세 가지입니다.
- 실험실 측정만으로 고칠 곳을 찾습니다. 데이터가 쌓이기를 기다릴 필요가 없습니다.
- 검색 차단 설정이 걸려 있지 않은지 확인합니다. 색인을 막아 두면 방문자가 늘어도 실사용자 데이터는 쌓이지 않습니다.
- 공개 후 한 달쯤 지나 다시 열어 실사용자 칸이 생겼는지 봅니다. 이 값은 최근 28일 수집분입니다.
무엇이 무거워서 느려지나요?
요즘 홈페이지의 용량부터 보면 짐작이 쉽습니다. HTTP Archive 의 웹 알마낙 2025년판(2025년 7월 수집, 2026년 1월 공개)에 따르면 모바일 첫 화면 용량 중간값은 2,164KB 였고, 그중 사진이 911KB, 자바스크립트가 646KB 였습니다.
절반 가까이가 사진이라는 뜻입니다. AI로 만든 한 장짜리 사이트는 이 비율이 더 기울기 쉽습니다. 큰 배경 사진 한 장, 웹폰트 두세 벌, 스크롤 효과 스크립트가 기본으로 들어가기 때문입니다.
짐을 내릴 때 제일 무거운 가방부터 빼는 것처럼, 용량이 큰 파일부터 손대면 같은 노력으로 더 크게 줄어듭니다. 측정 도구의 파일 목록을 용량 순으로 정렬하는 것만으로 작업 순서가 정해집니다.
파일 크기와 별개로 서버가 첫 응답을 주는 시간도 봅니다. 이 값은 0.8초 이하면 양호, 0.8~1.8초는 개선 필요, 1.8초를 넘으면 미흡으로 봅니다(web.dev 기준, 2026년 10월 확인). 사진을 다 줄였는데도 LCP 가 내려가지 않으면 이 구간을 들여다봐야 합니다.
원인을 찾는 순서
1단계 - 느린 페이지 한 장을 정합니다
사이트 전체가 아니라 주소 하나로 시작합니다. 첫 화면과 내용 페이지는 들어가는 파일이 달라서 원인도 다릅니다.
2단계 - 모바일 결과를 먼저 봅니다
PageSpeed Insights 에서 모바일 쪽을 먼저 확인합니다. 들어오는 사람 대부분이 휴대폰이고, 기준도 모바일이 더 까다롭습니다.
3단계 - 기준 밖인 숫자만 적어 둡니다
LCP·INP·CLS 중 기준을 넘은 항목만 메모합니다. 전부 적으면 뭘 먼저 할지 다시 헷갈립니다.
4단계 - 실험실로 다시 재서 겹치는지 봅니다
크롬 개발자도구 Lighthouse 로 같은 주소를 두 번 재 봅니다. 같은 항목이 또 지적되면 구조 문제이고, 한 번만 나오면 그때의 회선 상태일 수 있습니다.
5단계 - 용량 큰 파일 세 개를 적습니다
파일 목록을 용량 순으로 정렬해 위에서 세 개만 적습니다. 보통 사진, 글꼴, 외부 스크립트 중 하나입니다.
6단계 - 하나만 고치고 다시 잽니다
두 개를 같이 고치면 무엇이 효과였는지 알 수 없습니다. 한 번에 하나씩, 고친 뒤 같은 조건으로 다시 재서 비교합니다.
여기까지가 무료 도구로 할 수 있는 범위입니다. 유료 도구는 이 과정을 자동으로 반복하고 기록해 주는 역할이라, 처음 원인을 찾는 단계에서는 무료로 충분합니다.
원인별로 무게를 줄이는 방법
- 사진 - 화면에 보이는 크기보다 큰 원본을 그대로 올리지 않습니다. 첫 화면 배경은 보이는 폭에 맞춰 줄이고, 아래쪽 사진은 스크롤할 때 뒤늦게 불러오게 둡니다.
- 글꼴 - 웹폰트는 굵기 종류를 줄입니다. 본문 한 벌, 제목 한 벌이면 대개 충분하고, 안 쓰는 굵기를 빼면 그만큼 내려갑니다.
- 외부 스크립트 - 채팅 상담, 통계, 지도처럼 밖에서 불러오는 조각이 늘면 INP 가 먼저 나빠집니다. 지금 안 쓰는 것부터 뺍니다.
- 영상 - 첫 화면에 자동재생 영상을 두면 LCP 는 거의 내려가지 않습니다. 정지 사진으로 바꾸고 재생은 눌렀을 때로 미룹니다.
- 서버와 회선 - 위를 다 하고도 첫 응답이 느리면 호스팅 쪽을 봅니다. 가까운 곳에서 파일을 보내 주는 CDN 이 켜져 있는지, 압축이 걸려 있는지부터 확인하시면 됩니다.
자주 묻는 질문
점수가 100점이어야 검색에 잘 나오나요?
아닙니다. 점수는 요약값이고 검색 쪽이 보는 건 LCP·INP·CLS 입니다. 90점대에 들어왔다면 그다음은 내용과 검색어 쪽을 손보는 편이 효과가 큽니다.
모바일과 PC 점수가 많이 다른데 어느 쪽을 봐야 하나요?
방문자 비율이 높은 쪽입니다. 대개 모바일입니다. 두 값은 측정 조건이 달라서 서로 비교할 대상이 아닙니다.
잴 때마다 점수가 달라지는 이유가 무엇인가요?
실험실 측정은 그때의 회선과 서버 상태를 같이 담기 때문입니다. 두세 번 재서 가운데 값을 기록하면 흔들림이 줄어듭니다.
구글 모바일 친화성 테스트 주소가 열리지 않습니다
그 도구는 종료되었습니다. 구글 공식 문서에도 종료 표기가 붙어 있고, 대신 크롬 Lighthouse 와 PageSpeed Insights 의 모바일 결과를 쓰라고 안내하고 있습니다.
사진 형식을 바꾸면 얼마나 줄어드나요?
사진마다 다릅니다. 바꾸기 전 용량과 바꾼 뒤 용량을 측정 도구의 파일 목록에서 직접 비교하시면 됩니다. 숫자는 그 사이트의 사진이 알려 줍니다.
페이지가 한 장인 사이트도 측정할 필요가 있나요?
있습니다. 한 장짜리는 첫 화면에 모든 파일이 몰려 있어서 사진 한 장만 커도 전체가 늦어집니다. 오히려 고칠 곳이 적어 금방 끝납니다.
같은 작업을 아이비전트에서 하면 어디까지 자동인가요?
위 순서에서 손이 많이 가는 칸은 보통 서버 쪽입니다. 압축, CDN, 인증서 같은 설정은 사이트를 만드는 일과 상관없는데도 따로 챙겨야 하기 때문입니다.
아이비전트 AI 호스팅은 결제 즉시 계정이 만들어지고, 무료 SSL 이 자동 발급되며 글로벌 CDN 가속과 DDoS 방어가 기본으로 켜집니다. 트래픽 제한도 없습니다. AI로 만든 정적 사이트는 ZIP 으로 올리거나 Git 으로 바로 배포할 수 있고, xxx.ibigent.com 주소가 즉시 나오기 때문에 공개 전에 Lighthouse 로 미리 재 보기에도 이 임시 주소가 편합니다.
요금은 14일 무료체험이 있고, 내 도메인 연결과 광고 관리가 함께 필요하면 베이직부터 보시면 됩니다. 구성은 요금제 안내와 AI 호스팅 소개에 정리돼 있습니다.
고치는 과정도 줄일 수 있습니다. 편집 화면에서 바꾸고 싶은 부분만 골라 말로 고치면 되므로, 사진을 가벼운 것으로 교체하는 반복 작업을 코드를 열지 않고 끝낼 수 있습니다.
속도는 한 번 재 보면 다음에 할 일이 분명해집니다. 목적을 먼저 정하고 비교해서 고르시면 됩니다.
확인 기준 : 2026년 10월
