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

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

Largest Contentful Paint는 화면의 보이는 영역에 렌더링된 가장 큰 콘텐츠 요소(이미지, 비디오 또는 텍스트 유형)의 렌더링 시간을 측정한 값입니다. LCP 타이밍은 페이지를 요청한 시점과 해당 웹 페이지의 보이는 영역(스크롤을 내리기 전 화면)에 가장 큰 콘텐츠 요소가 표시될 때까지의 시간을 밀리초 단위로 나타냅니다.

Largest Contentful Paint의 역사

생각해 보면, LCP는 Core Web Vitals의 로딩 부분을 나타내기에 다소 사소한 지표처럼 보일 수 있습니다. 왜 로딩 속도를 '페이지가 로드되는 데 걸리는 시간'으로 측정하지 않을까요?

그 이유는 대부분의 최신 웹사이트에서 페이지 로드가 완료된 시점을 정의하는 것이 어렵거나 불가능하기 때문입니다. 점점 더 많은 웹사이트가 지연 로딩(lazy loading)이나 점진적 로딩(progressive loading)과 같은 기술을 사용하며, 이로 인해 페이지는 기본적으로 끊임없이 로드될 수 있습니다. 즉, 페이지 속도는 단일 시점으로 측정할 수 없습니다.

페이지를 로드할 때 사용자가 페이지가 빠르거나 느리다고 경험하게 만드는 몇 가지 순간들이 있습니다. 예를 들어 서버 지연(Time to First Byte), 콘텐츠가 처음으로 표시되는 시간(First Contentful Paint), 보이는 뷰포트가 완전해 보이는 시간(Largest Contentful Paint), 그리고 페이지가 상호작용 가능해지는 시점(링크 클릭이 가능해지는 시점)은 모두 로딩 과정에서 사이트가 느리거나 빠르다고 느껴질 수 있는 지점들입니다!

Largest Contentful Paint (LCP)가 선택된 이유는 방문자의 UX에 초점을 맞추기 때문입니다. LCP가 발생하면 방문자는 페이지 로딩이 완료되었다고 생각할 수 있습니다(백그라운드 프로세스가 계속 실행 중이더라도). LCP는 '페이지의 콘텐츠가 언제 표시되는가?'라는 질문에 답하기 위해 만들어졌습니다. 이것이 바로 LCP가 사용자 중심 성능의 핵심 지표로 인식되는 이유입니다.

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

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

이렇게 생각해 보세요. FCP는 페이지가 로드되기 시작했음을 알려주고, LCP는 페이지가 모두 로드된 것처럼 느껴짐을 알려줍니다. Google은 LCP가 사용자가 인식하는 "속도"를 더 정확하게 반영하기 때문에 이를 Core Web Vitals로 채택했습니다.

대부분의 웹사이트에서는 LCP 최적화를 우선시해야 합니다. LCP가 빠르다면 로딩 타임라인에서 FCP가 더 일찍 발생하기 때문에 FCP 역시 거의 항상 빠를 것입니다. 그 반대는 성립하지 않습니다. 빠른 FCP가 빠른 LCP를 보장하지는 않습니다.

LCP가 비즈니스에 중요한 이유

Largest Contentful Paint는 3가지 Core Web Vitals 중 하나입니다. Core Web Vitals로서 Largest Contentful Paint는 SEO에 중요하지만, 무엇보다도 UX에 결정적입니다. 방문자들은 기다리는 것을 좋아하지 않으며, (데스크톱 트래픽보다 느린 경향이 있는) 모바일 트래픽이 점점 증가함에 따라 Largest Contentful Paint를 최적화하는 것은 매우 합리적입니다.

• SEO 측면. 맞습니다. Google은 검색 결과에서 최고의 페이지를 제공하는 데 초점을 맞춥니다. LCP는 Google의 Core Web Vitals의 일부입니다. Google은 사이트 속도가 검색 결과의 한 요소임을 명확히 밝히고 있습니다.
• 방문자 측면: Google의 자체 최근 연구에 따르면 로딩 시간이 3초일 때 사용자가 사이트를 이탈할 확률이 두 배로 증가합니다. 여러분도 스스로 체감하실 것입니다. 인터넷을 서핑하는 동안 느리게 로드되는 웹사이트만큼 짜증나는 것은 거의 없습니다. 여러분 역시 느리게 로드되는 페이지를 금방 떠날 가능성이 높습니다.
• 기타 이유: 페이지 속도는 Google 광고 점수(Ad Score)의 한 요소입니다. 즉, 광고를 더 저렴하게 집행할 수 있습니다. 또한 Core Web Vitals를 통과하는 것은 Google의 주요 스토리(Top Story) 박스에 오르기 위한 필수 조건 중 하나입니다.

