Largest Contentful Paint(LCP)

요약 — Largest Contentful Paint(LCP)는 사용자가 페이지를 연 뒤 화면에서 가장 큰 요소, 보통 히어로 이미지나 큰 텍스트 블록이 나타나는 데 걸린 시간을 측정합니다. 2,5초 미만이면 좋음입니다. Google의 세 가지 Core Web Vitals 중 하나이며 대부분의 사이트가 가장 어려워하는 지표입니다.

LCP란?

사이트의 첫인상은 얼마나 빨리 로드된 것처럼 보이는지에서 생깁니다. LCP는 이를 수치화합니다. 스크롤하지 않고 보이는 뷰포트에서 가장 큰 단일 요소가 로드되는 시간을 측정합니다.

그 ‘가장 큰 요소’는 보통 둘 중 하나입니다.

• 히어로 배너, 제품 사진, 대표 이미지 같은 큰 이미지
• 이미지로 시작하지 않는 기사 페이지에서 흔한 큰 텍스트 블록

LCP는 페이지 로드가 처음 시작된 시점부터 해당 요소의 렌더링이 끝나는 순간까지입니다. 값이 낮을수록 페이지가 더 빠르게 느껴집니다.

점수

Google은 LCP를 세 구간으로 나눕니다.

• 좋음: 2,5초 이하
• 개선 필요: 2,5~4초
• 나쁨: 4초 초과

목표는 2,5초입니다. 한 번 실행한 테스트가 아니라 사이트를 방문한 실제 사용자로 평가하므로 실제 기기와 연결 환경에서 방문자가 겪는 경험을 반영합니다.

어려운 이유

LCP는 사람들이 가장 개선하기 어려워하는 Core Web Vital입니다. 서버가 응답하고, 브라우저가 이미지를 찾아 다운로드하고, 실제로 그려야 하는 등 움직이는 부분이 가장 많기 때문입니다. 어느 단계든 느리면 전체 값이 커집니다. 이미지 압축을 먼저 떠올리기 쉽고 때로는 도움이 되지만 실제 병목이 아닌 경우가 많습니다.

휴대전화는 연결과 처리 성능이 더 느리므로 데스크톱보다 모바일에서 어렵습니다.

먼저 할 일

흔한 실수를 바로잡는 빠른 개선 세 가지입니다.

1. 주요 이미지를 지연 로드하지 마세요. 지연 로딩은 브라우저가 이미지 가져오기를 기다리게 합니다. 페이지 아래 이미지에는 좋지만 히어로 이미지에 적용하면 화면에서 가장 중요한 요소를 일부러 늦춥니다. Evidence for this claim An LCP image should not be lazy-loaded, and reducing resource load delay is a primary LCP optimization. Scope: web.dev guidance for image-based LCP elements. Confidence: high · Verified: 2026-07-14 web.dev: Optimize LCP
2. 주요 이미지가 중요하다고 브라우저에 알리세요. 이를 위한 속성 fetchpriority="high"를 실제 LCP 후보 이미지 하나에 적용하세요. 여러 이미지에 남발하면 신호가 희석됩니다.
3. 서버를 빠르게 하세요. 서버 응답이 느리면 다른 최적화의 효과가 제한됩니다.

LCP의 네 하위 단계, LCP 요소 찾기, 렌더링·글꼴 문제와 실제 순위 영향까지 전체 사고 모델을 알고 싶다면 고급 탭으로 전환하세요.

요약 — LCP는 페이지 로드 시작 시점을 기준으로 뷰포트에 보이는 가장 큰 이미지나 텍스트 블록이 렌더링되는 시간입니다. 실제 사용자를 기기별로 나눈 일흔다섯 번째 백분위수에서 ≤ 2,5 s면 좋음, 2,5–4 s면 개선 필요, 4 s 초과면 나쁨입니다. 세 가지 Core Web Vitals 중 하나이며 TTFB, 리소스 로드 지연, 리소스 로드 시간, 요소 렌더링 지연의 네 부분으로 나뉩니다. 일반적으로 TTFB와 로드 시간이 큰 비중을 차지하지만 고정 비율이 아닌 지침이므로 자체 페이지를 진단해야 합니다. 핵심 개선은 LCP 이미지를 지연 로드하지 않고 실제 후보에 fetchpriority="high"를 추가하며, HTML에 없을 때 미리 로드하고, 렌더링 차단 CSS/JS를 없애며 TTFB를 줄이는 것입니다. 필드 지표라 실험실 도구는 근사값만 제공하고 로드 중 LCP 요소가 바뀔 수 있습니다. Google은 Core Web Vitals가 순위 시스템에 쓰인다고 확인했지만 정확한 LCP 가중치나 동점 판정 지표라고 밝히지 않았으며 콘텐츠 관련성이 여전히 우선합니다.

LCP가 실제로 측정하는 것

LCP는 사용자가 처음 페이지로 이동한 시점을 기준으로 뷰포트에 보이는 가장 큰 이미지나 텍스트 블록의 렌더링 시간을 보고합니다. Google은 이를 주요 콘텐츠가 사용자에게 나타나는 시점에 가장 가까운 표준화 대용 지표로 설명합니다. First Meaningful Paint와 Speed Index처럼 이전의 모호한 지표를 대체했습니다.

