페이지가 느리게 뜨고, 눌렀는데 반응이 늦고, 읽는 도중 화면이 툭툭 밀리면 사용자는 이유를 분석하지 않습니다. 그냥 불편하다고 느끼고 나갑니다.
이게 바로 Core Web Vitals가 중요한 이유입니다. 단순한 개발 지표가 아니라 SEO, 체류 경험, 전환율에 한 번에 영향을 주는 신호이기 때문입니다.
Core Web Vitals가 실제로 보는 것
Core Web Vitals는 페이지 경험을 세 가지 방향에서 봅니다.
1. LCP (Largest Contentful Paint)
사용자 화면 안에서 가장 중요한 콘텐츠가 언제 보이기 시작하는지를 측정합니다. 보통 히어로 이미지, 배너, 대표 영상, 첫 문단 같은 요소가 여기에 걸립니다.
권장 기준은 2.5초 이하입니다. 이보다 느리면 사용자는 "페이지가 아직 안 떴다"는 느낌을 받습니다.
2. INP (Interaction to Next Paint)
버튼 클릭, 메뉴 열기, 폼 입력처럼 실제 상호작용이 발생한 뒤, 화면이 얼마나 빨리 반응하는지를 봅니다.
목표는 200ms 이하입니다. 로딩은 끝났는데 사이트가 굼뜨게 느껴진다면 대개 INP 문제입니다.
3. CLS (Cumulative Layout Shift)
페이지가 로드되는 동안 요소가 예상치 않게 움직이는 정도를 측정합니다.
좋은 기준은 0.1 이하입니다. CLS가 높으면 오클릭이 늘고, 페이지 품질에 대한 신뢰도도 떨어집니다.
감으로 하지 말고 이렇게 측정하세요
최적화는 계측부터 시작해야 합니다. 어디가 문제인지 모르고 손대면 시간만 오래 걸립니다.
1. Google Search Console과 PageSpeed Insights
Search Console의 Core Web Vitals 보고서로 어떤 URL 그룹이 실제 사용자 환경에서 문제인지 먼저 확인하세요. 그다음 PageSpeed Insights로 개별 페이지를 파고들면 원인을 더 빨리 좁힐 수 있습니다.
2. Chrome Lighthouse
Lighthouse는 기술적인 가설을 세우기에 가장 빠른 도구입니다. 특히 아래 항목을 봐야 합니다.
- 어떤 요소가 LCP 후보로 잡히는지
- 메인 스레드를 길게 점유하는 스크립트가 무엇인지
- 첫 렌더링을 막는 CSS, 폰트, JS가 있는지
- 레이아웃 이동이 어느 순간 발생하는지
3. RUM(Real User Monitoring)
실험실 점수만으로는 부족합니다. 느린 모바일 네트워크, 구형 기기, 광고 스크립트, 지역별 지연 시간 같은 현실은 실제 사용자 데이터에서 더 잘 드러납니다.
SEO 관점에서 우선순위를 빠르게 잡고 싶다면 SEO Analyzer와 함께 봐도 좋습니다. 어느 페이지부터 손대야 하는지 판단이 쉬워집니다.
LCP를 낮추는 가장 현실적인 방법
LCP가 느릴 때는 보통 원인이 뻔합니다. 메인 이미지가 무겁거나, 서버 응답이 늦거나, 렌더링을 막는 리소스가 많은 경우입니다.
1. 대표 이미지를 먼저 손보세요
- 가능하면 WebP 또는 AVIF를 사용합니다.
srcset이나<picture>로 기기별 크기를 나눠 제공합니다.- 업로드 전에 압축합니다.
- LCP 후보 이미지에는
loading="lazy"를 쓰지 않습니다. width,height를 지정해 자리를 먼저 확보합니다.
1<picture> 2 <source 3 srcset="hero-1200.webp 1200w, hero-800.webp 800w, hero-400.webp 400w" 4 type="image/webp" 5 sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px" 6 > 7 <source 8 srcset="hero-1200.jpg 1200w, hero-800.jpg 800w, hero-400.jpg 400w" 9 type="image/jpeg" 10 sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px" 11 > 12 <img src="hero-800.jpg" alt="Homepage hero image" width="1200" height="800" loading="eager"> 13</picture>
2. TTFB를 줄이세요
서버가 늦게 응답하면 브라우저는 시작조차 못 합니다.
- 페이지 캐시와 데이터 캐시를 검토합니다.
- 정적 리소스는 CDN으로 분산합니다.
- 느린 쿼리와 무거운 서버 로직을 줄입니다.
- 첫 화면에 필요 없는 서버 연산은 뒤로 미룹니다.
3. 렌더링 차단 리소스를 줄이세요
초기 화면을 보여주기 전부터 너무 많은 CSS, 폰트, 스크립트를 읽으면 사용자는 페이지가 답답하다고 느낍니다.
- 크리티컬 CSS만 먼저 로드합니다.
- 중요하지 않은 스크립트는
defer를 사용합니다. - 독립 실행 가능한 외부 스크립트는
async를 검토합니다. - 초기 로딩에 꼭 필요하지 않은 라이브러리는 빼냅니다.
1<head> 2 <link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin> 3 <script src="/js/main.js" defer></script> 4 <script src="https://analytics.example.com/script.js" async></script> 5</head>
4. preload는 꼭 필요한 것만
LCP 이미지나 핵심 폰트처럼 정말 먼저 받아야 하는 리소스에는 효과적입니다. 하지만 남발하면 오히려 네트워크 경쟁만 심해집니다.
INP를 개선해 "눌렀을 때 바로 반응하는" 페이지 만들기
INP가 나쁘면 거의 항상 메인 스레드가 바쁩니다.
1. JavaScript를 줄이세요
- 큰 번들을 나눕니다.
- 나중에 써도 되는 기능은 동적 import로 미룹니다.
- 죽은 코드를 정리합니다.
- 초기에 반응할 필요가 없는 컴포넌트는 늦게 hydrate합니다.
1document.querySelector('.open-chart').addEventListener('click', async () => { 2 const { renderChart } = await import('./chart-module.js'); 3 renderChart(); 4});
2. 서드파티 스크립트를 통제하세요
채팅 위젯, 광고, 분석 도구, 지도, A/B 테스트 코드가 INP를 망치는 경우가 많습니다.
점검 포인트는 단순합니다.
- 이 스크립트가 실제 비즈니스 가치가 있는가
- 첫 상호작용 이후에 불러도 되는가
- 아예 제거해도 되는가
3. 긴 작업을 쪼개세요
한 번의 JS 작업이 너무 오래 돌면 사용자 입력이 대기 상태에 빠집니다.
- 무거운 처리 로직을 여러 단계로 나눕니다.
- 우선순위가 낮은 일은
requestIdleCallback으로 보냅니다. - 계산량이 큰 작업은 Web Worker로 옮깁니다.
CLS를 낮춰 화면이 흔들리지 않게 만들기
CLS는 큰 실수 하나보다 작은 방심이 여러 번 쌓여서 생기는 경우가 많습니다.
1. 이미지와 임베드 자리를 먼저 확보하세요
이미지, 영상, iframe이 늦게 들어오면 주변 요소가 밀립니다.
width,height를 넣습니다.- 반응형 레이아웃에는
aspect-ratio를 활용합니다. - 플레이어와 임베드는 고정된 컨테이너 안에 넣습니다.
2. 갑자기 끼어드는 요소를 줄이세요
배너, 공지, 추천 모듈, 광고 슬롯이 상단에 끼어들면 CLS가 크게 흔들립니다.
- 미리 공간을 확보합니다.
- 본문을 밀고 싶지 않다면 overlay를 사용합니다.
- 광고 영역은 최소 높이를 정합니다.
3. 웹폰트 로딩을 점검하세요
폰트도 레이아웃 이동의 원인입니다.
- 핵심 폰트를 preload합니다.
font-display: swap을 사용합니다.- 대체 폰트는 폭과 행간이 비슷한 것으로 고릅니다.
실제로는 이렇게 좋아집니다
모바일 비중이 높은 한 커머스 사이트의 초기 수치는 이랬습니다.
- LCP: 4.8초
- INP: 180ms
- CLS: 0.25
- 전환율: 1.2%
- 이탈률: 65%
적용한 작업은 비교적 명확했습니다.
- 핵심 이미지를 WebP로 교체
- 이미지와 광고 영역의 크기 예약
- 분석 및 광고 스크립트 지연 로딩
- 주요 히어로 이미지 preload
- 크리티컬 CSS 정리
- 정적 자산 CDN 적용
font-display: swap기반 폰트 로딩 조정
개선 후 결과:
- LCP: 1.9초
- INP: 65ms
- CLS: 0.08
- 전환율: 2.8%
- 이탈률: 42%
결국 성과를 만든 건 "대단한 기술"보다 우선순위였습니다.
한 번 고치고 끝내면 다시 나빠집니다
새 위젯 하나, 새 캠페인 랜딩 하나, 새 추적 코드 하나만 들어와도 Core Web Vitals는 쉽게 무너집니다.
1. 지속적으로 모니터링하세요
Search Console, RUM, 주요 페이지 템플릿을 계속 봐야 합니다.
2. 성능 예산을 정하세요
다음 항목에 상한선을 두는 편이 좋습니다.
- 전체 JavaScript 용량
- 이미지 최대 크기
- 폰트 개수
- 서드파티 스크립트 수
3. 배포 프로세스에 넣으세요
새 페이지나 리디자인은 배포 전에 LCP, INP, CLS를 한 번이라도 체크해야 합니다.
4. 팀 전체가 이해해야 합니다
이 문제는 개발만의 책임이 아닙니다. 디자인, 콘텐츠, 마케팅도 똑같이 영향을 줍니다.
핵심만 다시 정리하면
- LCP는 메인 리소스, 서버 응답, 초기 렌더링 경로를 다듬을 때 좋아집니다.
- INP는 메인 스레드 부담을 줄일 때 개선됩니다.
- CLS는 화면 공간을 미리 확보하고 예고 없는 삽입을 막을 때 떨어집니다.
- 실험실 점수보다 실제 사용자 데이터가 더 중요합니다.
- 목표는 점수표가 아니라 더 잘 읽히고 더 잘 전환되는 페이지입니다.
어디서부터 손대야 할지 먼저 정리하고 싶다면 SEO Analyzer로 우선순위를 잡고, 그다음 Lighthouse와 실제 사용자 데이터로 깊게 들어가면 됩니다.
