페이지 속도는 웹페이지가 콘텐츠를 보여 주고 사용자 입력에 반응하는 빠르기를 뜻합니다. 서버가 응답하는 시간, 파일을 내려받는 시간, 브라우저가 화면을 그리고 JavaScript를 실행하는 시간이 영향을 줍니다. 본문이 보이는 시점과 버튼을 눌렀을 때 반응하는 시점은 다르므로 각각 측정합니다.
무엇이 느린지 구별하는 지표
서버 응답이 빠른데 화면이 늦게 나타나거나, 본문은 보여도 버튼이 반응하지 않을 수 있습니다. 지표를 나눠야 지연이 발생한 단계를 찾을 수 있습니다.
- TTFB: 페이지 탐색을 시작한 뒤 첫 응답 바이트를 받기까지 걸리는 시간
- FCP: 첫 텍스트나 이미지가 표시되기까지 걸리는 시간
- LCP: 화면의 가장 큰 콘텐츠 요소가 표시되기까지 걸리는 시간
- INP: 클릭, 탭, 키보드 입력 후 다음 화면 갱신까지의 지연을 관찰해 페이지의 반응성을 평가하는 지표
- CLS: 예상하지 못한 레이아웃 이동의 정도
코어 웹 바이탈은 LCP, INP, CLS로 로딩, 반응성과 화면 안정성을 평가합니다. CLS는 시간 지표가 아니라 화면이 얼마나 불안정하게 움직였는지를 나타냅니다. 따라서 점수가 나쁘다고 모든 문제를 파일 전송 속도로만 해결할 수는 없습니다.
실사용 데이터와 실험실 데이터의 용도
PageSpeed Insights는 실제 방문에서 수집한 데이터와 통제된 환경의 진단 결과를 구분해 제공합니다.
| 데이터 | 의미 | 용도 |
|---|---|---|
| 실제 사용자 데이터 | Chrome 사용자에게서 수집한 최근 28일의 경험 | 방문자가 겪은 성능과 Core Web Vitals 판정 |
| 실험실 데이터 | 통제된 기기와 네트워크 조건의 Lighthouse 검사 | 원인 진단과 수정 전후 비교 |
실제 사용자 데이터에는 수정 전후 방문이 최대 28일 동안 섞입니다. 배포 직후의 변화는 같은 조건의 실험실 검사로 먼저 비교하고, 이후 실제 사용자 지표가 개선되는지 확인합니다. 해당 URL의 표본이 부족하면 PageSpeed Insights가 여러 페이지를 묶은 origin 단위 데이터를 대신 보여 줄 수 있습니다. origin은 프로토콜, 호스트와 포트가 같은 주소의 범위이므로, 그 수치를 개별 페이지의 성능으로 해석하지 않도록 주의합니다.
페이지가 느려지거나 화면이 밀리는 원인
문제가 나타난 지표에 따라 조사할 대상을 좁힙니다. 아래는 가능한 원인을 찾는 출발점이며, 지표 하나만으로 원인을 확정하는 표는 아닙니다.
| 발견한 문제 | 확인할 내용 |
|---|---|
| 첫 응답부터 늦음 | 서버와 데이터베이스 처리뿐 아니라 리디렉션, DNS 조회, 연결 시간도 확인합니다. 캐시와 CDN이 응답을 재사용하는지도 봅니다. |
| 첫 화면이나 주요 콘텐츠가 늦게 보임 | 큰 이미지의 전송 시간, 렌더링을 막는 CSS와 JavaScript, 웹폰트 요청을 확인합니다. |
| 버튼을 눌러도 반응이 늦음 | 브라우저의 긴 JavaScript 작업과 광고, 분석, 채팅 스크립트가 입력 처리를 지연시키는지 확인합니다. |
| 읽던 화면이 밀림 | 이미지와 광고 영역의 크기를 미리 확보했는지, 나중에 나타난 콘텐츠나 글꼴이 배치를 바꾸는지 확인합니다. |
중요 페이지의 병목부터 잡는 순서
방문이 많거나 전환에 중요한 페이지에서 지연이 큰 구간부터 수정합니다. 진단 도구의 모든 권고를 동일한 우선순위로 처리할 필요는 없습니다.
- 대상 페이지와 기기를 정합니다. 상품 상세, 서비스 소개, 글 등 주요 템플릿에서 대표 URL을 고르고 모바일과 데스크톱 지표를 나눠 봅니다.
- 느린 구간을 찾습니다. Lighthouse 진단과 Network 패널에서 요청별 대기 및 전송 시간을 확인합니다. 입력 반응 문제는 개발자 도구의 Performance 패널에서 실제 조작을 기록해 조사합니다.
- 원인에 맞게 수정합니다. 주요 이미지가 늦게 내려오면 크기와 로딩 방식을, 첫 응답이 늦으면 서버 처리와 캐시를 우선 검토합니다.
- 같은 조건으로 다시 측정합니다. 수정 전후에 기기와 네트워크 조건을 맞추고, 메뉴와 문의 폼, 결제 등 해당 페이지의 주요 기능이 정상인지 확인합니다.
- 배포 후 실제 방문을 확인합니다. 수정일을 기록하고 최근 28일 데이터가 갱신되면서 같은 지표가 개선되는지 살펴봅니다.
속도와 검색 순위의 관계
Google은 순위 시스템에서 Core Web Vitals를 참고하고 전반적인 페이지 경험을 평가하도록 권장합니다. 좋은 성능만으로 상위 노출을 보장하지는 않으며 검색어와 콘텐츠의 관련성도 중요합니다.
진단 점수를 올리려고 상품 정보나 문의 기능을 없애면 방문자가 할 수 있는 일도 줄어듭니다. 필요한 내용과 기능은 유지하면서 불필요한 파일 요청이나 중복 실행을 줄이고, 수정 후 화면과 기능을 직접 확인합니다.
자주 묻는 질문
PageSpeed 점수는 100점이어야 하나요?
Lighthouse 성능 100점이 Google 상위 노출의 요건은 아닙니다. 총점만 보지 말고 실제 사용자 데이터에서 주요 콘텐츠 표시가 늦은지, 입력 반응이 늦은지 먼저 확인합니다. 실험실 점수는 높아도 실제 기기와 네트워크에서 문제가 나타날 수 있습니다.
홈페이지 하나만 빠르면 되나요?
검색 방문자는 글, 상품과 서비스 상세 페이지로도 바로 들어옵니다. 주요 템플릿과 방문이 많은 페이지를 함께 측정해야 합니다.
캐시 플러그인을 설치하면 해결되나요?
캐시는 이미 만든 페이지나 파일을 재사용해 반복 처리와 전송을 줄일 수 있습니다. 하지만 브라우저가 실행해야 할 긴 JavaScript 작업까지 없애지는 않습니다. 적용 후 실제 응답 시간과 파일 전송이 줄었는지 확인하고, 로그인이나 장바구니처럼 사용자마다 다른 화면이 잘못 공유되지 않는지도 검사합니다.
함께 알아두면 좋은 용어
- 코어 웹 바이탈: 로딩과 반응성, 화면 안정성을 측정하는 핵심 지표
- LCP: 화면에 보이는 가장 큰 콘텐츠 요소가 표시되기까지 걸리는 시간
- TTFB: 페이지 탐색 시작부터 첫 응답 바이트를 받기까지 걸리는 시간
- Lighthouse: 통제된 환경에서 페이지 품질을 검사하는 도구
- CDN: 여러 지역의 서버에 콘텐츠를 분산해 사용자에게 전달하는 네트워크