처음부터 혼동하기 쉬운 점은 다음과 같습니다.

• ‘페이지 로드 시간’이 아닙니다. 모든 리소스를 가져왔어도 가장 큰 요소의 렌더링이 차단되면 LCP가 느릴 수 있습니다. 전체 페이지가 아니라 그 요소 하나를 봅니다.
• FCP와 다릅니다. First Contentful Paint는 어떤 콘텐츠든 처음 나타날 때 기록되지만 LCP는 가장 큰 요소를 기다립니다. 내비게이션 바는 빨리 그려져 FCP가 빠르지만 히어로 이미지가 늦어 LCP는 느릴 수 있습니다.
• 동적 지표입니다. 더 큰 요소가 보일 때마다 브라우저가 새 LCP 후보를 보냅니다. 사용자 상호작용(탭·스크롤·키 입력)이나 페이지 unload 전 마지막 항목이 최종 값입니다. 상호작용은 보이는 내용을 바꾸기 때문에 그때 보고를 멈춥니다. 나중에 DOM에서 제거된 후보도 자체 항목이 지워지지는 않으며, 보고가 멈추기 전에 더 큰 요소가 렌더링되지 않으면 그대로 보고됩니다.

기준값과 2,5초인 이유

기기 유형별로 나눈 실제 사용자 페이지 로드의 일흔다섯 번째 백분위수로 평가합니다. 출처가 통과하려면 방문 네 번 중 세 번이 2,5 s 안에 들어와야 합니다.

왜 2,5일까요? Google의 기준 방법론은 대략 1–3초를 ‘즉각적’으로 느낀다는 인간 지각 연구와, 잘 최적화한 사이트가 지나치게 쉽게 달성하지 않으면서도 2,5 s는 꾸준히 달성할 수 있다는 CrUX 데이터를 근거로 했습니다. 1,5 s나 2,0 s 같은 더 엄격한 목표는 충분한 출처에서 꾸준히 달성되지 않아 채택되지 않았습니다.

LCP 요소로 인정되는 것

LCP가 고려하는 요소 유형은 다음과 같습니다.

• <img> 요소
• <svg> 안의 <image> 요소
• <video> 요소(포스터 이미지 로드 시간 또는 첫 프레임 중 더 이른 시점)
• CSS url() 함수로 불러온 배경 이미지가 있는 요소
• 텍스트 노드나 다른 인라인 텍스트 자식을 포함한 블록 수준 요소

보고되는 크기는 뷰포트에 실제로 보이는 부분입니다. 잘리거나 스크롤 밖인 부분은 제외하고, 이미지는 보이는 크기와 고유 크기 중 더 작은 값을 사용합니다. 여백·패딩·테두리는 무시합니다. opacity: 0인 요소, 뷰포트 전체를 덮어 배경으로 취급되는 요소, 정보량이 낮은 자리표시자 이미지는 경험 규칙으로 제외됩니다.

페이지 약 사분의 삼은 이미지가 LCP 요소이므로 보통 이미지 작업을 먼저 하는 것이 맞습니다. 하지만 항상 그런 것도, 항상 압축이 답인 것도 아닙니다. 나머지는 텍스트 LCP이며 이때 개선 수단은 이미지 용량이 아니라 글꼴 로딩입니다.

대부분의 문서가 건너뛰는 네 하위 단계

모든 LCP 진단을 시작할 때 사용할 구조입니다. web.dev는 LCP를 순서대로 네 부분으로 나눕니다.

1. Time to First Byte(TTFB) — 사용자가 페이지 로드를 시작한 때부터 브라우저가 HTML의 첫 바이트를 받을 때까지. 일반적인 비중: 전체 LCP의 약 40%.
2. 리소스 로드 지연 — TTFB부터 브라우저가 LCP 리소스 로드를 시작할 때까지의 간격, 즉 발견 시간. 일반적인 비중: 10% 미만.
3. 리소스 로드 시간 — LCP 리소스 자체를 다운로드하는 시간. 일반적인 비중: 약 40%.
4. 요소 렌더링 지연 — 리소스 로드가 끝난 뒤 요소가 실제로 그려질 때까지. 일반적인 비중: 10% 미만.

표의 원칙은 LCP 시간 대부분이 HTML 문서와 LCP 리소스를 로드하는 데 쓰여야 한다는 것입니다. 둘 중 어느 것도 로드하지 않는 구간은 개선 기회입니다.

web.dev는 이 비율이 엄격한 규칙이 아니라 지침이라고 명시합니다. 절대 초 목표로 바꾸거나 모든 페이지를 같은 비율에 맞추지 마세요. 서로 비교할 때만 의미가 있고 LCP가 꾸준히 2,5초 안이라면 상대 비율 자체는 중요하지 않습니다. 정확한 40/10/40/10을 좇지 말고 자체 페이지에서 과도한 비중을 차지하는 하위 단계를 찾아 고치세요.