빠른 LCP는 방문자에게 페이지가 빠르게 로드된다는 인식을 줍니다. 그 결과 방문자가 페이지를 이탈할 가능성이 줄어듭니다.

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

Vodafone Italy는 LCP 점수를 최적화하는 통제된 실험을 진행했습니다. LCP를 31% 단축함으로써 매출이 8% 증가한 것을 확인했습니다. 이는 단순한 상관관계가 아니라, 더 빠른 체감 로딩 속도가 더 높은 수익으로 이어진다는 것을 증명하는 직접적인 A/B 테스트 결과입니다. 최적화 작업은 LCP 이미지 사전 로딩(preloading)과 렌더링 차단 리소스를 줄이는 데 초점을 맞췄습니다. web.dev에서 Vodafone 사례 연구 전문을 읽어보세요.

사례 연구: Google Flights (fetchpriority로 700ms 단축)

Google Flights 팀은 히어로 이미지에 fetchpriority="high"를 추가하여 LCP를 700밀리초 개선했습니다. 이 단일 HTML 속성 변경은 성능 스프린트에서 가장 큰 영향을 미친 최적화였습니다. fetchpriority 속성은 브라우저에게 다른 리소스보다 LCP 이미지 다운로드를 우선시하도록 지시하며, Google Flights 실험에서 보여주듯 그 영향은 극적일 수 있습니다. Core Web Vitals를 위한 리소스 우선순위 지정에 대해 자세히 알아보세요.

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

모든 요소가 LCP 요소로 간주되는 것은 아닙니다. 가장 큰 Contentful 요소는 사용자가 페이지와 상호작용하기 전에 화면의 보이는 영역(뷰포트)에 렌더링되어야 합니다.

해당 요소는 다음 중 하나여야 합니다.

• <img> 요소.
• <svg> 요소 안에 중첩된 <image> 요소.
• <video> 요소 (포스터 이미지나 첫 번째 비디오 프레임 중 더 일찍 발생하는 항목이 사용됨).
• CSS url() 함수를 통해 로드된 배경 이미지가 있는 요소. (참고: 이는 브라우저의 사전 로드(preload) 스캐너가 이미지를 발견할 수 없게 만들므로 LCP 최적화의 안티 패턴입니다. 배경 이미지 지연 로드에 대한 가이드를 읽어보세요).

• 텍스트 노드나 다른 인라인 텍스트 요소를 포함하는 블록 수준 요소 (<span>과 같은 인라인 텍스트 요소의 경우 가장 가까운 블록 수준 요소인 <div> 또는 <p>가 간주됨).

현재 opacity: 0으로 숨겨진 요소, 뷰포트 크기와 100% 일치하는 이미지(커버 이미지), 그리고 플레이스홀더(엔트로피가 낮은 이미지)와 같은 특정 요소들은 LCP 후보에서 제외됩니다. 이는 사양이 발전함에 따라 변경될 수 있다는 점을 명심하세요!

기술적 측면: LCP 요소 크기 측정

LCP는 뷰포트에서 가장 큰 시각적 콘텐츠 요소를 식별하고 정확한 규칙 세트를 기반으로 그 크기를 계산합니다. 이러한 규칙은 복잡한 레이아웃에서도 일관성과 정확성을 보장합니다.

• 뷰포트 전용: 페이지의 보이는 영역만 고려됩니다. 요소가 보이는 뷰포트에 부분적으로만 있는 경우 고려되는 크기는 잘려나갑니다.
• 테두리, 패딩 또는 여백 제외: 모든 요소에 대해 텍스트 및 이미지 테두리(border), 패딩(padding), 여백(margin)은 완전히 무시됩니다.
• 텍스트 크기: 텍스트 요소는 텍스트 노드 주변에 그릴 수 있는 가장 작은 직사각형으로 보고됩니다.
• 이미지 크기: 이미지의 경우 기본 크기(원본 너비 및 높이)와 표시 크기(화면 상의 크기) 중 더 작은 값이 LCP 요소 크기를 계산하는 데 사용됩니다.
• 첫 번째 크기 우선: 레이아웃이 변경되거나 요소 크기가 변경될 때, LCP에는 첫 번째 크기만 고려됩니다.
• 제거된 요소 포함: 요소가 DOM에서 제거되더라도 여전히 LCP 후보로 유지됩니다.

