Largest Contentful Paint (LCP): 개념, 측정 및 최적화 방법

Largest Contentful Paint(LCP)란 무엇인가?

Largest Contentful Paint는 화면의 보이는 영역에 칠해지는 가장 큰 콘텐츠 요소(이미지, 동영상, 텍스트 블록)의 렌더링 시간입니다. LCP 값은 페이지를 요청한 시점부터 해당 요소가 스크롤 없이 볼 수 있는 영역에 표시되는 순간까지의 시간(밀리초)입니다.

어떤 사람들은 이를 "last contentful paint"라고 부릅니다. 이것은 가장 큰 요소에 관한 것입니다. 나중에 렌더링되는 더 작은 요소는 이 값을 변경하지 않습니다.

Largest Contentful Paint의 역사

왜 로딩 속도를 '페이지가 로드되는 데 걸리는 시간'으로 측정하지 않을까요?

대부분의 최신 웹사이트에서는 언제 페이지가 완전히 로드되었는지 특정할 수 없기 때문입니다. lazy loading과 점진적 로딩은 방문자가 머무는 동안 페이지가 계속 로딩될 수 있음을 의미합니다. 단일 시점으로는 페이지 속도를 설명할 수 없습니다.

페이지는 로드되는 동안 여러 순간에 느리다고 느껴질 수 있습니다. 서버 응답이 늦거나(Time to First Byte), 한동안 아무것도 나타나지 않거나(First Contentful Paint), 나머지 요소가 다 렌더링되었는데 히어로 이미지만 여전히 회색 상자일 수 있습니다(Largest Contentful Paint). 또는 첫 번째 클릭이 아무 반응을 하지 않기도 합니다.

방문자가 보는 것을 그대로 따르기 때문에 LCP가 선택되었습니다. LCP가 발생하면 스크립트가 여전히 실행 중이더라도 대부분의 방문자는 페이지 로딩이 끝났다고 생각합니다. 이 지표는 '페이지의 콘텐츠는 언제 보이는가?'라는 단 하나의 질문에 답하기 위해 만들어졌습니다.

LCP 대 FCP: 차이점은 무엇인가?

Largest Contentful Paint(LCP)와 First Contentful Paint(FCP)는 모두 로딩 성능을 측정하지만 서로 다른 순간을 측정합니다. FCP는 브라우저가 첫 번째 콘텐츠 픽셀을 렌더링하자마자 발생하며, 이는 작은 내비게이션 바 또는 로딩 스피너일 수 있습니다. LCP는 viewport 내에 가장 큰 의미 있는 요소가 렌더링될 때 발생합니다.

FCP는 페이지 로드가 시작되었음을 알려줍니다. LCP는 페이지가 다 로드된 것처럼 느껴짐을 알려주며, 이것이 Google이 LCP를 Core Web Vitals로 지정한 이유입니다.

대부분의 웹사이트에서는 LCP를 먼저 작업하십시오. FCP는 항상 LCP보다 먼저 발생하므로 빠른 LCP는 대개 빠른 FCP를 동반합니다. 빠른 FCP는 LCP에 대해 알려주는 바가 거의 없습니다. 페이지가 헤더를 0.8초에 렌더링하고 히어로 이미지를 4초에 렌더링할 수도 있기 때문입니다.

LCP가 중요한 이유

Core Web Vitals로서 LCP는 SEO에 중요합니다. 그러나 방문자에게는 훨씬 더 중요합니다. 아무도 기다리는 것을 좋아하지 않으며, 트래픽의 대부분을 차지하는 모바일 기기에서는 페이지 로드가 더 느립니다.

• 순위. LCP는 Google의 Core Web Vitals 중 하나이며, Google은 페이지 속도를 순위 요소로 사용합니다.
• 방문자. 흰 화면이나 히어로 이미지가 있어야 할 회색 상자를 쳐다보는 방문자는 곧바로 이탈합니다. 아래의 Vodafone 테스트에서 이를 수치로 확인했습니다.
• Google 광고. 방문 페이지 경험은 품질평가점수의 일부입니다. 느린 방문 페이지는 모든 클릭의 비용을 상승시킵니다.

사례 연구: Vodafone (LCP 31% 개선, 매출 8% 증가)