흔한 가정을 뒤집는 사실도 있습니다. 2025년 2월부터 이미지 LCP의 네 하위 단계를 CrUX API에서 제공하며, Chrome 팀의 HTTP Archive 분석에서는 이미지 다운로드 시간이 LCP에서 가장 작은 부분인 경우가 많았습니다. 즉 ‘이미지만 압축’하면 자주 잘못된 하위 단계를 고칩니다. TTFB와 발견 지연이 더 큰 개선 수단인 경우가 많습니다.

LCP 요소 찾기

최적화 전에 어떤 요소가 LCP이며 어떤 하위 단계가 병목인지 확인하세요.

• PageSpeed Insights — 진단 섹션에서 LCP 요소를 표시하고 필드 데이터 탭에서 실제 사용자 점수를 보여 줍니다.
• Chrome DevTools — Performance 패널의 타임라인에서 LCP 노드를 표시합니다.
• web-vitals JS 라이브러리 — 자체 실사용자 모니터링에서 LCP와 요소를 기록합니다.

LCP 개선 방법

각 개선을 대상 하위 단계에 연결하세요.

리소스 로드 지연(발견) 개선. 효과가 가장 크고 가장 자주 잘못되는 부분입니다.

• LCP 이미지를 절대 지연 로드하지 마세요. LCP 요소에 loading="lazy"를 쓰면 항상 불필요한 로드 지연이 생깁니다. 지연 로딩은 첫 화면 아래 이미지에만 사용하세요.
• 예상 LCP 이미지에 **fetchpriority="high"**를 추가해 브라우저가 높은 우선순위로 일찍 가져오게 합니다.
• 이미지가 CSS나 JavaScript로 로드돼 초기 HTML에서 발견되지 않으면 <link rel="preload">로 미리 로드하세요. JS로 히어로 이미지를 불러오면 브라우저의 preload 스캐너에서 URL을 숨기므로 안티패턴입니다.
• 중요한 리소스를 동일 출처에 호스팅해 추가 연결 설정 비용을 피하세요.

preload와 fetchpriority는 서로 다른 문제를 해결하므로 습관적으로 둘 다 쓰지 마세요. preload는 JS·CSS 로드 이미지처럼 브라우저의 preload 스캐너가 늦게 발견할 리소스를 노출합니다. fetchpriority는 이미 찾은 리소스의 가져오기 우선순위를 바꿉니다. 초기 HTML의 일반 <img>처럼 발견과 우선순위가 이미 맞다면 둘을 추가해도 별 효과 없이 요청만 늘 수 있습니다. 트레이스를 보고 실제 문제에 맞는 하나를 적용한 뒤 필드 수치가 움직였는지 확인하세요.

요소 렌더링 지연 개선.

• 렌더링 차단 CSS를 줄이거나 인라인으로 넣고 중요하지 않은 스타일은 지연합니다.
• <head>의 동기 스크립트를 피합니다.
• 마크업이 바로 그릴 수 있는 상태로 오도록 서버 측 렌더링이나 정적 생성을 우선하고 메인 스레드의 긴 작업을 나눕니다.

리소스 로드 시간 단축.

• 현대적 이미지 형식(WebP, AVIF), 합리적인 압축, CDN을 사용합니다.
• 효율적인 Cache-Control을 설정합니다. 네트워크 경합도 놓치지 마세요. 첫 화면 아래의 다른 이미지를 지연 로드하면 대역폭을 확보해 LCP 이미지가 더 빨리 도착할 수 있습니다.

TTFB 단축.

• 리디렉션을 줄이고 불필요한 고유 URL 매개변수를 없애며 서버 응답 시간을 최적화합니다. LCP에는 이전 페이지의 unload 시간, 연결 설정, 리디렉션 시간도 모두 TTFB로 포함됩니다.

특수 사례: 텍스트 기반 LCP. 가장 큰 요소가 텍스트면 핵심 경로는 이미지 용량이 아니라 글꼴 로딩입니다. font-display: optional이나 시스템 글꼴은 글꼴로 인한 렌더링 지연을 없앱니다. 글꼴 파일을 미리 로드하지 않은 font-display: swap은 오히려 지연을 만들 수 있습니다.

실험실과 필드의 차이가 중요한 이유

LCP는 근본적으로 필드 지표입니다. Google은 CrUX의 실제 사용자 데이터로 평가하고 PageSpeed Insights 필드 탭과 Search Console Core Web Vitals 보고서에 표시합니다. 순위에 입력되는 것도 이 필드 데이터입니다.

Lighthouse, Chrome DevTools, WebPageTest 같은 실험실 도구는 시뮬레이션 조건에서 근사할 뿐이고 점수 기준도 같지 않습니다. Lighthouse 데스크톱은 필드 기준(≤ 2,5 s)보다 엄격한 좋음 기준(≤ 1,2 s)을 사용합니다. 따라서 Lighthouse 통과가 CrUX 통과를 보장하지 않고 반대도 마찬가지입니다. 실험실 도구는 디버깅과 재현에 쓰고 실제 판정은 필드 데이터를 신뢰하세요.

