구글 페이지스피드 인사이트: 코어 웹 바이탈로 보는 웹사이트 속도 최적화 가이드
ℹ️이 콘텐츠에는 광고가 포함되어,판매 발생 시 수익이 발생합니다.(네이버 쇼핑 커넥트, 아마존 어필리에이트, 애드센스 등)구글에서 만든 페이지스피드 인사이트는 웹사이트의 속도와 사용자 경험을 측정해주는 대표적인 성능 분석 도구입니다.
단순히 웹사이트 속도 측정을 위한 페이지 로딩 시간을 평가하는 것을 넘어, 코어 웹 바이탈 평가 지표를 기반으로 사이트의 전반적인 품질을 진단하고 개선 방향을 제시합니다.
코어 웹 바이탈은 실제 사용자 경험을 수치화한 3가지 핵심 지표로, 주요 콘텐츠가 화면에 표시되는 속도(LCP: 최대 콘텐츠 표시 시간), 사용자의 첫 입력에 대한 반응 속도(FID: 최초 입력 지연), 화면 요소의 시각적 안정성(CLS: 누적 레이아웃 이동)을 평가합니다.
이 페이지에서는 페이지스피드 인사이트 사용법을 단계별로 살펴보고, 실제 점수를 높이기 위한 웹사이트 속도 최적화 방법까지 함께 정리해보겠습니다.
Ⅰ. 페이지스피드 인사이트란 무엇인가?
1. PageSpeed Insights 개요와 역할
페이지스피드 인사이트(이하 PSI) 구글(Google)에서 제공하는 웹사이트 성능 분석 도구입니다. 웹페이지의 로딩 속도와 사용자 경험(UX)을 종합적으로 평가하여, 점수와 함께 구체적인 개선 가이드를 제시합니다.
이 도구는 단순한 속도 측정 도구가 아니라,
- 사용자의 실제 방문 데이터를 기반으로 한 필드 데이터(실제 사용자 경험)
- 테스트 환경에서 시뮬레이션한 랩 데이터(실험 데이터) 두 가지를 함께 분석한다는 점이 특징입니다.
이를 통해 웹사이트의 병목 구간이나 성능 저하 원인을 시각적으로 파악하고, 모바일과 데스크톱 환경에서 각각 어떤 요소가 속도를 저해하는지 구체적으로 확인할 수 있습니다.
2. Chrome Lighthouse와의 관계
페이지스피드 인사이트는 Chrome의 오픈소스 프로젝트인 Lighthouse를 기반으로 작동합니다. Lighthouse는 웹페이지의 성능, 접근성, SEO, PWA 등 다양한 항목을 점수화 하는 자동화 진단 도구입니다.
이 도구는 크롬 개발자 도구(DevTools) 안에서도 실행할 수 있지만, 기본적으로는 독립된 오픈소스 성능 분석 엔진으로, PageSpeed Insights가 그 결과를 시각적으로 보여주는 웹 기반 리포트 형태로 활용합니다.
🔸 요약하자면:
Lighthouse → 데이터를 수집하고 점수를 계산
PageSpeed Insights → 그 데이터를 시각화하여 제공
H3: 코어 웹 바이탈과의 연관성
PSI의 핵심 평가지표 중 가장 중요한 부분이 바로 코어 웹 바이탈입니다. 이는 구글이 공식적으로 사용자 경험 품질을 판단하는 기준으로 사용하는 세 가지 핵심 지표입니다.
즉, LCP(콘텐츠 표시 속도), INP(입력 반응성), CLS(시각적 안정성) 값이 좋을수록 페이지스피드 인사이트 점수 또한 높게 평가됩니다.
따라서 PSI는 단순히 속도만이 아닌, 실제 사용자 경험 전반을 측정하고 검색 순위 개선에도 직접적인 영향을 주는 도구라고 할 수 있습니다.
Ⅱ. 페이지스피드 인사이트 사용법
페이지스피드를 구글에서 검색하거나 URL 링크에서 접속한 후 도메인 주소를 입력합니다.
워드프레스로 구축한 테스트 URL로 테스트를 진행한 화면이며, Kadence Theme의 어필리에이트 블로그 템플릿을 사용했습니다.
모바일 79점, 데스크탑, 97점의 성능 점수를 확인할 수 있습니다.
Ⅲ. 지표 해석
성능 점수는 웹 페이지의 로딩 속도 및 사용자 경험을 측정합니다.
1️⃣ First Contentful Paint(FCP)는 사용자가 페이지를 열었을 때 화면에 첫 번째 콘텐츠(텍스트, 이미지, SVG 등)가 표시되기까지 걸린 시간입니다.
|
구간 |
평가 |
|---|---|
|
0 ~ 1.8초 |
✅ 좋음 |
|
1.8 ~ 3.0초 |
⚠️ 보통 |
|
3.0초 이상 |
❌ 느림 |
2️⃣ Largest Contentful Paint(LCP)은 페이지가 로드되는 동안 화면에 표시되는 가장 큰 콘텐츠 요소(주로 이미지, 동영상, 텍스트 블록 등)가 완전히 렌더링 되기까지 걸리는 시간을 측정하는 지표입니다. 즉, 사용자가 페이지의 “핵심 내용”을 볼 수 있게 되는 시점을 의미합니다.
|
구간 |
평가 |
|---|---|
|
0 ~ 2.5초 |
✅ 좋음 |
|
2.5 ~ 4.0초 |
⚠️ 개선 필요 |
|
4.0초 이상 |
❌ 느림 |
3️⃣ Total Blocking Time(TBT)은 사용자가 페이지를 실제로 상호작용할 수 있는 상태가 되기까지, 페이지 로딩 중 JavaScript 처리 때문에 차단된 총 시간을 의미합니다.
쉽게 말하면:
“페이지가 시각적으로는 로딩 중이지만, 버튼 클릭이나 스크롤 같은 사용자 입력에 반응하지 못한 시간”
예시:
- FCP 이후 JS 처리로 100ms, 200ms, 150ms의 blocking task가 발생하면
→ TBT = 100 + 200 + 150 = 450ms
구간
평가
0 ~ 200ms
✅ 좋음
200 ~ 600ms
⚠️ 보통
600ms 이상
❌ 개선 필요
TBT가 길수록, 사용자는 화면이 다 뜨더라도 버튼 클릭이나 메뉴 사용이 늦게 느껴집니다.
4️⃣ Cumulative Layout Shift(CLS)는 페이지 로딩 중 예상치 못한 레이아웃 이동이 얼마나 발생했는지를 측정하는 지표입니다. 즉, 화면에 요소가 갑자기 이동하여 사용자가 클릭하려던 버튼이나 링크가 밀리는 현상을 수치로 나타냅니다.
광고가 로딩되면서 버튼이 이동하는 경우
예: 텍스트를 읽고 있는데 이미지가 갑자기 내려오면서 글 위치가 바뀌는 경우
- Shift Score = 이동 거리 × 이동된 화면 비율
- 페이지 내 모든 layout shift를 합산 → CLS 점수
예시:
- 화면 상단 50% 영역의 이미지가 아래로 25% 이동 → 0.25 × 0.25 = 0.0625
- 페이지 내 여러 shift를 합하면 총 CLS 점수
점수
평가
0 ~ 0.1
✅ 좋음
0.1 ~ 0.25
⚠️ 개선 필요
0.25 이상
❌ 나쁨
0.1 이하가 안정적인 사용자 경험 기준입니다.
5️⃣Speed Index(SI)는 페이지 로딩 시, 사용자가 실제로 화면에서 콘텐츠를 볼 수 있게 되는 속도를 수치화 한 지표입니다.
- 단순히 HTML이나 JS가 로드된 시간을 보는 것이 아니라,
- 화면이 시각적으로 얼마나 빨리 채워졌는가를 평가합니다.
즉, “페이지가 시각적으로 완전히 로딩되기까지의 체감 속도”를 나타냅니다.
- Lighthouse 기준: 페이지 로딩 중 화면 픽셀 단위로 변화 정도를 추적
- 초기 로딩 시: 일부 콘텐츠만 나타남 → SI 점수 계산 시작
- 모든 콘텐츠가 렌더링될 때까지 시각적 변화율을 누적하여 숫자로 표시
- 단위: 밀리초(ms)
숫자가 낮을수록 화면이 빨리 채워져, 사용자 체감 속도가 좋음을 의미합니다.
구간
평가
0 ~ 3,000ms
✅ 좋음
3,000 ~ 5,000ms
⚠️ 개선 필요
5,000ms 이상
❌ 느림
실제 페이지 구조, 이미지 크기, JS 처리량 등에 따라 달라집니다.
접근성은 모든 사용자가 웹사이트를 문제없이 이용할 수 있는가를 평가하는 항목입니다. 특히 장애를 가진 사용자(시각, 청각, 운동, 인지 장애 등)가 웹사이트를 이용할 수 있는지를 기준으로 합니다.
|
항목 |
설명 |
개선 포인트 |
|---|---|---|
|
대체 텍스트(Alt text) 존재 여부 |
이미지에 alt 속성이 있는지 |
모든 이미지에 의미 있는 alt 텍스트 추가 |
|
링크 텍스트 명확성 |
“여기 클릭” 대신 링크 목적을 설명 |
SEO와 UX 향상 |
|
색상 대비 |
텍스트와 배경 색상 대비 충분한지 |
WCAG 기준 대비율 최소 4.5:1 이상 |
|
폼 레이블 |
입력 필드에 label 태그 또는 aria-label 사용 |
스크린 리더 호환성 향상 |
|
헤딩 구조 |
H1~H6 구조가 논리적으로 사용되는지 |
문서 구조화 및 스크린 리더 편의 |
|
키보드 접근성 |
키보드만으로 메뉴, 버튼, 링크 접근 가능 |
tabindex, focus 관리 |
|
ARIA 속성 사용 적절성 |
role, aria-* 속성 올바르게 사용 |
접근성 기능 보강 |
점수 평가 90~100 ✅ 우수 50~89 ⚠️ 개선 필요 0~49 ❌ 미흡
접근성 점수는 시각, 청각, 키보드 등 다양한 사용자 경험의 안전성과 편리성을 평가합니다. SEO 점수와 일부 겹치는 요소가 있어, 접근성 개선은 검색 엔진 최적화에도 긍정적인 영향을 줍니다.
권장사항은 웹사이트가 보안·호환성·코드 품질 측면에서 얼마나 올바르게 구성되어 있는지를 평가하는 항목입니다.
단순히 속도 뿐 아니라,
“사용자가 안전하고 안정적으로 웹사이트를 이용할 수 있는가?”
를 기술적으로 점검합니다.
|
항목 |
설명 |
|---|---|
|
HTTPS 사용 여부 |
모든 리소스(이미지, JS, CSS)가 HTTPS로 로드되어야 함 |
|
콘솔 에러 없음 |
브라우저 콘솔에서 JS 오류, mixed content 경고 등이 없어야 함 |
|
최신 라이브러리 사용 |
jQuery, React, Vue 등 오래된 버전 사용 시 감점 |
|
비권장 API 사용 금지 |
예: |
|
이미지 해상도 적절성 |
작은 공간에 너무 큰 이미지 파일을 불러오면 경고 |
|
사용자 데이터 보호 |
외부 스크립트나 iframe에서 개인정보 노출 위험이 없어야 함 |
|
Cross-Origin 정책 적절성 |
외부 도메인 호출 시 CORS 헤더 설정이 정상이어야 함 |
|
브라우저 호환성 |
deprecated 속성, 구식 HTML 태그 사용 시 감점 |
Lighthouse는 각 항목을 통과하면 가중치를 주어 0~100점으로 계산합니다.
점수대
평가
의미
90~100
✅ 좋음
보안과 구조 모두 우수
50~89
⚠️ 개선 필요
일부 구식 스크립트나 혼합 콘텐츠
0~49
❌ 나쁨
HTTPS 미적용, 오류 다수
검색엔진 최적화 (SEO)는 페이지의 검색 노출 가능성(크롤링, 색인, 구조적 데이터 등) 을 기술적으로 평가하는 부분입니다. 즉, 콘텐츠 품질 자체보다는 “검색 엔진이 이 페이지를 문제 없이 이해하고 색인 할 수 있는가?”를 자동 점검합니다.
점검 항목
설명
주요 개선 포인트
Document has a
<title>element제목 태그 존재 여부
모든 페이지에 고유한
<title>지정Document has a meta description
요약(meta description) 존재 여부
Rank Math 또는 Yoast SEO로 설정
Page has successful HTTP status code (200)
정상 응답 확인
404, 500 등 오류 페이지 점검
Links have descriptive text
링크 텍스트가 의미 있는지
“여기를 클릭” 대신 “WP Rocket 설정 보기” 식으로
Images have alt attributes
이미지 대체 텍스트
SEO 및 접근성 향상
Page isn’t blocked from indexing
robots.txt 또는 noindex 금지 여부
필요한 페이지만 색인 허용
Viewport meta tag
모바일 뷰포트 정의
<meta name="viewport" content="width=device-width, initial-scale=1">Document uses HTTPS
보안 연결 여부
모든 리소스 HTTPS 유지
Structured data is valid
스키마 구조화 데이터
Rank Math의 Schema 사용 권장
Ⅳ. 코어 웹 바이탈
지표 해석의 PageSpeed Insights 성능 항목에서 5가지 항목을 확인했습니다. 이 중에서 LCP와 CLS가 코어 웹 바이탈에 포함됩니다. 얼핏 봤을 성능과 코어 웹 바이탈 항목이 같은 항목으로 오해할 수 있지만 다른 점을 확인할 수 있습니다.
|
PSI 성능 지표 |
설명 |
Core Web Vitals 포함 여부 |
|---|---|---|
|
FCP (First Contentful Paint) |
첫 콘텐츠가 화면에 표시되는 시간 |
❌ (보조 지표) |
|
LCP (Largest Contentful Paint) |
주요 콘텐츠 표시 시간 |
✅ 포함 |
|
TBT (Total Blocking Time) |
사용자가 상호작용할 수 없었던 시간 |
⚙️ FID(INP) 대체 개념 |
|
CLS (Cumulative Layout Shift) |
레이아웃 안정성 |
✅ 포함 |
|
SI (Speed Index) |
화면이 시각적으로 채워지는 속도 |
❌ (보조 지표) |
1. 코어 웹 바이탈 3가지 핵심 지표
Google이 “검색 순위 평가”에 반영하는 사용자 경험 중심 지표인 코어 웹 바이탈로, 다음 3가지입니다.
|
지표 |
의미 |
기준 |
|---|---|---|
|
LCP (Largest Contentful Paint) |
주요 콘텐츠가 표시되는 속도 |
≤ 2.5초 |
|
FID → INP (First Input Delay / Interaction to Next Paint) |
사용자 입력에 대한 반응 속도 |
≤ 200ms |
|
CLS (Cumulative Layout Shift) |
화면 요소의 시각적 안정성 |
≤ 0.1 |
2024년 3월부터 Core Web Vitals의 FID를 완전히 INP로 대체했습니다.
2. 다른 주요 측정항목
즉, “다른 주요 측정항목”은 코어 웹 바이탈의 ‘보조 지표’ 성격을 가진 두 항목(FCP, TTFB)을 뜻하며, 성능 병목의 원인을 추적하거나 LCP/INP/CLS에 영향을 주는 요소를 파악할 때 사용됩니다.
|
지표 |
의미 |
기준 |
|---|---|---|
|
FCP (First Contentful Paint) |
사용자가 페이지를 열었을 때 첫 콘텐츠(텍스트, 이미지 등) 가 표시되기까지 걸린 시간 |
≤ 1.8초 |
|
TTFB (Time To First Byte) |
브라우저가 서버로부터 첫 바이트를 수신하기까지의 시간 |
≤ 0.8초 |
FCP(First Contentful Paint) 는 사용자가 페이지를 열었을 때
화면에 첫 번째 콘텐츠(텍스트, 이미지, SVG 등) 가 표시되기까지 걸린 시간을 의미합니다.
즉, 브라우저가 처음으로 “무언가를 그려주는 순간”을 측정하는 지표입니다.
🔍 참고: FCP는 코어 웹 바이탈에는 포함되지 않지만, 페이지의 초기 렌더링 속도를 진단하는 데 가장 유용한 지표입니다.
| 구간 | 평가 |
|---|---|
| 0 ~ 1.8초 | ✅ 좋음 |
| 1.8 ~ 3.0초 | ⚠️ 보통 |
| 3.0초 이상 | ❌ 느림 |
TIP:
FCP가 느리다면 CSS 또는 JavaScript가 렌더링을 차단하고 있을 가능성이 높습니다.
→ 불필요한 JS 지연 로드, Critical CSS 적용, 캐시 프리로드로 개선할 수 있습니다.
TTFB(Time To First Byte) 는 브라우저가 서버로 요청을 보낸 뒤,
첫 번째 바이트 응답을 받기까지 걸린 시간을 측정합니다.
즉, 서버가 “응답을 시작하기까지”의 속도를 보여주는 서버 성능 지표입니다.
TTFB가 느리면, 네트워크 지연이나 서버 처리 속도 자체에 문제가 있는 경우가 많습니다.
🔍 참고: TTFB는 사용자 인터페이스보다는 서버·호스팅·CDN 성능 진단용 지표로 쓰입니다.
| 구간 | 평가 |
|---|---|
| 0 ~ 0.8초 | ✅ 좋음 |
| 0.8 ~ 1.8초 | ⚠️ 보통 |
| 1.8초 이상 | ❌ 느림 |
TIP:
- 느린 TTFB는 주로 서버 응답 지연, PHP 처리 속도, 캐시 미적용, DB 부하 때문입니다.
- CDN 사용, 캐시 플러그인(WP Rocket, Cloudflare 등) 적용으로 개선할 수 있습니다.
3. Core Web Vitals 점수 개선의 중요성
Core Web Vitals는 단순한 성능 지표가 아니라, Google이 직접 검색 순위에 반영하는 공식 사용자 경험(UX) 기준입니다. 즉, 점수가 낮다는 것은 단순히 사이트가 느리다는 의미가 아니라, 사용자가 페이지를 불편하게 느낄 가능성이 높다는 뜻입니다.
3.1 검색 순위(SEO)에 직접적인 영향
- Google은 Core Web Vitals를 Page Experience(페이지 경험) 신호의 핵심으로 사용합니다.
- LCP, INP, CLS가 기준을 충족하면 “좋은 사용자 경험을 제공하는 사이트”로 평가받습니다.
- 이는 콘텐츠 품질이 동일할 경우 순위 결정의 차별 요소로 작용합니다.
3.2 이탈률 감소와 전환율 향상
- LCP가 2.5초를 넘으면 사용자 이탈률이 급격히 상승합니다.
- 반대로, 페이지 반응(INP)과 안정성(CLS)을 개선하면 체류 시간과 클릭률이 함께 증가합니다.
- 즉, Core Web Vitals 개선은 UX 개선 = 매출·전환 개선으로 이어집니다.
3.3 실제 사용자 데이터 기반 평가
- PSI의 “필드 데이터(Field Data)”는 크롬 사용자들이 실제로 경험한 데이터를 기반으로 합니다.
- 단순한 실험 수치가 아니라, 진짜 이용자의 브라우징 품질을 반영하기 때문에 Search Console의 Core Web Vitals 리포트와도 직접 연결됩니다.
Ⅴ. 웹사이트 속도 최적화 방법
PageSpeed Insights에서 낮은 점수를 보이는 경우, 코어 웹 바이탈과 성능 항목 별로 다음과 같은 개선이 우선 적용됩니다.
🔢 개선 우선순위 요약
|
우선순위 |
핵심 지표 |
주요 개선 포인트 |
|---|---|---|
|
1️⃣ |
LCP (Largest Contentful Paint) |
이미지·Hero 콘텐츠 최적화, 서버 캐싱, Lazy Load |
|
2️⃣ |
INP (Interaction to Next Paint) |
JS 최소화, 메인 스레드 블로킹 제거 |
|
3️⃣ |
CLS (Cumulative Layout Shift) |
크기 고정, 광고·이미지 로드 안정화 |
|
⚙️ 참고 |
FCP / TTFB |
초기 응답 속도, HTML·캐시 최적화 |
Ⅵ. 실제 웹사이트에 개선해야 할 사항과 통과한 감사
어떤 항목에서 개선해야 하는지와 통과한 감사를 확인할 수 있습니다.
우선 개선 항목을 확인하고 사이트에 반영 후 해결이 가능한지 확인할 수 있습니다.
웹사이트에서 통과한 항목들입니다.
해결해야 할 항목들을 중심으로 우선순위를 정하고, 사이트 구조나 리소스 로드 방식을 점진적으로 개선해 나가는 것이 중요합니다.
모든 문제를 한 번에 해결하기보다는, LCP·INP·CLS와 같이 사용자 경험에 직접적인 영향을 주는 항목부터 우선적으로 조치하는 것이 효율적입니다.
실제 사이트에 반영 후에도 문제가 바로 해결되지 않고 동일한 점수가 나오는 경우 크롬 앱의 캐시가 남아 있거나, 페이지스피드에 바로 반영되지 않는 경우가 있습니다. 이럴 경우 크롬 개발자도구의 성능 탭을 활용해서 현재 사용 중인 데스크탑을 기준으로 점수 측정을 할 수 있습니다.
또한 PageSpeed Insights의 진단 결과는 고정된 수치가 아니라 실제 사용자 환경(기기, 네트워크 상태, 페이지 업데이트 등)에 따라 변동될 수 있으므로, 정기적으로 측정하고 Search Console의 Core Web Vitals 리포트와 함께 추적하는 것이 좋습니다.