이탈리아 Vodafone은 기존 방문 페이지와 외형 및 작동 방식이 동일하지만 속도가 더 빠른 사본에 트래픽을 50/50으로 분할했습니다. 더 빠른 사본은 클라이언트 측 위젯 대신 서버에서 렌더링하고, 크기를 조정한 히어로 이미지를 제공하며, 스크롤 아래의 이미지를 지연시키고 더 작은 SVG 및 PNG 파일을 사용했습니다. 그 결과 LCP는 8.3초에서 5.7초로 단축(31% 속도 향상)되었고 매출은 8% 증가했습니다. (web.dev의 Vodafone 사례 연구)

테스트: Google Flights (fetchpriority로 700ms 단축)

Google Flights 페이지 테스트에서 LCP 이미지에 fetchpriority="high"를 추가하여 LCP를 2.6초에서 1.9초로 단축했습니다. 이 속성이 없으면 Chrome은 낮은 우선순위로 이미지를 요청하고, 레이아웃을 통해 해당 이미지가 viewport 내에 있다는 것이 확인되어야만 우선순위를 높입니다. 복잡한 페이지에서는 이 과정에 수백 밀리초의 대기 시간이 발생합니다. Core Web Vitals를 위한 리소스 우선순위 지정에 대해 자세히 알아보십시오.

어떤 요소가 LCP 요소로 간주되는가?

모든 요소가 LCP 요소가 될 수 있는 것은 아닙니다. 사용자가 페이지와 상호 작용하기 전에 화면의 보이는 영역(viewport)에 렌더링되어야 합니다.

해당하는 요소는 다음과 같습니다:

• <img> 요소.
• <svg> 요소 안에 중첩된 <image> 요소.
• <video> 요소 (포스터 이미지나 첫 번째 동영상 프레임 중 더 일찍 나타나는 것을 사용합니다).
• CSS url() 함수를 통해 로드된 배경 이미지가 있는 요소. 이 요소도 계산되지만 프리로드 스캐너가 볼 수 없어 브라우저가 이미지를 늦게 찾습니다. 배경 이미지 지연에서 자세한 내용을 확인하십시오.

• 텍스트 노드나 기타 인라인 텍스트 요소를 포함하는 블록 레벨 요소 (<span>과 같은 인라인 텍스트 요소의 경우 가장 가까운 블록 레벨 요소인 <div>나 <p>가 고려됩니다).

일부 요소는 제외됩니다: opacity: 0인 요소, 전체 viewport를 덮는 이미지(Chrome은 이를 배경으로 취급합니다) 및 낮은 엔트로피 이미지는 무시됩니다. Chrome 112부터 표시된 픽셀당 이미지 데이터가 0.05비트 미만인 이미지는 플레이스홀더로 간주되어 무시됩니다. Chrome은 이러한 규칙을 수시로 변경합니다.

LCP 요소 크기 측정 방법

브라우저는 다음 규칙에 따라 각 후보의 크기를 계산합니다:

• viewport 한정: 페이지의 보이는 부분만 고려됩니다. 요소가 보이는 viewport에 부분적으로만 있는 경우 고려되는 크기는 잘려나갑니다.
• 테두리, 패딩, 여백 제외: 모든 요소의 텍스트 및 이미지 테두리, 패딩, 여백은 완전히 무시됩니다.
• 텍스트 크기: 텍스트 요소는 텍스트 노드 주위에 칠할 수 있는 가장 작은 직사각형으로 보고됩니다.
• 이미지 크기: 이미지의 경우 내재된 크기(원본 너비와 높이)와 표시 크기(화면상의 크기) 중 더 작은 값이 LCP 요소 크기 계산에 사용됩니다.
• 최초 크기 반영: 레이아웃이 변경되거나 요소 크기가 변경되는 경우 첫 번째 크기만 LCP에 반영됩니다.
• 제거된 요소 포함: 요소가 DOM에서 제거되더라도 여전히 LCP 후보로 간주됩니다.

LCP 요소는 로딩 중에 변경될 수 있습니다

페이지는 여러 단계로 렌더링되므로 페이지가 로딩되는 동안 LCP 요소가 자주 변경됩니다. 첫 번째 사용자 상호 작용 전까지 브라우저는 새로운 LCP 후보를 계속 보고합니다. viewport 내에 보이고 이전 후보보다 더 큰 새로운 요소가 렌더링되면 그것이 새로운 LCP 요소가 됩니다.

LCP field data 분석 결론: CoreDash는 매일 수백만 개의 LCP 데이터를 추적합니다. 모바일에서 LCP 요소는 종종 단락이나 헤딩입니다. 데스크톱에서는 더 넓은 viewport에 더 큰 이미지가 들어가므로 동일한 페이지라도 기기별로 LCP 요소가 다를 때가 많습니다. 무엇을 수정할지 결정하기 전에 두 기기 환경을 모두 확인하십시오.