실험실과 필드가 달라지는 두 번째 이유도 알아두면 이상한 값 때문에 존재하지 않는 버그를 쫓지 않을 수 있습니다. 현재 LargestContentfulPaint 브라우저 API는 여전히 W3C Working Draft이며 단일 문서 로드 범위입니다. bfcache 복원이나 동일 문서 SPA 탐색에서 자체 초기화되지 않습니다. 백그라운드 탭이나 사전 렌더링 페이지처럼 화면 밖에서 시작한 페이지는 실제로 보인 때가 아니라 로드부터 시간을 재 값이 부풀 수 있습니다. 조건을 충족하는 사용자 입력이 있으면 보고 알고리즘도 멈추므로 주요 콘텐츠가 표시되기 전에 상호작용하면 LCP가 이를 포착하지 못합니다. 기준표가 바뀌는 것은 아니며 단순한 첫 로드가 아닌 세션의 값이 이상해 보이는 이유를 설명합니다.

LCP가 순위에 영향을 주나요?

Google이 Core Web Vitals를 순위 시스템에 사용하고 좋은 점수를 권장한다는 의미에서는 그렇습니다. 하지만 현재 Search Central 문서는 정확한 LCP 가중치를 공개하지 않고 동점 판정 지표라고도 설명하지 않습니다. Google은 관련성 있는 콘텐츠를 제공하는 페이지가 여러 개일 때 페이지 경험이 “can contribute to success in Search” (번역) 「검색 성공에 기여할 수 있다」고 하며, 좋은 점수가 순위 상승을 보장하지 않는다고 설명합니다. 콘텐츠 관련성과 품질이 여전히 우선입니다. LCP는 문서화되지 않은 순위 동점 판정 때문이 아니라 사용자가 실제로 더 빠르게 느끼고 전환에도 좋은 페이지를 만들기 위해 최적화하세요.

데이터에서 확인되는 현실도 있습니다. Core Web Vitals 중 사이트가 가장 개선하기 어려워하는 지표가 LCP이며, CPU와 연결이 느린 모바일은 데스크톱보다 훨씬 어렵습니다. 3G 이하에서는 2,5 s 기준을 달성하기가 거의 불가능하게 느껴질 수 있습니다.

관련 지표

LCP는 Interaction to Next Paint, Cumulative Layout Shift와 함께 세 가지 Core Web Vitals를 구성합니다. 첫 하위 단계인 Time to First Byte는 별도의 진단 지표이고 First Contentful Paint는 로딩 타임라인에서 바로 옆에 있습니다. PageSpeed Insights, Lighthouse, Chrome User Experience Report(CrUX)에서 모두 볼 수 있으며 이 클러스터에서 각 지표를 자세히 다룹니다.

AI 요약

고급 버전을 압축하면 다음과 같습니다.

• LCP는 페이지 로드 시작을 기준으로 가장 큰 보이는 이미지나 텍스트 블록이 렌더링되는 시간이며 ‘주요 콘텐츠가 언제 나타나는가’에 가장 가까운 표준화 대용 지표입니다.
• 기준: 실제 사용자를 기기별로 나눈 일흔다섯 번째 백분위수에서 좋음 ≤ 2,5 s, 개선 필요 2,5–4 s, 나쁨 > 4 s입니다. 세 가지 Core Web Vitals 중 하나입니다.
• 페이지 로드 시간도 FCP도 아닙니다. FCP는 어떤 콘텐츠든 첫 픽셀, LCP는 가장 큰 요소입니다. LCP는 동적이어서 로드 중 가장 큰 후보가 바뀔 수 있고 사용자 상호작용 전 마지막 후보가 최종 값입니다.
• LCP 요소: <img>, <svg> 안의 <image>, <video> 포스터, CSS background-image: url(), 블록 수준 텍스트 요소입니다. 약 4개 중 3개 페이지는 이미지 LCP이고 나머지는 텍스트라 이미지 용량이 아닌 글꼴이 개선 수단입니다.
• 네 하위 단계: TTFB(약 40%), 리소스 로드 지연(<10%), 리소스 로드 시간(약 40%), 요소 렌더링 지연(<10%). web.dev는 고정 비율이 아닌 지침이라고 하므로 정확한 비율을 좇지 말고 페이지별로 진단하세요. CrUX 2025 데이터에서는 이미지 다운로드가 가장 작은 부분인 경우가 많아 이미지 압축만으로는 잘못된 문제를 고칠 수 있습니다.
• 핵심 개선: LCP 이미지를 지연 로드하지 말고 실제 후보에 fetchpriority="high"를 추가하며 HTML에 없을 때 미리 로드하세요. preload와 fetchpriority는 다른 문제를 해결하므로 습관적으로 둘 다 쓰지 마세요. 렌더링 차단 CSS/JS와 TTFB도 줄입니다.
• 필드이지 실험실이 아닙니다. CrUX/Search Console 데이터가 순위에 쓰이고 Lighthouse는 더 엄격한 데스크톱 기준(≤ 1,2 s)으로 근사할 뿐입니다. 현재 LargestContentfulPaint API는 문서 로드 범위이며 bfcache 복원이나 동일 문서 SPA 탐색에서 자체 초기화되지 않습니다.
• 순위: Google은 CWV가 순위 시스템에 쓰인다고 확인했지만 정확한 LCP 가중치나 동점 판정 지표라고 밝히지 않았습니다. 콘텐츠 관련성이 여전히 우선하며 개선하기 가장 어렵고 모바일에서 더 어렵습니다.