LCP의 동적 특성

Largest Contentful Paint (LCP)는 동적인 지표입니다. 렌더링이 복잡하고 여러 단계에 걸쳐 발생할 수 있기 때문에 페이지 로딩 중 LCP 요소가 변경되는 것은 정상입니다. 사용자의 첫 상호작용 전에 브라우저의 성능 옵저버(performance observer)는 LCP 후보로 간주될 수 있는 모든 요소를 식별합니다. 뷰포트 내에 표시되면서 이전에 식별된 LCP 요소보다 더 큰 새로운 요소가 렌더링되면, 이것이 새로운 LCP가 됩니다.

LCP 필드 데이터의 시사점: CoreDash에서는 매일 수백만 개의 LCP 항목을 추적합니다. 모바일 페이지 뷰의 경우 LCP 요소는 종종 단락이나 제목과 같은 텍스트 기반 요소임이 밝혀졌습니다. 평균적으로 (정확히는 75백분위수에서) LCP 요소가 텍스트 노드이거나 일반 이미지인 경우 Core Web Vitals를 통과하게 됩니다. LCP 요소가 배경 이미지, 비디오 또는 지연 로드(lazy-loaded) 이미지인 경우 Core Web Vitals는 실패하는 경향이 있습니다.

좋은 LCP 점수란 무엇인가요?

Largest Contentful Paint에서 Core Web Vitals를 통과하려면 방문자의 최소 75%가 '좋음(good)' LCP 점수를 받아야 합니다. LCP 점수가 0에서 2.5초 사이면 좋음(good)으로 간주되며, 2.5에서 4초 사이는 개선 필요(needs improvement), 4초 이상은 나쁨(poor)으로 간주됩니다.

실제 LCP 데이터가 보여주는 것

CoreDash는 매일 수백만 건의 실제 사용자 LCP 측정값을 추적합니다. 웹 전반의 LCP 성능에 대해 데이터가 밝히는 내용은 다음과 같습니다.

이미지 LCP 대 텍스트 LCP

이미지 기반 LCP 요소가 있는 페이지의 75백분위수 LCP는 744ms로, 텍스트 기반 LCP 요소의 388ms보다 거의 두 배나 느립니다. 이는 이미지 최적화가 LCP 점수를 향상시키는 데 가장 큰 영향을 미치는 영역임을 확인시켜 줍니다. LCP 요소가 이미지인 경우 최적화에 특히 적극적으로 임해야 합니다.

사전 로딩(Preloading)과 지연 로딩(Lazy Loading)의 영향

사전 로드된 LCP 이미지는 75백분위수에서 364ms로 100% "좋음" 점수를 달성합니다. 대조적으로, 지연 로드된 LCP 이미지는 720ms로 가장 느린 편에 속하며 페이지 로드의 4.3%가 "나쁨"으로 평가됩니다. 사전 로드되지 않은 이미지 역시 752ms로 거의 비슷한 수준의 저조한 성능을 보입니다. 결론은 명확합니다. LCP 이미지를 사전 로딩(preload)하고 절대로 지연 로딩(lazy-load)하지 마세요.

모바일 대 데스크톱 LCP

모바일 LCP(75백분위수에서 764ms)는 데스크톱 LCP(380ms)보다 2배 더 느립니다. 이 격차는 더 느린 모바일 네트워크와 상대적으로 성능이 낮은 모바일 프로세서로 인해 발생합니다. Google이 모바일 우선 인덱싱(mobile-first indexing)을 사용하기 때문에 모바일 LCP 최적화를 우선시해야 합니다.

글로벌 LCP 통계

