SEO

페이지 속도

페이지 속도(Page Speed)는 웹 페이지의 콘텐츠가 로드되어 사용자가 실제로 보고 상호작용할 수 있게 되기까지의 빠르기를 말합니다. 사용자 경험과 전환율에 직접 영향을 주며, 구글의 페이지 경험(Page Experience) 신호 중 하나인 코어 웹 바이탈로 측정됩니다.

페이지 속도는 페이지 콘텐츠가 로드되어 사용 가능해지는 빠르기로, 사용자 경험·전환·SEO에 영향을 주는 핵심 지표입니다.
구글은 코어 웹 바이탈(LCP·INP·CLS)로 속도와 사용성을 측정하며, 이는 페이지 경험 신호로 검색 순위에 반영됩니다.
좋은 기준은 LCP 2.5초 이내, INP 200ms 이하, CLS 0.1 이하이며, 실사용자 데이터(필드 데이터)의 75번째 백분위수로 판정합니다.
PageSpeed Insights, Search Console, Lighthouse, CrUX 등으로 측정하고, 서버 응답·렌더 차단 리소스·이미지 최적화로 개선합니다.

페이지 속도 개요

페이지 속도는 사용자가 페이지를 요청한 시점부터 콘텐츠가 화면에 표시되고 실제로 조작할 수 있게 되기까지 걸리는 시간을 의미합니다. 단순히 "빨리 뜨는가"를 넘어 로딩, 반응성, 시각적 안정성을 모두 포괄하는 개념으로 발전해 왔습니다. 페이지가 느리면 사용자는 콘텐츠를 보기 전에 이탈하기 쉽고, 이는 전환율 하락으로 이어집니다.

구글은 페이지 속도를 포함한 사용자 경험을 코어 웹 바이탈(Core Web Vitals)이라는 지표 묶음으로 정량화합니다. 코어 웹 바이탈은 페이지 경험(Page Experience) 신호의 일부로, 구글 검색의 핵심 순위 시스템이 보상하려는 방향과 일치한다고 공식 문서에 명시되어 있습니다. 즉 속도는 단독으로 순위를 결정하지는 않지만, 콘텐츠 품질이 비슷한 페이지 사이에서 의미 있는 변별 요소로 작동합니다.

코어 웹 바이탈 3대 지표

페이지 속도와 사용성은 세 가지 핵심 지표로 측정됩니다.

LCP(Largest Contentful Paint) — 로딩 성능. 화면에서 가장 큰 콘텐츠 요소가 렌더링되는 시점을 측정하며, 좋은 기준은 2.5초 이내입니다.
INP(Interaction to Next Paint) — 반응성. 사용자 상호작용에 화면이 반응하는 지연을 측정하며, 좋은 기준은 200밀리초 이하입니다.
CLS(Cumulative Layout Shift) — 시각적 안정성. 로딩 중 예기치 않은 레이아웃 이동의 누적량을 측정하며, 좋은 기준은 0.1 이하입니다.

지표	측정 대상	좋음 기준
LCP	로딩 성능	2.5초 이내
INP	반응성	200ms 이하
CLS	시각적 안정성	0.1 이하

판정은 실사용자 데이터의 75번째 백분위수를 기준으로 하며, 모바일과 데스크톱을 분리해 평가합니다. 즉 사용자의 75%가 좋은 경험을 받아야 해당 지표를 통과한 것으로 봅니다.

측정 도구

페이지 속도 측정은 실제 사용자에게서 수집한 필드 데이터(field data)와 통제된 환경에서 측정한 랩 데이터(lab data)로 나뉩니다. 구글은 랩 측정이 필드 측정을 대체할 수 없다고 명시합니다. 랩 데이터는 개발 단계에서 회귀를 잡는 데 유용하지만, 실제 기기·네트워크·상호작용을 반영하지 못하기 때문입니다.

PageSpeed Insights — 필드 데이터(CrUX)와 랩 데이터(Lighthouse)를 함께 제공하는 대표 진단 도구입니다.
Search Console 코어 웹 바이탈 보고서 — 실사용자 데이터 기반으로 사이트 전체 페이지의 성능 상태를 그룹별로 보여 줍니다.
CrUX(Chrome User Experience Report) — 실제 크롬 사용자에게서 수집한 필드 데이터의 원천입니다.
Lighthouse / Chrome DevTools — 랩 환경 진단 도구로, 개발 중 성능 점검과 회귀 감지에 사용합니다. 단, 랩에서는 상호작용이 없어 INP 대신 TBT(Total Blocking Time)를 대리 지표로 씁니다.

주요 최적화 항목

web.dev의 LCP 최적화 가이드에 따른 핵심 개선 항목은 다음과 같습니다.

서버 응답 시간(TTFB) 단축 — 불필요한 리다이렉트를 줄이고 초기 HTML을 가능한 한 빠르게 전달합니다.
렌더 차단 리소스 제거 — 사용하지 않는 CSS를 제거하고, 중요하지 않은 스타일은 지연 로딩하며, <head>의 동기 스크립트를 피합니다.
이미지 최적화 — WebP·AVIF 등 최신 포맷과 반응형 이미지를 사용하고 압축합니다. LCP 이미지에는 fetchpriority="high"를 적용하고 loading="lazy"는 쓰지 않습니다.
리소스 사전 로드 — 핵심 리소스에 <link rel="preload">를 적용하고, LCP 요소가 초기 HTML에서 발견되도록 합니다.
CDN과 캐싱 — 사용자와 가까운 위치에서 리소스를 제공하고, cache-control 정책으로 재방문 시 네트워크 요청을 줄입니다.

<!-- LCP 이미지 우선순위 지정 예시 -->
<img src="hero.avif" fetchpriority="high" alt="메인 이미지">

<!-- 핵심 리소스 사전 로드 -->
<link rel="preload" href="hero.avif" as="image" fetchpriority="high">

근거

구글 검색 센트럴 문서는 코어 웹 바이탈이 핵심 순위 시스템이 보상하려는 방향과 일치하므로 검색 성공을 위해 좋은 코어 웹 바이탈을 달성하라고 권장합니다. 또한 LCP 2.5초, INP 200ms, CLS 0.1이라는 좋음 기준과 75번째 백분위수 판정 방식을 명시합니다(출처: Google Search Central, web.dev). LCP 최적화의 구체적 기법은 web.dev의 LCP 최적화 가이드에 근거합니다.

실행 체크리스트

PageSpeed Insights와 Search Console 보고서로 현재 LCP·INP·CLS의 필드 데이터를 확인합니다.
모바일과 데스크톱을 분리해 75번째 백분위수 기준 통과 여부를 점검합니다.
서버 응답 시간(TTFB)을 줄이고 불필요한 리다이렉트를 제거합니다.
사용하지 않는 CSS·JS를 제거하고 비핵심 스크립트를 지연 처리합니다.
LCP 이미지에 최신 포맷·압축·fetchpriority="high"를 적용하고 lazy 로딩을 해제합니다.
핵심 리소스를 사전 로드하고 CDN·브라우저 캐싱을 구성합니다.
이미지·광고·임베드에 크기를 명시해 CLS를 줄입니다.
배포 후 Lighthouse로 회귀를 점검하고 필드 데이터로 실제 개선을 재확인합니다.

페이지 속도