좋은 LCP 점수란 무엇인가?

Core Web Vitals의 LCP 기준을 통과하려면 전체 페이지 방문의 최소 75%가 좋은 LCP(2.5초 미만)를 기록해야 합니다. 2.5초에서 4초 사이는 개선이 필요하며 4초 초과는 불량입니다. PageSpeed Insights에서 모바일 탭을 먼저 확인하십시오. 상단의 field data는 지난 28일 동안의 75백분위수(p75)를 나타냅니다.

CoreDash 데이터가 보여주는 것

이미지 LCP 대 텍스트 LCP

이미지 기반 LCP 요소가 있는 페이지의 p75 LCP는 744ms로, 텍스트 기반 LCP 요소(388ms)보다 거의 두 배 느립니다. 이러한 격차의 대부분은 브라우저가 이미지를 늦게 찾고 요청하기 때문에 발생합니다(아래 4단계 참조).

프리로드와 lazy loading의 영향

프리로드된 LCP 이미지의 p75는 364ms이며 불량인 페이지 로드는 없습니다. lazy loading이 적용된 LCP 이미지는 720ms에 달하고 페이지 로드의 4.3%가 불량으로 평가되며, 프리로드되지 않은 이미지는 752ms입니다. 절대 LCP 이미지에 lazy loading을 적용하지 마십시오. 그리고 이미지가 일찍 요청되도록 확실히 하십시오: HTML 내에 fetchpriority="high"를 사용하거나, 불가피한 경우 프리로드 하십시오.

모바일 대 데스크톱 LCP

모바일 LCP(75백분위수에서 764ms)는 데스크톱 LCP(380ms)의 두 배입니다. 모바일 네트워크는 더 느리고 휴대폰은 CPU 성능이 낮습니다. Google은 모바일과 데스크톱을 별도로 평가하며 대부분의 사이트가 모바일에서 실패하므로 모바일에서 먼저 시작하십시오.

웹 전반의 LCP 동향

2026년 8월 CrUX 릴리스에 따르면 좋은 LCP를 가진 출처는 68.1%로 전년도의 66.7%에서 상승했습니다. 하지만 이는 여전히 3가지 Core Web Vitals 중 가장 낮은 수치이며(INP 85.3%, CLS 81.5%), 대부분의 사이트에서 통과 여부를 결정짓는 것은 LCP입니다.

HTTP Archive의 크롤링 데이터는 CrUX가 수집하지 못하는 상세 정보를 제공합니다. 2025 Web Almanac에 따르면 모바일 페이지의 76%에서 LCP 요소는 이미지이며 약 16%의 페이지가 이 이미지에 lazy loading을 적용합니다. LCP 이미지가 있는 모바일 페이지 중 17%만이 fetchpriority="high"를 사용하고 약 2%만이 프리로드를 적용합니다.

LCP 측정 방식: 4가지 핵심 단계

Google에 따르면 Largest Contentful Paint는 4개의 세부 단계로 나눌 수 있습니다. 각 단계는 서로 다른 수정 방법을 요구하므로 먼저 어느 단계가 느린지 파악하십시오. 느린 Time to First Byte(TTFB)는 서버 측 작업이 필요하고 느린 리소스 로드 지연은 HTML 수정이 필요합니다.

LCP 시간은 다음 4가지 단계의 합입니다:

• Time to First Byte(TTFB): 서버 응답 시간입니다. DNS 조회부터 TCP/TLS 연결을 거쳐 브라우저가 HTML 문서의 첫 번째 바이트를 수신하는 순간까지를 모두 포괄합니다. 느린 TTFB는 그 이후의 모든 과정을 지연시킵니다. 흔한 원인은 캐시되지 않은 HTML이며 이로 인해 방문할 때마다 PHP나 Node에서 페이지를 다시 빌드합니다. HTML을 캐시하지 않는 CDN은 이미지만 빠르게 만들 뿐입니다.
• 리소스 로드 지연: TTFB가 완료된 후 브라우저가 실제로 LCP 리소스 다운로드를 시작할 때까지의 시간입니다. 이 지연 시간이 길다는 것은 브라우저가 LCP 리소스를 늦게 찾았다는 것을 의미합니다. 대개 CSS 배경 이미지(프리로드 스캐너가 발견할 수 없음)나 클라이언트 측 렌더링(JavaScript 실행 후에만 LCP 요소가 나타남)에서 발생합니다. LCP 요소를 초기 HTML에 배치하고, 그것이 불가능할 때만 LCP 이미지를 프리로드하십시오.
• 리소스 로드 시간: LCP 리소스(이미지, 글꼴, 동영상)를 다운로드하는 데 걸리는 시간입니다. 이 단계는 파일 크기와 네트워크에 의존합니다. AVIF나 WebP를 사용하고 휴대폰에 적절한 크기의 이미지가 전송되도록 srcset을 설정하십시오. 대부분의 사이트에서 4단계 중 가장 짧습니다.
• 요소 렌더링 지연: LCP 리소스 다운로드가 완료된 후 해당 요소가 화면에 완전히 렌더링될 때까지의 시간입니다. 이미지는 준비되었지만 브라우저가 아직 렌더링할 수 없는 상태입니다. main thread의 render blocking CSS와 JavaScript가 일반적인 원인입니다. 테스트 스크립트가 로드될 때까지 페이지를 숨기는 A/B 테스트 스니펫이 대표적인 예입니다.

Google은 이미지 LCP를 가진 실제 Chrome 탐색을 분석하여 p75 LCP를 다음 단계들로 나누었습니다. 각 그룹의 중앙값 출처는 다음과 같습니다:

LCP가 불량인 사이트에서는 TTFB와 리소스 로드 지연을 합쳐 3.5초 이상이 소요됩니다. 이미지를 다운로드하는 데는 350ms가 걸립니다. 불량 LCP를 가진 대부분의 출처는 전체 LCP 시간의 10% 미만을 LCP 이미지 다운로드에 사용합니다.

각 단계를 찾고 수정하는 방법에 대해서는 Largest Contentful Paint(LCP) 문제 찾기 및 수정을 읽어보십시오.

일반적인 LCP 실수

실수 1: LCP 이미지에 lazy loading 적용

loading="lazy"는 이미지가 viewport에 가까워질 때까지 다운로드를 대기하라고 브라우저에 지시합니다. LCP 이미지는 이미 viewport 안에 있으므로 브라우저는 먼저 레이아웃을 통해 이를 파악한 후에야 다운로드를 시작할 수 있습니다. 테마와 페이지 빌더는 종종 히어로 이미지를 포함한 모든 이미지에 이 속성을 추가합니다. LCP 이미지에서 이 속성을 제거하십시오. 그것이 전부입니다. 2025 Web Almanac에 따르면 약 16%의 페이지가 이 실수를 저지릅니다. lazy loading된 LCP 이미지 수정 방법에 대한 가이드를 읽어보십시오.

실수 2: LCP 이미지가 늦게 발견됨

슬라이더나 클라이언트 측에서 렌더링된 히어로 이미지는 CSS 파싱이나 JavaScript 실행이 끝난 후에야 페이지에 이미지 URL을 추가합니다. 이로 인해 다운로드가 시작되기도 전에 수백 밀리초를 낭비하게 됩니다. 가장 좋은 해결책은 HTML에 일반적인 <img> 태그를 사용하는 것입니다. 불가능하다면 <head>에 프리로드 힌트를 추가하십시오:

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

브라우저는 즉시 다운로드를 시작합니다. 프리로드만으로는 우선순위가 높아지지 않으므로 fetchpriority="high"를 유지하십시오. 그렇지 않으면 이미지가 스타일시트와 스크립트 뒤에서 여전히 대기하게 됩니다. 자세한 내용은 LCP 이미지 프리로드 가이드를 확인하십시오.

실수 3: CSS 배경 이미지를 LCP 요소로 사용

프리로드 스캐너는 background-image: url(...)을 볼 수 없습니다. 브라우저는 HTML과 CSS를 모두 다운로드하고 규칙을 페이지의 요소에 매칭한 후에야 이미지를 발견합니다. 이는 리소스 로드 지연을 추가합니다. 해결책은 대신 fetchpriority="high" 속성과 함께 표준 <img> 태그를 사용하는 것입니다:

<img src="/img/hero.webp"
     alt="Descriptive alt text"
     width="1200"
     height="600"
     fetchpriority="high">

이제 프리로드 스캐너가 HTML에서 이미지를 먼저 찾고 fetchpriority="high"가 이를 다운로드 대기열의 맨 앞에 둡니다. 자세한 내용은 리소스 우선순위 지정 가이드를 참조하십시오.

