Core Web Vitals 개선 실전 — LCP 3초→1.2초 줄인 방법

핵심 요약

• LCP(Largest Contentful Paint)는 Google 검색 순위에 직접 영향을 주는 핵심 지표다.
• 이미지 최적화, 폰트 로딩 전략, 코드 스플리팅 세 가지를 순차 적용해 LCP를 3.0초에서 1.2초로 단축했다.
• CLS는 이미지·광고 영역에 명시적 크기를 지정하고 레이아웃 변화를 제거해 0.28→0.04로 낮췄다.
• 실제 프로덕션 Next.js 프로젝트 기준이며, 동일 원리를 React·Vue 프로젝트에도 적용할 수 있다.

들어가며 — 왜 Core Web Vitals인가

2021년 Google이 Page Experience 업데이트를 배포하면서 Core Web Vitals는 단순한 UX 지표를 넘어 SEO 순위 요소로 자리 잡았다. 그 이후로도 Google은 꾸준히 해당 신호의 가중치를 높이고 있으며, 2024년 기준 INP(Interaction to Next Paint)가 FID를 완전히 대체하면서 평가 항목도 진화했다.

필자가 운영하는 이커머스 프로젝트는 반년 전까지만 해도 PageSpeed Insights에서 모바일 점수 38점이라는 처참한 성적을 받고 있었다. LCP는 3.0초, CLS는 0.28, INP는 320ms — 세 지표 모두 "개선 필요" 구간이었다. 그 상태에서 어떻게 지표를 바꿨는지, 과정 전체를 기록으로 남긴다.

Core Web Vitals 세 가지를 빠르게 이해하는 방법은?

LCP — 페이지의 "첫인상" 속도

LCP는 뷰포트 안에서 가장 큰 콘텐츠 요소(대개 히어로 이미지나 H1 텍스트)가 렌더링되는 데 걸리는 시간이다. Google 기준 2.5초 이하가 Good, 4.0초를 초과하면 Poor다.

이커머스 사이트에서 히어로 배너 이미지가 LCP 대상이 되는 경우가 압도적으로 많다. 이 이미지 하나를 제때 불러오지 못하면 나머지 최적화가 모두 무의미해진다.

CLS — 레이아웃이 "펄쩍" 뛰지 않는가

CLS(Cumulative Layout Shift)는 페이지 로딩 중 요소가 예기치 않게 이동하는 정도를 측정한다. 광고 배너가 뒤늦게 삽입되거나, 크기를 지정하지 않은 이미지가 뒤늦게 로드되면 점수가 높아진다. 0.1 이하가 Good 기준이다.

INP — 사용자 입력에 얼마나 빠르게 반응하는가

INP는 클릭, 탭, 키보드 입력 등 모든 상호작용의 응답 지연을 측정한다. 2024년 3월 FID를 대체했으며, 200ms 이하가 Good 기준이다. JavaScript 번들이 무거울수록 메인 스레드가 막혀 INP가 나빠진다.

문제 진단 — 처음 측정 결과

최적화 전 지표를 정확히 기록하는 것이 출발점이다. 아래 도구를 순서대로 사용했다.

1. 1PageSpeed Insights — 필드 데이터(실제 사용자 데이터)와 랩 데이터(Lighthouse) 동시 제공
2. 2Chrome DevTools > Performance 탭 — 렌더링 타임라인과 LCP 후보 요소 확인
3. 3WebPageTest — 국내 CDN 엣지 서버 기준 실측, 필름스트립으로 시각 확인
4. 4Vercel Analytics / Sentry — 실제 유저 세션 기반 Core Web Vitals 수집

진단 결과 병목은 세 곳으로 좁혀졌다.

• 히어로 이미지 — 4.2MB JPEG, 최적화 없이 태그로 직접 삽입
• Google Fonts — @import 방식으로 3개 폰트 패밀리를 동기 로드
• 번들 크기 — 메인 청크 1.8MB, 트리 셰이킹 미적용 라이브러리 다수 포함

LCP를 3.0초에서 1.2초로 줄인 세 가지 방법은?

방법 1 — 이미지 최적화와 preload

가장 효과가 컸다. 히어로 이미지 처리 방식을 완전히 바꿨다.

Before

<img src="/banner.jpg" alt="메인 배너" />

After — Next.js Image 컴포넌트 + WebP 변환

import Image from 'next/image';

<Image
  src="/banner.webp"
  alt="메인 배너"
  width={1920}
  height={800}
  priority          // LCP 대상 이미지는 반드시 priority
  quality={80}
  sizes="(max-width: 768px) 100vw, 1920px"
/>

priority prop 하나만 붙여도 Next.js는 해당 이미지에 태그를 자동으로 삽입한다. WebP 전환 이후 파일 크기는 4.2MB에서 340KB로 약 92% 감소했다.

순수 HTML/React 프로젝트라면 안에 직접 preload 태그를 추가하면 된다.

<link
  rel="preload"
  as="image"
  href="/banner.webp"
  type="image/webp"
/>

이 작업 하나로 LCP가 3.0초 → 1.8초로 떨어졌다.

방법 2 — 폰트 로딩 전략 변경