공식 문서

Google Chrome·검색 팀의 1차 출처 안내입니다.

web.dev(Chrome 팀)

• Largest Contentful Paint(LCP) — LCP 요소, 크기 계산, 보고 중단 시점, 측정 API를 설명하는 공식 정의
• Largest Contentful Paint 최적화 — 네 하위 단계 구조와 전체 최적화 방법
• Core Web Vitals — 세 가지 Core Web Vitals에서 LCP의 위치
• Core Web Vitals 지표 기준 정의 방법 — 2,5 s 기준의 연구와 달성 가능성 데이터

Chrome for Developers

• CrUX에서 LCP 이미지 하위 단계와 RTT 제공 — 2025년 2월 네 하위 단계의 필드 데이터 공개(이미지 LCP만)
• Largest Contentful Paint | Lighthouse — 실험실 지표와 기기별 점수

Google Search Central

• Core Web Vitals와 Google 검색 결과 이해 — Core Web Vitals가 검색에 반영되는 방식

출처 인용

Google 문서와 팀의 공식 발언입니다. 각 링크는 인용된 구절로 바로 이동합니다.

web.dev — 정의와 동작 (Google Philip Walton과 Barry Pollard)

• “LCP reports the render time of the largest image, text block, or video visible in the viewport, measured relative to when the user first navigated to the page.” (번역) 「LCP는 사용자가 처음 페이지로 이동한 시점을 기준으로 뷰포트에 보이는 가장 큰 이미지·텍스트 블록·동영상의 렌더링 시간을 보고합니다.」 인용으로 이동
• 측정 대상에 관해 “LCP doesn’t consider margins, paddings, or borders applied using CSS.” (번역) 「LCP는 CSS로 적용한 여백·패딩·테두리를 고려하지 않습니다.」 인용으로 이동
• 보고 중단 시점에 관해 “The browser will stop reporting new entries as soon as the user interacts with the page (via a tap, scroll, or keypress), as user interaction often changes what’s visible to the user.” (번역) 「사용자 상호작용은 보이는 내용을 바꾸는 경우가 많으므로 탭·스크롤·키 입력으로 페이지와 상호작용하는 즉시 브라우저가 새 항목 보고를 멈춥니다.」 인용으로 이동
• 타이밍 포함 범위에 관해 “It is important to note that LCP includes any unload time from the previous page, connection set up time, redirect time, and other Time To First Byte (TTFB) delays.” (번역) 「LCP에는 이전 페이지의 unload 시간, 연결 설정 시간, 리디렉션 시간과 기타 TTFB 지연이 포함됩니다.」 인용으로 이동

web.dev — 최적화 (Google Philip Walton과 Barry Pollard)

• 가장 중요한 지연 로딩 규칙: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay.” (번역) 「LCP 이미지를 절대 지연 로드하지 마세요. 항상 불필요한 리소스 로드 지연을 일으킵니다.」 인용으로 이동
• 하위 단계 목표의 원칙: “The vast majority of the LCP time should be spent loading the HTML document and LCP source.” (번역) 「LCP 시간의 대부분은 HTML 문서와 LCP 소스를 로드하는 데 쓰여야 합니다.」 인용으로 이동

Google Search Central — 순위

• “We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally.” (번역) 「검색 성공과 전반적으로 우수한 사용자 경험을 위해 사이트 소유자가 좋은 Core Web Vitals를 달성할 것을 강력히 권장합니다.」 Search Central Core Web Vitals 문서에서 전달된 문구이므로 최종 인용으로 쓰기 전에 현재 페이지에서 확인하세요.

LCP 개선 체크리스트

발견과 TTFB가 대개 가장 크고 자주 망가지는 개선 수단이므로 위에서 아래 순서로 진행하세요.

• PageSpeed Insights 진단, DevTools Performance 패널 또는 web-vitals 라이브러리로 실제 LCP 요소를 찾았습니다. 추측으로 최적화하지 않습니다.
• 변경 전에 네 하위 단계 중 병목이 어디인지 확인했습니다.
• LCP 이미지에 loading="lazy"가 없습니다. 지연 로딩은 첫 화면 아래에서만 씁니다.
• LCP 이미지에 **fetchpriority="high"**가 있습니다.
• LCP 이미지를 초기 HTML에서 발견할 수 있으며 CSS/JS로 로드한다면 <link rel="preload">로 미리 로드했습니다.
• 히어로 이미지를 JavaScript로 로드해 preload 스캐너에서 숨기지 않습니다.
• 렌더링 차단 CSS를 최소화·인라인 처리하고 중요하지 않은 스타일을 지연했습니다.
• <head>에 동기 스크립트가 없고 긴 작업을 나눴습니다.
• 현대적 이미지 형식(WebP/AVIF), 합리적 압축, CDN, 효율적 Cache-Control을 사용합니다.
• 첫 화면 아래 이미지를 지연 로드해 LCP 이미지와 대역폭을 다투지 않습니다.
• 리디렉션을 줄이고 서버 응답을 최적화하며 불필요한 URL 매개변수를 없애 TTFB를 개선했습니다.
• 텍스트 LCP라면 font-display: optional 또는 시스템 글꼴을 쓰고 바뀌는 글꼴 파일을 미리 로드합니다.
• Lighthouse 실험실 실행만이 아니라 필드 데이터(CrUX / Search Console)로 확인했습니다.

