코어 웹 바이탈 최적화, 세 지표 병목과 개선 방법
핵심 요약 코어 웹 바이탈은 로딩(LCP)·반응(INP)·안정성(CLS)을 재는 구글의 웹 성능 지표다. 실사용자 데이터로 병목을 찾아 이미지 우선 로딩, 자바스크립트 작업 분할, 레이아웃 자리 예약으로 지표별 개선하는 방법을 정리했다.
목차
코어 웹 바이탈(Core Web Vitals)은 구글이 정한 웹페이지 사용자 경험 측정 지표로, 로딩 속도를 보는 LCP, 반응 속도를 보는 INP, 화면 안정성을 보는 CLS 세 가지로 이뤄진다. 최적화의 핵심은 세 지표를 각각 '좋음' 구간 안에 넣는 것이고, 방법은 실제 사용자 데이터로 병목을 찾은 뒤 지표별 원인을 하나씩 손보는 순서로 진행한다. 구글의 web.dev 문서 기준 2026년 7월 현재 '좋음' 구간은 LCP 2.5초 이하, INP 200밀리초 이하, CLS 0.1 이하로 안내된다. 이 글은 웹 프론트엔드 기준의 개선 실무를 다루며, 검색 순위 반영 정책의 세부는 다루지 않는다.
코어 웹 바이탈은 어떤 지표인가
세 가지 지표를 묶은 이름이다. 각각 다른 경험을 잰다. LCP는 화면에서 가장 큰 콘텐츠가 그려지는 시점을 보고, INP는 사용자 입력에 화면이 반응하는 시간을 보며, CLS는 요소가 예기치 않게 밀리는 정도를 본다.
- LCP(Largest Contentful Paint)는 대표 이미지나 큰 텍스트가 눈에 보이기까지 걸리는 시간이다. 페이지가 빨리 떴다고 느끼는 순간과 가깝다.
- INP(Interaction to Next Paint)는 클릭·탭·키 입력 뒤 다음 화면이 그려질 때까지의 지연을 잰다. 구글은 2024년에 INP가 기존 FID(First Input Delay)를 대체했다고 안내한 것으로 알려져 있다.
- CLS(Cumulative Layout Shift)는 보고 있던 요소가 뒤늦게 뜬 이미지·광고·폰트에 밀려나는 정도를 점수로 나타낸다.
구글 web.dev 문서 기준으로 2026년 7월 현재 '좋음' 구간은 LCP 2.5초 이하, INP 200밀리초 이하, CLS 0.1 이하로 안내된다. 한 번 측정한 값이 아니라 전체 방문의 하위 75퍼센트가 이 기준을 만족해야 '좋음'으로 평가된다고 한다. 느린 소수 사용자를 지표에서 숨기지 말라는 뜻이다.
지표는 어디서 측정하나
두 종류의 데이터로 본다. 하나는 필드 데이터, 하나는 랩 데이터다.
필드 데이터는 실제 사용자의 브라우저에서 모은 성능 기록이다. 기기와 네트워크와 지역이 제각각인 진짜 방문자 값이라 최종 판단 기준이 된다. 구글 서치 콘솔의 코어 웹 바이탈 보고서나 PageSpeed Insights 상단에서 확인할 수 있다고 안내된다. 랩 데이터는 통제된 환경에서 도구가 직접 측정한 값이다. Lighthouse나 크롬 개발자 도구로 원인을 재현하고 디버깅할 때 쓴다.
배포 과정이나 실사용자 모니터링에 성능 수치를 직접 심고 싶다면 구글이 배포하는 web-vitals 자바스크립트 라이브러리를 쓰는 방법이 있다. 각 지표가 확정될 때마다 콜백으로 값을 넘겨준다.
import {onLCP, onINP, onCLS} from 'web-vitals';
onLCP(console.log);
onINP(console.log);
onCLS(console.log);콘솔에 찍는 대신 콜백 안에서 수집 서버로 값을 보내면 실사용자 성능을 지표로 쌓을 수 있다.
LCP 개선: 로딩 병목 줄이기
LCP가 느리면 원인은 대개 넷 중 하나다. 서버 응답이 늦거나(TTFB), 화면을 그리기 전에 처리해야 하는 CSS·자바스크립트인 렌더 차단 리소스가 많거나, 대표 이미지 자체가 크거나, 콘텐츠를 자바스크립트로 뒤늦게 그리는 경우다.
실무에서 먼저 손대는 지점은 대표 이미지다. 화면 최상단에 뜨는 이미지에는 fetchpriority 속성으로 우선순위를 높이고, 화면 밖 이미지에는 지연 로딩을 걸어 초기 로딩 경쟁을 줄인다. 이미지는 WebP처럼 가벼운 포맷으로 바꾸고 실제 표시 크기에 맞춰 내보낸다. 서버 응답이 느리면 CDN(사용자와 가까운 서버에서 콘텐츠를 대신 전달해 거리를 줄이는 네트워크)을 앞에 두고, 화면 그리기를 막는 CSS·자바스크립트는 꼭 필요한 것만 남긴다.
<!-- 최상단 대표 이미지: 우선 로딩 -->
<img src="hero.webp" width="1200" height="675" alt="대표 이미지" fetchpriority="high">
<!-- 화면 밖 이미지: 나중에 로딩 -->
<img src="thumb.webp" width="320" height="180" alt="목록 이미지" loading="lazy">INP 개선: 상호작용 지연 줄이기
INP는 사용자가 무언가를 눌렀을 때 화면이 반응하는 속도다. 지연의 주범은 메인 스레드다. 메인 스레드는 브라우저가 화면 그리기와 자바스크립트 실행을 한 줄로 처리하는 작업 흐름인데, 여기서 오래 걸리는 작업(long task)이 돌면 그동안 사용자 입력이 밀린다.
개선은 긴 작업을 쪼개는 데서 시작한다. 한 번에 수백 밀리초씩 도는 계산은 작은 단위로 나누고, 급하지 않은 처리는 입력에 대한 반응을 먼저 그린 뒤로 미룬다. 무거운 이벤트 핸들러는 실제 필요한 일만 남기고, 스크롤이나 입력마다 붙는 핸들러는 디바운스(연이은 호출을 모아 마지막 한 번만 실행하는 기법)로 호출 횟수를 줄인다. 분석·광고 같은 서드파티 스크립트도 메인 스레드를 오래 잡으면 INP를 끌어내리므로 로딩 시점을 늦추거나 필요성을 다시 따져 본다.
CLS 개선: 레이아웃 밀림 막기
CLS는 화면이 흔들리는 정도다. 글을 읽는 중에 이미지가 뒤늦게 떠서 문단이 아래로 밀리거나, 버튼을 누르려는 순간 광고가 끼어들어 엉뚱한 곳을 누르는 경험이 그대로 점수가 된다.
핵심은 자리를 미리 잡아 두는 것이다. 이미지와 비디오에는 width·height나 aspect-ratio로 크기를 지정해, 로딩 전에도 브라우저가 들어갈 공간을 비워 두게 한다. 광고나 임베드처럼 나중에 채워질 영역은 컨테이너 높이를 먼저 정해 둔다. 웹폰트는 불러오는 동안 글자가 다시 그려지며 밀리지 않게 대체 폰트로 먼저 보여주는 방식(font-display)을 쓴다. 동적으로 추가하는 콘텐츠는 이미 보고 있는 요소 위쪽에 끼워 넣지 않는다.
개선 우선순위와 점검 주기
순서를 정할 때는 필드 데이터를 먼저 본다. 랩 점수가 아무리 좋아도 실사용자 지표가 나쁘면 그쪽이 진짜 문제다. 구글 도구의 필드 데이터는 대체로 최근 28일을 굴려 집계한다고 안내되므로, 오늘 고쳐도 지표에 완전히 반영되기까지는 시간이 걸린다. 배포하고 숫자가 바로 안 바뀐다고 되돌리기보다 며칠에서 몇 주 단위로 추이를 지켜보는 편이 낫다.
한 번에 다 잡으려 하지 말고 가장 나쁜 지표부터 하나씩 손대기를 권한다. LCP·INP·CLS는 원인이 서로 달라서, 이미지 최적화로 LCP를 줄여도 자바스크립트가 무거우면 INP는 그대로다. 측정으로 병목을 확인하고, 지표별 원인을 고치고, 다시 필드 데이터로 확인하는 흐름을 반복하는 것이 결국 가장 빠른 길이다.