Largest Contentful Paint 측정 방법

JavaScript로 Largest Contentful Paint 측정하기

가장 빠른 방법은 PerformanceObserver를 사용하는 것입니다. 다음 스니펫은 LCP 시간과 요소를 기록합니다:

new PerformanceObserver((list) => {
    const lcpEntry = list.getEntries().at(-1);
    console.log('LCP value: ', lcpEntry.startTime);
    console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
  }).observe({ type: 'largest-contentful-paint', buffered: true });

간단한 확인 이상이 필요하다면 Web Vitals Library를 사용하십시오.

Chrome DevTools에서 Largest Contentful Paint(LCP) 측정하기

1. Ctrl+Shift+I(Mac의 경우 Cmd+Option+I)를 눌러 Chrome DevTools를 엽니다.
2. Performance 패널로 이동합니다. 현재 페이지의 LCP를 LCP 요소와 함께 즉시 표시합니다.
3. 패널의 새로고침 버튼을 클릭하여 추적(trace)을 기록합니다. 추적의 LCP 마커는 LCP 요소와 4단계를 보여줍니다.

추적에서 살펴보아야 할 내용을 포함한 전체 설명은 Chrome DevTools로 LCP 진단하기에 있습니다.

실험실(Lab) 및 현장(Field) 도구로 Largest Contentful Paint 측정하기

lab data와 field data는 서로 다른 역할을 수행합니다. 둘 다 필요합니다.

• Field data (RUM 및 CrUX)는 Google이 통과 여부를 결정할 때 사용하는 데이터입니다. 실제 사용자가 경험하는 수치입니다. 문제가 있는지 파악하려면 여기서부터 시작하십시오.
• Lab data (Lighthouse 등)는 통제된 테스트입니다. Google은 이를 순위에 반영하지 않지만 디버깅에 필요합니다. 문제가 왜 발생했는지 알려주기 때문입니다.

도구:

Largest Contentful Paint 개선하기

모바일에서 가장 느린 템플릿을 선택하여 4가지 LCP 단계를 살펴보십시오. CoreDash는 실제 방문자의 페이지별 데이터를 보여주고 DevTools는 단일 로드를 보여줍니다. 위 field data에서 보듯 불량 LCP를 가진 거의 모든 사이트에서 TTFB와 리소스 로드 지연이 가장 큰 비중을 차지하므로 여기서부터 시작하십시오.

모든 사람이 가장 먼저 시도하는 방법은 히어로 이미지를 AVIF로 변환하는 것입니다. 4초의 LCP를 가진 사이트에서 전체 다운로드는 약 350ms이므로 더 작은 파일은 그 중 아주 작은 일부 시간만을 단축시킵니다. 변환은 하되 가장 마지막에 하십시오.

단계별 조치:

• TTFB: 서버나 CDN에서 HTML을 캐시하십시오. TTFB 최적화 가이드에서 자세한 내용을 읽어보십시오.
• 리소스 로드 지연: HTML에 <img>를 넣고 loading="lazy"를 없애며 fetchpriority="high"를 적용하십시오. 리소스 로드 지연 수정하기를 참조하십시오.
• 리소스 로드 시간: 기기에 맞는 더 작은 파일 크기를 사용하십시오. LCP 이미지 최적화 방법을 참조하십시오. 또한 실제 프로젝트에서 우리가 어떻게 LCP를 70% 낮췄는지에 대해서도 읽어볼 수 있습니다.
• 요소 렌더링 지연: render blocking CSS를 줄이고 스크립트를 지연시키며 깜빡임 방지 스니펫을 제거하십시오. 요소 렌더링 지연 수정하기를 참조하십시오.

관련 가이드

LCP의 각 부분에는 자체 가이드가 있습니다:

• LCP 문제 찾기 및 수정: DevTools, WebPageTest, CoreDash를 사용하여 어느 단계가 느린지 파악합니다.
• Chrome DevTools로 LCP 진단하기: Performance 추적 패널의 LCP 마커 활용법을 다룹니다.
• LCP 이미지 최적화: 이미지 형식, 크기, srcset을 다룹니다.
• 리소스 로드 지연: LCP 이미지를 더 일찍 요청하는 방법을 다룹니다.
• 리소스 로드 시간: 리소스 다운로드 자체를 최적화하는 방법을 다룹니다.
• 요소 렌더링 지연: 이미지가 준비되었으나 아직 렌더링되지 않았을 때의 해결책을 다룹니다.