LCP 요약표

기준값(기기별 실제 사용자 일흔다섯 번째 백분위수)

네 하위 단계와 해결책

LCP 요소가 될 수 있는 것

• <img> · <svg> 안의 <image> · <video> 포스터 · CSS background-image: url() · 블록 수준 텍스트

경험 규칙으로 제외: opacity: 0, 전체 뷰포트 ‘배경’ 요소, 정보량이 낮은 자리표시자

빠른 사실

• LCP는 필드 지표이며 CrUX / Search Console 데이터가 순위에 쓰입니다. Lighthouse는 근사값만 제공하고 데스크톱에서 더 엄격한 좋음 기준 ≤ 1,2 s를 사용합니다.
• 로드 중 LCP 요소가 바뀔 수 있으며 사용자 상호작용 전 마지막 후보가 최종 값입니다.
• 페이지 약 4개 중 3개는 이미지 LCP이고 나머지는 텍스트라 글꼴이 개선 수단입니다.
• 이미지 다운로드 시간이 가장 작은 하위 단계인 경우가 많아 압축이 항상 답은 아닙니다.
• LCP ≠ FCP이며 LCP ≠ 전체 페이지 로드 시간입니다.

LCP 측정·개선 도구

필드 데이터(순위에 쓰이는 값)

• PageSpeed Insights — 필드 탭에서 실제 사용자 CrUX LCP를 보여 주고 진단에서 LCP 요소를 표시합니다.
• Search Console Core Web Vitals 보고서 — 실제 사용자 데이터에서 URL을 묶어 LCP 상태를 보여 줍니다.
• Chrome User Experience Report(CrUX) — 기반 필드 데이터세트로 2025년 2월부터 API에서 이미지 LCP의 네 하위 단계를 제공합니다.
• web-vitals JS 라이브러리 — 자체 실사용자 모니터링에서 LCP와 LCP 요소를 기록합니다.

실험실 데이터(디버깅용)

• Lighthouse — 빠른 실험실 LCP와 개선 목록을 제공합니다. 데스크톱 기준이 필드보다 엄격함을 기억하세요.
• Chrome DevTools Performance 패널 — LCP 노드와 전체 렌더링 타임라인을 표시합니다.
• WebPageTest — 느린 하위 단계를 찾는 폭포수 보기

SEO 크롤러

• Ahrefs Site Audit — 사이트 전체의 Core Web Vitals / 성능 문제를 대규모로 찾습니다.

도구 자체의 점수

이 페이지의 지표를 실제로 보여 주는 예시입니다. 잘 알려진 페이지 속도·모니터링 서비스의 실제 사용자 모바일 LCP(Chrome UX Report 필드 데이터)를 비교합니다.

잘못된 문제를 겨냥하는 LCP 개선

히어로 이미지 지연 로딩

loading="lazy"는 LCP가 될 가능성이 높은 첫 화면 이미지의 발견을 늦춥니다. 즉시 로드하고 예상 후보에 fetchpriority="high"를 주며 지연 로딩은 첫 화면 아래 이미지에만 사용하세요.

병목을 찾기 전에 모든 이미지 압축

이미지 다운로드 시간은 LCP 네 하위 단계 중 하나이며 가장 작을 수 있습니다. 해결책을 고르기 전에 LCP 요소를 찾고 TTFB, 로드 지연, 로드 시간, 렌더링 지연을 확인하세요.

JavaScript로 히어로 이미지 로드

JS 삽입 이미지는 브라우저 preload 스캐너에서 URL을 숨겨 리소스 로드 지연을 만듭니다. 이미지를 초기 HTML에 넣거나 CSS·JS가 담당해야 한다면 미리 로드하세요.

Lighthouse 한 번으로 성공 선언

Lighthouse는 통제된 진단이고 Google의 CWV 판정은 CrUX 필드 데이터에서 나옵니다. 실험실 실행으로 작동 원리를 확인하고 실제 사용자 데이터에서 p75 결과가 개선됐는지 기다려 확인하세요.

LCP 리소스가 늦게 시작됨

증상: TTFB와 LCP 리소스 요청 사이에 긴 간격이 있습니다. 가능한 원인: 지연 로딩, JS 발견, CSS 배경 이미지, 낮은 가져오기 우선순위. 해결: 초기 HTML에서 리소스를 발견할 수 있게 하고 지연 로딩을 제거하며 fetchpriority="high"를 적용하거나 미리 로드합니다. 트레이스에서 요청 시점이 앞당겨졌는지 확인하세요.

리소스는 로드됐지만 LCP가 늦게 발생함

증상: 로드 시간이 끝난 한참 뒤 LCP 이벤트가 발생합니다. 가능한 원인: 렌더링 차단 CSS, 동기 JavaScript, 긴 작업, 텍스트 LCP의 글꼴 렌더링. 해결: 차단 작업을 줄이고 텍스트의 글꼴 전략을 테스트하며 요소 렌더링 지연이 줄었는지 확인하세요.

