목차 · 9개 항목
사이트가 느리다는 말은 자주 듣지만, 어디가 어떻게 느린지 설명하기는 어렵습니다. 구글은 이를 Core Web Vitals라는 세 가지 지표로 나눠 제시합니다. 로딩, 반응성, 시각적 안정성입니다. 이 글은 세 지표의 의미와 기준값, 데이터를 읽는 방법, 그리고 현장에서 자주 만나는 원인과 해결 방법을 순서대로 정리합니다.
세 가지 지표와 기준값
| 지표 | 무엇을 보나 | 좋음 | 개선 필요 | 나쁨 |
|---|---|---|---|---|
| LCP | 화면에서 가장 큰 콘텐츠가 표시되기까지 걸린 시간 | 2.5초 이하 | 2.5초 초과 4초 이하 | 4초 초과 |
| INP | 클릭, 탭, 키 입력 후 화면이 반응하기까지의 지연 | 200ms 이하 | 200ms 초과 500ms 이하 | 500ms 초과 |
| CLS | 로딩 중 레이아웃이 예기치 않게 밀리는 정도 | 0.1 이하 | 0.1 초과 0.25 이하 | 0.25 초과 |
INP는 2024년 3월 FID를 대체해 Core Web Vitals에 들어왔습니다. FID가 첫 입력의 지연만 보았다면, INP는 페이지를 이용하는 동안 발생한 상호작용 전반의 반응성을 반영합니다.
판정은 실제 방문자 데이터의 75번째 백분위수를 기준으로 합니다. 방문자 넷 중 셋 이상이 기준 안에 들어와야 좋음으로 본다는 뜻입니다. 평균이 아니라 느린 쪽 방문자를 포함해 판단한다는 점을 기억해 두면 결과를 해석하기 쉽습니다.
현장 데이터와 실험실 데이터
속도 데이터는 출처에 따라 두 종류로 나뉩니다. 이 차이를 모르면 도구마다 결과가 달라 혼란스럽습니다.
- 현장 데이터(필드 데이터): 실제 크롬 사용자 경험을 모은 CrUX 데이터입니다. 최근 28일간의 실제 방문자 환경이 반영되며, 서치 콘솔의 Core Web Vitals 보고서와 PageSpeed Insights 상단이 이 데이터를 씁니다. 방문자가 적은 페이지는 데이터가 표시되지 않을 수 있습니다.
- 실험실 데이터(랩 데이터): Lighthouse가 정해진 기기와 네트워크 조건에서 한 번 불러와 측정한 결과입니다. 원인을 찾고 수정 효과를 바로 확인할 때 유용합니다.
INP는 실제 사용자의 상호작용이 있어야 측정되므로 실험실 데이터에는 나오지 않습니다. 실험실에서는 총 차단 시간(TBT)을 반응성의 참고 지표로 봅니다.
PageSpeed Insights와 서치 콘솔 보고서 읽는 법
PageSpeed Insights에 주소를 넣으면 위쪽에 현장 데이터, 아래쪽에 실험실 진단이 나옵니다. 현장 데이터는 해당 URL 기준과 출처(사이트 전체) 기준이 따로 있으니 어느 쪽 데이터인지 먼저 확인하십시오. 아래쪽 진단 항목에서는 LCP 요소가 무엇인지, 렌더링을 막는 리소스가 무엇인지, 레이아웃 이동을 일으킨 요소가 무엇인지 확인할 수 있습니다.
서치 콘솔의 Core Web Vitals 보고서는 모바일과 데스크톱을 나누고, 비슷한 페이지를 묶은 URL 그룹 단위로 상태를 보여 줍니다. 한 그룹의 대표 URL을 고치면 같은 템플릿을 쓰는 페이지 전체가 함께 개선되는 경우가 많습니다. 수정 후에는 보고서에서 수정 결과 확인을 시작하면 28일 동안 추적합니다. 서치 콘솔 전반은 구글 서치 콘솔 가이드에서 다뤘습니다.
LCP가 느릴 때
LCP 요소는 대개 첫 화면의 큰 이미지나 제목 문단입니다. 흔한 원인과 해결 방법은 다음과 같습니다.
- 서버 응답이 느림: 첫 바이트까지 시간이 길면 나머지가 모두 늦어집니다. 캐시, CDN, 데이터베이스 쿼리를 먼저 점검합니다.
- LCP 이미지에 지연 로딩을 걸어 둠: 첫 화면 이미지에는
loading="lazy"를 쓰지 않습니다. - 이미지를 늦게 발견함: CSS 배경이나 스크립트로 넣은 이미지는 브라우저가 늦게 찾습니다.
img태그로 넣고 우선순위를 높입니다. - 이미지 용량이 큼: WebP나 AVIF 형식, 화면 크기에 맞는
srcset을 씁니다.
<img src="/hero.avif" width="1200" height="630"
fetchpriority="high" alt="서비스 소개 이미지" />외부 도메인에서 폰트나 이미지를 가져온다면 preconnect로 연결을 미리 열어 두는 것도 도움이 됩니다. 다만 모든 도메인에 걸면 오히려 초기 연결 경쟁이 생기므로 첫 화면에 꼭 필요한 한두 곳에만 씁니다.
INP가 나쁠 때
INP는 대부분 메인 스레드를 오래 붙잡는 자바스크립트 때문에 나빠집니다.
- 사용하지 않는 스크립트와 중복 라이브러리를 제거합니다.
- 채팅 위젯, 광고, 분석 태그 같은 외부 스크립트를 정리하고 필요한 페이지에만 불러옵니다.
- 클릭 처리 안에서 무거운 계산을 하지 말고, 화면 갱신을 먼저 하고 나머지 작업은 나눠서 처리합니다.
- 한 번에 많은 요소를 다시 그리는 구조라면 목록 가상화나 렌더링 범위 축소를 검토합니다.
어떤 상호작용이 느린지 찾으려면 크롬 개발자 도구의 성능 패널에서 실제로 버튼을 눌러 보며 기록하는 방법이 가장 확실합니다. 긴 작업으로 표시되는 구간을 따라가면 어떤 스크립트가 시간을 쓰는지 확인할 수 있습니다. 현장 데이터에서 INP가 나쁜데 원인을 찾기 어렵다면 web-vitals 라이브러리로 실제 방문자의 상호작용 데이터를 수집하는 것도 방법입니다.
CLS가 높을 때와 폰트 문제
레이아웃 이동은 크기를 예약하지 않은 요소가 나중에 들어오면서 생깁니다.
- 이미지와 동영상, iframe에는
width와height또는aspect-ratio를 지정합니다. - 광고나 배너 자리는 미리 높이를 잡아 둡니다.
- 기존 콘텐츠 위에 동적으로 요소를 끼워 넣지 않습니다.
- 웹폰트가 늦게 적용되며 글자 폭이 바뀌는 문제는 핵심 폰트 미리 불러오기,
font-display설정, 대체 폰트의 크기 보정으로 줄입니다. 한글 웹폰트는 용량이 크므로 필요한 글자만 담은 서브셋 사용을 권합니다.
어디부터 고칠지 순서 정하기
문제가 여러 개 보이면 다 고치고 싶어지지만, 작업 순서를 정해야 효과를 확인하기 쉽습니다. 실무에서는 보통 다음 순서로 접근합니다.
- 템플릿 단위로 묶기: 상품 상세, 글 상세, 목록처럼 같은 템플릿을 쓰는 페이지를 묶고, 방문이 많은 템플릿부터 봅니다.
- 현장 데이터가 나쁜 지표부터: 실험실 점수가 낮아도 현장 데이터가 좋음이라면 우선순위를 낮춥니다.
- 공통 원인부터: 모든 페이지에 들어가는 외부 스크립트, 헤더 이미지, 웹폰트는 한 번 고치면 사이트 전체에 효과가 납니다.
- 한 번에 하나씩 반영: 여러 수정을 동시에 반영하면 어떤 수정이 효과가 있었는지 알기 어렵습니다.
개선 작업 체크리스트
- 서치 콘솔에서 상태가 나쁜 URL 그룹과 대표 URL을 확인했는가
- PageSpeed Insights에서 현장 데이터와 실험실 진단을 구분해 보았는가
- LCP 요소가 무엇인지 확인하고 지연 로딩을 해제했는가
- 이미지 형식과 크기를 화면에 맞게 최적화했는가
- 외부 스크립트 목록을 만들고 불필요한 것을 제거했는가
- 모든 이미지와 광고 영역에 크기를 지정했는가
- 수정 후 서치 콘솔에서 수정 결과 확인을 시작했는가
마무리
Core Web Vitals는 점수 경쟁이 아니라 실제 방문자가 겪는 불편을 줄이는 작업입니다. 페이지 경험은 여러 순위 요소 중 하나이므로 콘텐츠와 함께 균형 있게 다루는 것이 좋습니다. 우리 사이트의 속도 문제가 어디에서 생기는지 궁금하다면 무료 SEO 진단으로 먼저 확인해 보십시오.