HTTP Archive Web Almanac 2025에 따르면, 전 세계 모바일 페이지의 62%가 좋은 LCP 점수(2.5초 미만)를 달성했으며, 이는 2022년 44%에서 상승한 수치입니다. LCP는 여전히 통과하기 가장 어려운 Core Web Vitals이며 전체 Core Web Vitals 점수의 주요 병목 지점입니다. 또한 모바일 LCP 요소의 73%가 이미지이며, 16%의 모바일 사이트가 실수로 LCP 이미지를 지연 로드(lazy-load)하고 있습니다.

LCP 측정 방식: 4가지 주요 단계

Google에 따르면 Largest Contentful Paint는 4개의 하위 파트로 나눌 수 있습니다. 각 단계마다 완전히 다른 해결책이 필요하기 때문에 어느 단계에서 병목 현상이 발생하는지 이해하는 것이 효율적인 최적화를 위해 필수적입니다. 느린 Time to First Byte (TTFB)는 서버 측 작업이 필요하지만, 리소스 로드 지연이 느린 경우에는 HTML의 변경이 필요합니다.

페이지의 최종 LCP 시간은 단일하고 통합된 값이 아닙니다. 4개의 구분된 하위 파트의 합입니다. 이 세부 구성을 이해하는 것이 LCP 문제를 효율적으로 진단하고 수정하는 핵심입니다.

다음은 4가지 단계에 대한 세부 내용입니다.

• Time to First Byte (TTFB): 이는 순수한 서버 응답 시간입니다. DNS 조회부터 TCP/TLS 연결을 거쳐 브라우저가 HTML 문서의 첫 번째 바이트를 수신하는 순간까지의 모든 과정을 포함합니다. 느린 TTFB는 LCP에 항상 치명적인 근본적인 문제입니다. 웹 전반에 걸쳐 LCP가 나쁜 사이트들은 TTFB에만 평균 2.27초를 소비하는데, 이는 2.5초 임계값에 거의 달하는 수치입니다. TTFB를 최적화하려면 서버 측 캐싱, CDN 구성 및 효율적인 백엔드 코드가 필요합니다.
• 리소스 로드 지연(Resource Load Delay): 이는 "발견 간극(discovery gap)"입니다. TTFB가 완료된 시점과 브라우저가 실제로 LCP 리소스를 다운로드하기 시작하는 시점 사이의 시간을 측정합니다. 여기서 지연이 길다는 것은 브라우저가 LCP 리소스를 늦게 발견했음을 의미합니다. 이는 CSS 배경 이미지(사전 로드 스캐너가 발견할 수 없음)나 클라이언트 측 렌더링(JavaScript 실행 후에만 LCP 요소가 나타남)을 사용할 때 나타나는 전형적인 증상입니다. 해결책은 LCP 요소가 초기 HTML에 있는지 확인하고, 브라우저가 충분히 일찍 발견할 수 없는 경우 LCP 이미지를 사전 로딩(preload)하는 것입니다.
• 리소스 로드 시간(Resource Load Duration): 이는 실제로 LCP 리소스 파일(이미지, 글꼴 또는 비디오)을 다운로드하는 데 걸리는 시간입니다. 이 단계는 전적으로 파일 크기와 네트워크 상태에 영향을 받습니다. 최적화란 AVIF나 WebP 같은 최신 이미지 형식을 사용하고, srcset으로 반응형 이미지를 구현하며, 적절한 압축과 함께 CDN을 통해 에셋을 제공하는 것을 의미합니다.
• 요소 렌더링 지연(Element Render Delay): 마지막 지연 단계입니다. LCP 리소스 다운로드가 완료된 후 해당 요소가 화면에 완전히 렌더링될 때까지의 시간을 측정합니다. 이 지연은 거의 항상 브라우저의 메인 스레드가 다른 작업(특히 JavaScript 처리)에 의해 차단되어 발생합니다. 렌더링을 차단하는 CSS와 동기식 스크립트가 가장 흔한 원인입니다.

Largest Contentful Paint를 향상시키기 위해 이러한 각 중점 영역을 최적화할 수 있습니다. 취해야 할 단계를 이해하려면 Largest Contentful Paint (LCP) 문제 파악 및 수정을 읽어보세요.

흔한 LCP 실수

CoreDash를 통해 수백만 번의 페이지 로드를 분석한 결과, 3가지 LCP 실수가 다른 어떤 것보다 훨씬 더 자주 나타납니다. 이를 피하는 것만으로도 대부분의 사이트가 LCP 합격 점수에 도달할 수 있습니다.