실험실 LCP는 좋지만 필드 LCP는 나쁨

증상: Lighthouse는 통과하지만 CrUX나 Search Console은 실패합니다. 가능한 원인: 실제 사용자의 기기·네트워크·캐시 상태·지역·LCP 요소가 다릅니다. 해결: 필드 데이터를 세분화하고 RUM에서 요소·하위 단계 세부 정보를 수집하며 기본 실험실 프로필만 조정하지 말고 느린 구간을 재현하세요.

실행마다 보고되는 LCP 요소가 달라짐

증상: DevTools가 서로 다른 이미지나 텍스트 블록을 식별합니다. 가능한 원인: 반응형 중단점, 개인화, 늦은 DOM 변경, 경쟁 후보. 해결: 대표 뷰포트와 상태를 테스트하고 데스크톱 히어로 하나가 모든 사용자를 대표한다고 가정하지 말고 반복되는 각 후보를 최적화하세요.

히어로 이미지 발견: 지연과 조기 방식

단순화한 지연 구현은 JavaScript 뒤에 이미지를 숨깁니다.

<div id="hero"></div>
<script>
  document.querySelector('#hero').innerHTML = '<img src="hero.webp" alt="">';
</script>

다음 버전은 브라우저가 HTML을 파싱하면서 발견하고 우선 처리할 수 있습니다.

<img src="hero.webp" alt="" fetchpriority="high" width="1200" height="675">

CSS 배경 이미지: 비공개와 preload 방식

LCP 이미지가 CSS 배경이어야 한다면 스타일시트 처리가 끝나기 전에 공개하세요.

<link rel="preload" as="image" href="hero.webp" fetchpriority="high">

preload는 URL과 요청 속성이 실제 리소스와 일치할 때만 도움이 됩니다.

Chrome DevTools에서 최근 LCP 후보 나열

Chrome DevTools Console에 붙여 넣고 페이지를 다시 로드해 브라우저가 보고하는 후보를 관찰하세요. 상호작용 전 마지막 후보가 관련 값입니다.

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.table({
      lcp: Math.round(entry.startTime),
      element: entry.element?.tagName,
      url: entry.url || '',
      size: entry.size,
    });
  }
}).observe({ type: 'largest-contentful-paint', buffered: true });

첫 화면의 지연 로드 이미지 후보 찾기

DevTools Console에서 실행하세요. 위쪽 가장자리가 현재 뷰포트 안에서 시작하는 지연 이미지를 나열합니다. 속성을 제거하기 전에 실제 LCP 후보인지 확인하세요.

[...document.querySelectorAll('img[loading="lazy"]')]
  .filter((img) => img.getBoundingClientRect().top < innerHeight)
  .map((img) => ({ src: img.currentSrc || img.src, top: img.getBoundingClientRect().top }));

크롤러에서 이미지 우선순위 속성 추출

Screaming Frog 맞춤 추출에서 이 XPath를 사용하면 높은 우선순위로 표시된 이미지를 반환합니다.

//img[@fetchpriority='high']/@src

LCP 개선이 적용됐는지 입증하기

발견 순서 테스트

실행할 테스트: 히어로 이미지 변경 뒤 DevTools Performance 트레이스를 기록합니다. 예상 결과: LCP 요청이 더 일찍 시작되고 지연 로드되지 않습니다. 실패 해석: 리소스가 여전히 숨겨졌거나 우선순위가 낮거나 다른 의존성 뒤에서 차단됩니다. 모니터링 기간: 실험실에서 즉시 확인합니다. 롤백 조건: 변경이 다른 중요 리소스를 늦추거나 실험실 LCP를 지속적으로 악화시킵니다.

렌더링 지연 테스트

실행할 테스트: 동등한 변경 전후 트레이스에서 LCP 리소스 완료 시점과 LCP 이벤트를 비교합니다. 예상 결과: 새 레이아웃·시각 회귀 없이 요소 렌더링 지연이 줄어듭니다. 실패 해석: CSS, JavaScript, 글꼴이 여전히 페인트를 막습니다. 모니터링 기간: 대표 뷰포트에서 즉시 확인합니다. 롤백 조건: 렌더링이 깨지거나 스타일이 누락되거나 반복 LCP가 더 나빠집니다.

필드 결과 테스트

실행할 테스트: 배포 뒤 URL 수준 CrUX 또는 퍼스트파티 RUM p75 LCP를 모니터링합니다. 예상 결과: INP나 CLS를 악화시키지 않으면서 p75가 좋음 기준에 가까워지거나 그 안에 머뭅니다. 실패 해석: 실험실 사례가 대표적이지 않았거나 실제 방문에서는 다른 하위 단계가 지배합니다. 모니터링 기간: RUM은 먼저 확인할 수 있고 CrUX는 28일 이동 창이 교체돼야 합니다. 롤백 조건: 출시에 연결된 지속적인 필드 악화가 발생합니다.

추적할 가치가 있는 LCP 지표

필드 p75 LCP

