코어 웹 바이탈 개선 글의 흔한 실패는 체크리스트를 위에서부터 다 하는 것이다. 지연의 원인은 사이트마다 다르고, 대부분은 한두 개의 병목이 점수 전체를 끌어내린다. 나머지 항목을 아무리 손봐도 숫자는 안 움직인다.
그래서 순서는 언제나 같다. 재고 → 병목을 찾고 → 그것만 고친다.
세 지표가 각각 무엇을 재는가
| 지표 | 재는 것 | 나쁠 때 보이는 증상 |
|---|---|---|
| LCP (Largest Contentful Paint) | 첫 화면에서 가장 큰 요소가 그려지는 시점 | 페이지가 한참 하얗다가 뒤늦게 뜬다 |
| CLS (Cumulative Layout Shift) | 화면 요소가 예고 없이 밀린 정도 | 읽으려는데 글이 아래로 밀리고, 누르려던 버튼이 도망간다 |
| INP (Interaction to Next Paint) | 클릭·입력에 화면이 반응하기까지의 시간 | 눌렀는데 아무 일도 안 일어나다가 뒤늦게 반응한다 |
셋은 서로 다른 원인에서 온다. LCP는 로딩, CLS는 레이아웃, INP는 자바스크립트 문제라고 크게 나눠두면 진단이 빨라진다.
먼저 측정한다
두 종류의 데이터가 있고, 이 차이를 모르면 헛수고를 한다.
실험실 데이터 — PageSpeed Insights나 Lighthouse가 표준 조건에서 시뮬레이션한 결과. 즉시 얻을 수 있고 원인 분석에 좋다. 하지만 실제 사용자의 환경이 아니다.
실사용자 데이터(필드 데이터) — 실제 방문자의 브라우저에서 수집된 값. 서치 콘솔의 코어 웹 바이탈 보고서와 PageSpeed Insights 상단에 나온다. 검색 순위에 영향을 주는 것은 이쪽이다.
실험실 점수 90점인데 필드 데이터가 나쁜 경우가 흔하다. 방문자의 기기가 느리거나, 네트워크가 나쁘거나, 실제로 많이 보는 페이지가 측정한 페이지와 다르기 때문이다. 필드 데이터에서 문제가 확인된 지표만 손대는 것이 원칙이다.
효과가 큰 순서대로
1. 이미지 — 대부분의 사이트에서 LCP 요소는 이미지다. 여기가 가장 크다.
- 포맷: JPEG·PNG를 WebP나 AVIF로 바꾸면 같은 화질에 용량이 크게 준다
- 크기: 화면에 400px로 표시되는 이미지를 2000px 원본으로 내보내지 않는다.
srcset으로 기기별 크기를 제공한다 - 지연 로딩: 첫 화면 아래 이미지에는
loading="lazy". 단 LCP 이미지에는 절대 걸지 않는다 — 오히려 느려진다 - 우선순위: 첫 화면의 대표 이미지에는
fetchpriority="high"를 준다
2. 폰트 — 한글 웹폰트는 영문보다 훨씬 무겁다. 체감에 직결된다.
font-display: swap으로 폰트가 로딩되는 동안 대체 글꼴로 먼저 보여준다- 실제로 쓰는 굵기만 불러온다. Regular와 Bold 둘이면 충분한 경우가 대부분이다
- 서브셋 폰트를 쓴다. 한글 전체 글자를 담은 폰트는 수 메가바이트다
- 중요한 폰트는
<link rel="preload">로 먼저 요청한다
3. 렌더 차단 리소스 — <head>의 CSS·JS가 화면 그리기를 막는다.
- 첫 화면에 필요 없는 CSS는 분리하고, 스크립트에
defer나async를 붙인다 - 외부 스크립트(광고, 채팅 위젯, 분석 도구)를 점검한다. 한 줄 붙인 스크립트가 LCP를 1초 늦추는 경우가 흔하다
4. 서버 응답 시간(TTFB) — 여기가 느리면 뒤의 모든 최적화가 무의미하다.
- CDN을 붙여 정적 파일을 가까운 곳에서 내보낸다
- 서버 쪽 캐시(페이지 캐시, DB 쿼리 캐시)를 켠다
- 느린 DB 쿼리를 찾는다. 대개 인덱스가 없는 쿼리 하나가 범인이다
CLS: 화면이 튀는 문제
원인은 거의 항상 크기를 예약하지 않은 것이다.
- 이미지·동영상에
width와height를 명시한다. 브라우저가 미리 공간을 비워둘 수 있다. CSS로 반응형 크기를 주더라도 속성은 넣어둔다 - 광고·임베드 영역에 최소 높이를 지정한다. 나중에 로딩되면서 아래 내용을 밀어내는 대표적 원인이다
- 폰트 교체로 인한 밀림: 대체 글꼴과 실제 글꼴의 크기 차이를
size-adjust등으로 맞춘다 - 동적으로 삽입되는 배너를 기존 콘텐츠 위에 끼워 넣지 않는다. 넣어야 한다면 자리를 미리 비워둔다
INP: 반응이 느린 문제
클릭했을 때 브라우저가 다른 일로 바쁘면 반응이 늦는다.
- 긴 작업을 쪼갠다. 한 번에 수백 밀리초씩 도는 자바스크립트가 있으면 그 사이 입력이 대기한다
- 이벤트 핸들러를 가볍게 한다. 무거운 계산은 결과만 먼저 보여주고 뒤에서 처리한다
- 불필요한 서드파티 스크립트를 뺀다. INP에서도 흔한 범인이다
- 스크롤·입력 이벤트에는 디바운스·스로틀을 적용한다
측정 후 유지
개선은 한 번으로 끝나지 않는다. 새 기능, 새 이미지, 새 스크립트가 들어올 때마다 되돌아간다.
- 배포 파이프라인에 Lighthouse 검사를 넣어 점수가 떨어지면 알림이 오게 한다
- 서치 콘솔의 코어 웹 바이탈 보고서를 월 1회 확인한다. 필드 데이터는 28일 단위로 집계되므로 개선 효과도 그만큼 늦게 반영된다
- 개선 작업을 할 때는 한 번에 하나씩 배포한다. 다섯 개를 한꺼번에 바꾸면 무엇이 효과를 냈는지 모른다
⚠️ 지표 구성과 임계값은 바뀔 수 있다. 이 글은 2026년 8월 기준이며, 현재 기준값은 web.dev와 서치 콘솔 문서에서 확인할 것.
Leave a Reply