실수 1: LCP 이미지의 지연 로딩(Lazy-Loading)

히어로 이미지에 loading="lazy"를 추가하는 것은 가장 흔한 단일 LCP 실수입니다. 지연 로딩은 브라우저에게 스크롤되어 보일 때까지 이미지 다운로드를 의도적으로 지연시키도록 지시합니다. (이미 뷰포트 내에 있는) LCP 이미지의 경우, 이는 완전히 불필요한 지연을 초래합니다. CrUX 데이터에 따르면 모바일 사이트의 16%가 이러한 실수를 범하고 있습니다. CoreDash 데이터는 사전 로드된 이미지의 경우 364ms 및 0%의 '나쁨' 비율을 기록한 반면, 지연 로드된 LCP 이미지는 75백분위수에서 720ms 및 4.3%의 '나쁨' 경험을 나타냅니다. 지연 로드된 LCP 이미지 수정 방법에 대한 전체 가이드를 읽어보세요.

실수 2: LCP 이미지를 사전 로드(Preloading)하지 않음

지연 로딩이 없더라도 많은 사이트가 브라우저에 LCP 이미지에 대해 충분히 일찍 알리지 못합니다. CSS를 파싱하거나 JavaScript를 실행한 후에야 이미지 URL이 발견된다면, 브라우저는 다운로드를 시작하기도 전에 수백 밀리초를 낭비하게 됩니다. 문서의 <head>에 사전 로드(preload) 힌트를 추가하는 것이 해결책입니다.

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

이는 브라우저에게 CSS나 레이아웃 계산을 기다리지 말고 즉시 이미지 다운로드를 시작하도록 지시합니다. 효과를 극대화하려면 fetchpriority="high"와 결합하세요. LCP 이미지 사전 로딩에 대한 가이드에서 자세히 알아보세요.

실수 3: LCP에 CSS 배경 이미지 사용

background-image: url(...)을 통해 로드된 CSS 배경 이미지는 브라우저의 사전 로드(preload) 스캐너에 보이지 않습니다. 브라우저는 HTML을 다운로드하고, CSS를 파싱하며, 렌더 트리를 구성하기 전까지는 이를 발견할 수 없습니다. 이는 상당한 리소스 로드 지연을 추가합니다. CrUX 데이터에 따르면 모바일 페이지의 9%가 CSS 배경 이미지를 LCP 요소로 사용합니다. 해결책은 대신 표준 <img> 태그를 fetchpriority="high" 속성과 함께 사용하는 것입니다.

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

fetchpriority="high" 속성은 이 이미지가 페이지에서 가장 우선순위가 높은 리소스임을 브라우저에 직접 신호로 보냅니다. Google Flights 사례 연구에서 증명되었듯이, 이 단일 속성으로 LCP를 700ms나 단축할 수 있습니다. 더 깊이 이해하려면 리소스 우선순위 지정 가이드를 참조하세요.

Largest Contentful Paint 측정 방법

Largest Contentful Paint (LCP)는 순수 JavaScript, 랩(Lab) 데이터 및 필드(Field) 도구로 측정할 수 있습니다. 각 방법에는 장단점이 있습니다.

JavaScript로 Largest Contentful Paint 측정하기

JavaScript를 사용하여 Largest Contentful Paint (LCP)를 측정할 때 Performance Observer API는 빠른 솔루션을 제공합니다. 다음 코드 스니펫은 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 });

이 스니펫은 LCP 항목이 보고될 때 이를 추적하여 타임스탬프와 요소 세부 정보를 콘솔에 표시합니다. 더 광범위한 인사이트를 얻으려면 Web Vitals Library를 사용하는 것을 고려해 보세요.

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

1. Ctrl+Shift+I(Mac의 경우 Cmd+Option+I)를 눌러 Chrome DevTools를 엽니다.
2. Performance 탭으로 이동합니다.
3. Core Web Vitals를 보려면 페이지를 새로고침합니다.

이제 DevTools Performance 탭에 Largest Contentful Paint의 타이밍과 요소를 포함하여 Core Web Vitals에 대한 정보가 표시됩니다.

랩(Lab) 및 필드(Field) 도구로 Largest Contentful Paint 측정하기