Google Fonts를 @import로 불러오면 브라우저는 CSS를 파싱하다가 멈추고 폰트 요청을 보낸다. 이 대기 시간이 LCP를 크게 늘린다.

Before

<style>
  @import url('https://fonts.googleapis.com/css2?family=Noto+Sans+KR:wght@400;700&display=swap');
</style>

After — + display=swap + 자체 호스팅

<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link
  rel="stylesheet"
  href="https://fonts.googleapis.com/css2?family=Noto+Sans+KR:wght@400;700&display=swap"
/>

더 나아가 next/font(Next.js 13+)를 사용하면 폰트를 빌드 타임에 자체 호스팅으로 처리해 외부 요청 자체가 사라진다.

// app/layout.js
import { Noto_Sans_KR } from 'next/font/google';

const notoSansKR = Noto_Sans_KR({
  weight: ['400', '700'],
  subsets: ['latin'],
  display: 'swap',
});

폰트 개선 후 LCP 1.8초 → 1.5초.

방법 3 — 코드 스플리팅과 번들 최적화

메인 JS 번들이 크면 브라우저의 메인 스레드가 파싱·실행으로 묶인다. 이 시간 동안 LCP 요소가 화면에 그려지지 않는다.

다이나믹 임포트로 초기 번들 분리

import dynamic from 'next/dynamic';

// 스크롤 아래 위치하는 무거운 차트 컴포넌트
const SalesChart = dynamic(() => import('@/components/SalesChart'), {
  ssr: false,
  loading: () => <div className="chart-skeleton" />,
});

번들 분석으로 불필요한 라이브러리 제거

npx @next/bundle-analyzer

분석 결과 moment.js(66KB gzip)와 lodash 전체(70KB gzip)가 포함된 것을 확인했다. moment는 date-fns의 필요한 함수만 개별 임포트로 교체하고, lodash는 lodash-es의 트리 셰이킹 임포트로 전환했다.

// Before
import _ from 'lodash';
const result = _.groupBy(data, 'category');

// After
import { groupBy } from 'lodash-es';
const result = groupBy(data, 'category');

메인 번들이 1.8MB → 420KB로 줄었고, LCP는 1.5초 → 1.2초로 내려갔다.

CLS 0.28 → 0.04 낮추기

레이아웃 이동의 주범은 두 곳이었다.

1. 크기 미지정 이미지

모든 태그에 width와 height를 명시하거나, CSS로 aspect-ratio를 고정했다.

.product-image-wrapper {
  aspect-ratio: 4 / 3;
  overflow: hidden;
}

2. 뒤늦게 삽입되는 광고 배너

광고 슬롯이 로드되기 전에 동일한 높이의 플레이스홀더를 미리 잡아두었다.

<div style={{ minHeight: '90px' }}>
  <AdBanner slot="header" />
</div>

이 두 가지만으로 CLS가 0.28에서 0.04로 감소했다.

INP 개선 — 메인 스레드 부담 줄이기

INP는 번들 경량화 후 자연스럽게 320ms → 140ms로 개선되었다. 추가로 클릭 이벤트 핸들러 안에서 무거운 연산을 동기로 실행하던 부분을 requestIdleCallback으로 미뤘다.

button.addEventListener('click', () => {
  // 즉시 필요한 UI 업데이트
  setLoading(true);

  // 무거운 처리는 유휴 시간으로 연기
  requestIdleCallback(() => {
    processHeavyData(payload);
  });
});

최적화 전후 비교

FAQ

Q1. Core Web Vitals 점수가 SEO 순위에 얼마나 영향을 미치나요?

Google은 Core Web Vitals를 "tie-breaker" 신호로 설명한다. 콘텐츠 품질이 비슷한 두 페이지 중 사용자 경험이 더 좋은 쪽을 우선한다는 의미다. 절대적인 가중치는 공개되지 않았지만, 특히 경쟁이 치열한 키워드에서 차별 요소가 될 수 있다. 모바일 성능 개선 후 해당 프로젝트에서 타겟 키워드 평균 순위가 약 5~8계단 상승했다.

Q2. PageSpeed Insights와 실제 사용자 경험이 다른 이유는 무엇인가요?

PageSpeed Insights는 두 가지 데이터를 제공한다. 상단의 "Field Data"는 Chrome UX Report 기반의 실제 유저 데이터이고, 하단의 "Lab Data"는 Lighthouse가 제어된 환경에서 시뮬레이션한 결과다. 실제 성능은 네트워크 조건, 기기 사양, 캐시 상태에 따라 달라지므로 Lab 점수만 보지 말고 Field Data를 반드시 함께 확인해야 한다.

Q3. LCP 대상 요소가 무엇인지 어떻게 확인하나요?

Chrome DevTools의 Performance 탭에서 녹화 후 타임라인을 보면 LCP 마커와 해당 요소가 표시된다. 또는 PageSpeed Insights 결과 페이지에서 "LCP element" 항목을 직접 확인할 수 있다. 대부분은 히어로 이미지, 대형 텍스트 블록, 배경 이미지 중 하나다.

**Q4. Next.js를 사용하지 않아

참고: Cloudflare 개발자 문서