지표: 폼 팩터별 일흔다섯 번째 백분위수 LCP. 알 수 있는 것: 실제 사용자가 Core Web Vitals 로딩 기준을 충족하는지 보여 줍니다. 수집 방법: CrUX, Search Console 또는 퍼스트파티 RUM. 벤치마크 / 현실적 범위: 2,5초 이하는 좋음이며 모바일과 데스크톱을 분리합니다. 주기: CrUX 이동 창을 기록하며 매주 확인합니다.

LCP 하위 단계 분포

지표: LCP의 TTFB, 리소스 로드 지연, 로드 시간, 요소 렌더링 지연. 알 수 있는 것: 어느 단계가 대기를 차지하는지 밝힙니다. 수집 방법: 대표 실험실 트레이스와 가능한 경우 CrUX/RUM의 이미지 LCP 하위 단계. 벤치마크 / 현실적 범위: 이 문서의 대략적인 40/10/40/10 진단 비율을 보편적 성능 보장이 아닌 지침으로 사용합니다. 주기: 템플릿 출시 뒤와 우선 템플릿은 매월 확인합니다.

좋음 LCP URL 범위

지표: 필드 LCP가 좋음인 중요 URL 그룹. 알 수 있는 것: 개선이 샘플 페이지에 한정되지 않고 넓게 적용됐는지 보여 줍니다. 수집 방법: Search Console CWV 그룹과 우선 페이지의 URL 수준 CrUX. 벤치마크 / 현실적 범위: 템플릿별 기준선을 정하며 트래픽이 적은 URL에는 개별 필드 데이터가 없을 수 있습니다. 주기: 매주 확인합니다.

퀴즈: Largest Contentful Paint

LCP 측정과 진단에 관한 짧은 문제 다섯 개입니다. 답을 고른 뒤 확인하세요.

볼 만한 자료

관련 글

• Largest Contentful Paint(LCP)란 무엇이며 어떻게 개선하나 — Ahrefs 블로그의 전체 LCP 안내
• Core Web Vitals(CWV)란 무엇이며 어떻게 개선하나 — LCP와 INP·CLS의 관계 및 개선이 가장 어려운 이유
• 기술 SEO 초보자 가이드 — 전체 기술 SEO에서 페이지 성능의 위치

공식 자료(Google / Chrome)

• Largest Contentful Paint(LCP)와 LCP 최적화 — 공식 정의와 개선 안내
• CWV 기준 정의 방법 — 2,5 s의 근거

기타 자료

• 이미지 로딩을 최적화해 웹사이트 Largest Contentful Paint 개선 — 대역폭 경합과 JS 이미지 안티패턴에 강한 MDN 개발자 관점
• 성능 — 2025 Web Almanac — fetchpriority 채택, preload 사용, 이미지·텍스트 LCP 비율, 기기별 통과율의 출처인 HTTP Archive 연례 심층 분석
• Largest Contentful Paint(LCP) — 하위 단계 폭포수 분석, 프로그레시브 JPEG 주의점, iframe·소프트 탐색 예외를 다룬 DebugBear 문서
• Largest Contentful Paint(LCP): 정의, 측정과 최적화 — corewebvitals.io의 실제 RUM 벤치마크, Vodafone Italy 비즈니스 사례, Google Flights fetchpriority 결과
• Largest Contentful Paint | MDN Web Docs — LargestContentfulPaint API, 요소 유형, 브라우저 호환성 참고

인용할 만한 통계

• LCP는 통과하기 가장 어려운 Core Web Vital입니다. 구성 요소가 가장 많아 사이트가 INP나 CLS보다 더 어려워합니다. 출처
• 모바일은 데스크톱보다 어렵습니다. 느린 CPU와 연결이 LCP를 높이며 3G/저속 연결에서는 2,5 s 기준 달성이 거의 불가능합니다. 출처
• 이미지 다운로드 시간은 LCP에서 가장 작은 부분인 경우가 많습니다. Chrome의 HTTP Archive 분석에서는 다운로드 시간이 자주 병목이 아니며 TTFB와 발견 지연이 보통 더 컸습니다. 출처
• CrUX 범위는 좁습니다. 42백만 페이지 연구에서 약 11,4%만 관련 CrUX 필드 데이터가 있었습니다. 대부분은 측정할 만큼 실사용자 트래픽이 없습니다. 출처
• 모바일 페이지 62%, 데스크톱 페이지 74%가 좋음 LCP 달성(2025 Web Almanac). 모바일 격차는 CPU와 네트워크가 더 느린 탓입니다. 출처
• 모바일 페이지 중 2,1%만 LCP 이미지를 preload하지만 76%는 이미지가 LCP 요소입니다. 2025 Web Almanac 기준 큰 최적화 기회를 놓치고 있습니다. 출처
• fetchpriority="high" 채택률은 2022년 모바일 사이트 0,03%에서 2025년 17,3%로 증가했으며 WordPress 코어 도입의 영향이 컸습니다. 2025 Web Almanac에 따르면 Google Flights는 이 속성 하나로 LCP를 700 ms 개선했습니다. 출처

동영상

• Google Search Central(YouTube) — Chrome 팀의 LCP 최적화 실습을 포함한 Core Web Vitals와 페이지 경험 설명 영상. 채널

변경 내역