분명히 말씀드리자면, 랩(Lab) 데이터와 필드(Field) 데이터는 서로 다른 두 가지 목적을 제공합니다. 둘 다 필요합니다.

• 필드 데이터 (RUM 및 CrUX)는 Core Web Vitals 통과를 위해 실제로 중요한 유일한 데이터입니다. 실제 사용자가 경험하는 데이터입니다. Google은 CrUX 데이터 세트의 이 데이터를 사용합니다. 문제가 있는지 알아보기 위해 여기서부터 시작하세요.
• 랩 데이터 (Lighthouse 등)는 통제된 테스트입니다. Google이 랭킹에 사용하는 데이터는 아니지만, 디버깅을 위해 필수적입니다. 이 데이터를 사용하여 문제가 발생하는 원인을 파악합니다.

필수 도구에 대한 빠른 가이드입니다.

Largest Contentful Paint 개선하기

LCP 최적화에는 4단계를 모두 다루는 체계적인 접근이 필요합니다. 네트워크 관련이든 CPU 집약적이든 LCP 요소가 렌더링되기 전에 발생하는 모든 작업이 LCP 점수에 영향을 줄 수 있습니다. 단지 하나의 해결책만 쫓지 말고 전체 체인을 이해해야 합니다. 상위 수준의 전략은 다음과 같습니다.

• TTFB 최적화: 서버는 빨라야 합니다. TTFB가 느리다면 다른 작업은 아무런 소용이 없습니다. 여기에는 서버 측 캐싱, CDN 사용, 그리고 효율적인 백엔드 코드가 포함됩니다. TTFB 최적화 가이드에서 자세한 내용을 읽어보세요.
• 리소스 로드 지연(Resource Load Delay) 제거: 브라우저의 사전 로드 스캐너가 즉시 찾을 수 있도록 LCP 요소가 초기 HTML에 있는지 확인하세요. LCP에 CSS 배경 이미지를 사용하지 마세요. 늦게 발견되는 중요한 이미지를 사전 로드(preload) 하세요. 리소스 로드 지연 수정 가이드에서 방법을 알아보세요.
• 리소스 로드 시간(Resource Load Time) 단축: LCP 파일을 더 작게 만드세요. AVIF와 같은 최신 이미지 형식을 사용하고, 반응형 이미지를 도입하며, 적절한 압축을 수행하는 것을 의미합니다. LCP 이미지 최적화 방법에 대한 전체 가이드를 확인해 보세요. 또한 실제 프로젝트에서 어떻게 LCP를 70% 낮췄는지에 대한 글도 읽어보실 수 있습니다.
• 요소 렌더링 지연(Element Render Delay) 단축: 메인 스레드 차단을 멈추세요. 중요하지 않은 JavaScript를 지연시키고, 긴 작업을 분할하며, 렌더링 차단 CSS를 최소화하세요. 이는 요소 렌더링 지연 수정 가이드에서 다룹니다.

관련 가이드

이 허브 페이지는 상위 수준에서 Largest Contentful Paint를 다룹니다. LCP 최적화의 각 측면에 대한 상세하고 실용적인 지침을 원하시면, 다음 전용 가이드들을 살펴보세요.

• LCP 문제 파악 및 수정: Chrome DevTools, WebPageTest, CoreDash를 활용하여 느린 LCP의 원인을 정확히 찾아내는 단계별 진단 가이드입니다.
• LCP 이미지 최적화: 이미지 포맷, 반응형 이미지, 압축, 모든 디바이스에 최적화된 이미지 제공에 대한 모든 것을 다룹니다.
• 리소스 로드 지연(Resource Load Delay): 사전 로딩(preloading), fetchpriority, CSS 배경 이미지 회피를 포함하여 브라우저가 LCP 리소스를 최대한 일찍 발견하도록 하는 방법을 다룹니다.
• 리소스 로드 시간(Resource Load Duration): 파일 크기 최적화, CDN 구성, 최신 압축 방식을 통해 LCP 리소스의 실제 다운로드 시간을 줄입니다.
• 요소 렌더링 지연(Element Render Delay): JavaScript와 CSS로 인한 메인 스레드 차단을 줄여 리소스 다운로드와 화면 렌더링 사이의 지연을 제거합니다.