웹사이트 속도 측정은 구글 PageSpeed Insights에 주소를 넣는 것이 가장 빠른 방법입니다. 실제 방문자 기준 수치는 구글 서치 콘솔의 코어 웹 바이탈 보고서로, 느린 원인은 크롬 개발자 도구와 WebPageTest로 찾습니다. 이 글은 사이트 속도 측정 도구별 사용법과, 측정 결과를 보고 고치는 순서를 정리했습니다.
웹사이트 속도는 왜 측정해야 하나요?
속도는 방문자가 직접 느끼는 사용 경험이고, 구글도 코어 웹 바이탈을 순위 시스템에 사용한다고 밝힙니다. 다만 구글은 좋은 점수가 상위 노출을 보장하지 않으며, 언제나 가장 관련성 높은 콘텐츠를 먼저 보여 주려 한다고 덧붙입니다. 그래서 속도는 구글 SEO의 다른 기본기와 함께, 방문자의 불편을 찾는 지표로 보는 것이 맞습니다.
사이트 속도 측정에서는 어떤 지표를 보나요?
핵심은 코어 웹 바이탈 3가지(LCP·INP·CLS)이고, 원인을 좁힐 때 FCP와 TTFB를 함께 봅니다. 2024년 3월 12일부터 응답성 지표는 FID 대신 INP를 씁니다. 기준은 실제 방문의 75번째 백분위 값입니다.
| 지표 | 의미 | 좋음 | 개선 필요 | 나쁨 |
|---|---|---|---|---|
| LCP | 가장 큰 콘텐츠가 표시되는 시간 | 2.5초 이하 | 2.5~4초 | 4초 초과 |
| INP | 클릭·입력 후 화면이 반응하는 시간 | 200ms 이하 | 200~500ms | 500ms 초과 |
| CLS | 화면이 예기치 않게 밀리는 정도 | 0.1 이하 | 0.1~0.25 | 0.25 초과 |
| FCP | 첫 콘텐츠가 표시되는 시간 | 1.8초 이하 | 1.8~3초 | 3초 초과 |
| TTFB(실험) | 서버가 첫 바이트를 보내는 시간 | 0.8초 이하 | 0.8~1.8초 | 1.8초 초과 |
웹사이트 속도 측정 사이트는 어디를 쓰나요?
무료로 쓸 수 있는 도구 네 가지면 충분합니다. 하나는 점수를, 하나는 실제 방문자 데이터를, 나머지는 원인을 보여 줍니다.
1. 구글 PageSpeed Insights
PageSpeed Insights는 주소 하나로 모바일·데스크톱 성능을 보여 줍니다. 위쪽의 실제 사용자 데이터는 크롬 사용자 경험 보고서(CrUX)의 최근 28일 값이고, 아래쪽 성능 점수는 Lighthouse가 모의 환경에서 측정한 실험실 데이터입니다. 점수는 90점 이상 좋음, 50~89점 개선 필요, 50점 미만 나쁨입니다. 방문자가 적은 페이지는 실제 데이터 대신 사이트 전체 값이 나오거나 아예 나오지 않을 수 있습니다. 화면 읽는 법은 PageSpeed Insights 사용법에 자세히 정리했습니다.
2. 서치 콘솔 코어 웹 바이탈 보고서
코어 웹 바이탈 보고서는 서치 콘솔에 사이트를 등록하면 볼 수 있습니다. CrUX의 실제 방문자 데이터로 비슷한 페이지끼리 묶어 기기별로 좋음·개선 필요·나쁨을 표시하므로, 사이트 전체에서 어느 유형의 페이지가 느린지 한눈에 찾을 때 씁니다. 데이터가 부족한 URL 그룹은 보고서에 나오지 않습니다.
3. 크롬 개발자 도구(Lighthouse·네트워크)
크롬에서 F12로 개발자 도구를 열면 Lighthouse 패널에서 바로 측정할 수 있고, 네트워크 패널에서 파일별 로딩을 볼 수 있습니다. 네트워크 패널의 ‘캐시 사용 중지’를 켜면 처음 방문한 사람과 비슷한 조건이 되고, 제한(Throttling) 메뉴의 ‘Slow 4G’로 느린 모바일 환경을 흉내 낼 수 있습니다. 표 머리글을 오른쪽 클릭해 Protocol 열을 켜면 파일이 HTTP/2(h2)로 오는지도 확인됩니다.
4. WebPageTest
WebPageTest는 실제 브라우저로 여러 지역·기기·네트워크 조건에서 페이지를 불러 보는 도구입니다. 로딩 과정을 영상으로 남기고 DNS·TCP·TLS 같은 연결 단계를 파일별로 나눠 보여 주므로, 어떤 CSS·JS·이미지가 늦게 오는지 찾을 때 유용합니다. 한국 방문자가 많다면 가까운 테스트 위치를 골라 측정합니다.
페이지 로딩 속도 측정은 어떤 순서로 하나요?
- PageSpeed Insights에서 홈과 방문이 많은 글 2~3개를 모바일 기준으로 측정하고 LCP·INP·CLS 값을 적어 둡니다.
- 서치 콘솔 코어 웹 바이탈 보고서에서 ‘나쁨’ 또는 ‘개선 필요’ URL 그룹을 확인합니다.
- 느린 페이지를 크롬 개발자 도구나 WebPageTest로 열어 늦게 오는 파일을 찾습니다.
- 아래 개선 방법을 한 번에 하나씩 적용하고, 같은 조건으로 다시 측정해 비교합니다.
- 실제 사용자 데이터는 28일 단위로 쌓이므로 서치 콘솔 보고서는 몇 주 뒤에 다시 봅니다.
측정 후 웹사이트 속도는 어떻게 개선하나요?
대부분의 사이트는 이미지, 서버 응답, 폰트, 렌더링을 막는 CSS·JS 순서로 고치면 효과가 큽니다. 구글 web.dev 가이드의 권장 사항을 기준으로 정리했습니다.
1. 이미지 용량 줄이기
이미지는 화면 크기에 맞게 줄이고 압축합니다. TinyPNG 같은 압축 도구를 쓰거나 WebP로 바꾸면 됩니다. 구글에 따르면 무손실 WebP는 PNG보다 26%, 손실 WebP는 비슷한 화질의 JPEG보다 25~34% 작습니다. 첫 화면의 가장 큰 이미지(LCP 이미지)에는 지연 로딩을 쓰지 말고, 모든 이미지에 width·height를 적어 화면 밀림(CLS)을 막습니다.
<!-- 첫 화면의 대표 이미지: 우선 불러오기 -->
<img src="hero.webp" width="1200" height="630" fetchpriority="high" alt="대표 이미지 설명">
<!-- 스크롤해야 보이는 이미지: 지연 로딩 -->
<img src="chart.webp" width="800" height="450" loading="lazy" alt="차트 설명">2. 서버 응답 시간(TTFB) 줄이기
서버가 멀거나 느리면 모든 지표가 함께 늦어집니다. 리디렉션 단계를 줄이고, 방문자와 가까운 곳에서 파일을 보내는 CDN 캐시를 씁니다. 한국 방문자가 대부분인데 서버가 해외에 있다면 서울 지역 서버를 고를 수 있는 호스팅으로 옮기는 것도 방법입니다.
3. 웹 폰트 줄이기
가장 빠른 폰트는 요청하지 않는 폰트입니다. 쓰는 폰트 수와 굵기를 줄이고, WOFF2 형식과 필요한 글자만 남긴 서브셋을 씁니다. 외부 폰트 서비스를 쓴다면 <head>에 preconnect를 넣고, 폰트가 늦게 와도 글자가 먼저 보이도록 font-display를 지정합니다. 폰트를 직접 호스팅한다고 저절로 빨라지지는 않으므로 측정으로 확인합니다.
4. 렌더링을 막는 CSS·JS 줄이기
<head> 안의 큰 CSS와 동기 스크립트는 화면 표시를 늦춥니다. 스크립트는 defer로 미루고, 인라인은 아주 작은 CSS·JS에만 씁니다. 큰 파일을 모두 HTML에 넣으면 오히려 문서가 무거워집니다. 클릭 반응(INP)이 느리다면 오래 걸리는 자바스크립트 작업을 잘게 나눕니다.
5. 워드프레스 캐시 플러그인
워드프레스는 LiteSpeed Cache 같은 캐시 플러그인으로 페이지를 미리 만들어 두면 서버 응답이 빨라집니다. 캐시 플러그인은 서로 충돌할 수 있으니 하나만 쓰고, 쓰지 않는 플러그인은 정리합니다. 설정 항목은 LiteSpeed Cache 설정 안내(영문)를, 워드프레스 전반의 점검은 워드프레스 SEO 가이드를 참고하세요.
속도 측정에서 자주 하는 실수는 무엇인가요?
- 점수만 보기: Lighthouse 점수는 네트워크 상태, 브라우저 확장 프로그램, 광고 등 조건에 따라 측정할 때마다 달라질 수 있습니다. 실제 방문자 데이터(LCP·INP·CLS)를 함께 봅니다.
- 데스크톱만 재기: 구글은 모바일 버전으로 색인하므로 모바일 결과를 먼저 봅니다.
- 로그인한 상태로 재기: 관리자로 로그인하면 캐시를 건너뛰는 경우가 많아 실제보다 느리게 나옵니다.
- 한꺼번에 여러 개 바꾸기: 무엇이 효과를 냈는지 알 수 없습니다. 하나씩 바꾸고 다시 잽니다.
속도 외의 기술 점검 항목은 테크니컬 SEO 체크리스트에서 이어서 확인할 수 있습니다.
PageSpeed Insights 점수와 서치 콘솔 결과가 왜 다른가요?
보는 데이터가 다르기 때문입니다. PageSpeed Insights의 성능 점수는 Lighthouse가 한 번 모의로 불러온 실험실 결과이고, 서치 콘솔 코어 웹 바이탈 보고서는 실제 크롬 사용자들의 최근 데이터를 묶은 결과입니다. 서치 콘솔이 코어 웹 바이탈 상태를 판정할 때 쓰는 것은 실제 사용자 데이터입니다.
방문자가 적은 사이트도 속도를 측정할 수 있나요?
측정할 수 있습니다. 실제 사용자 데이터가 부족하면 PageSpeed Insights와 서치 콘솔에 현장 데이터가 나오지 않을 수 있지만, Lighthouse 실험실 측정과 WebPageTest는 방문자 수와 상관없이 언제든 돌려 볼 수 있습니다.
속도 개선 결과는 언제 확인할 수 있나요?
실험실 측정은 고친 직후 바로 다시 재 보면 됩니다. 실제 사용자 데이터는 최근 28일 기준으로 쌓이므로, 서치 콘솔 코어 웹 바이탈 보고서에 반영되기까지는 몇 주가 걸립니다.