최대 콘텐츠풀 페인트(LCP) 최적화: LCP를 2.5초 이내로 낮추세요. 이미지 최적화와 TTFB 개선 가이드입니다.

요약
최대 콘텐츠풀 페인트(Largest Contentful Paint, LCP)는 페이지에서 가장 큰 콘텐츠 요소가 화면에 표시되기까지 걸리는 시간을 측정하며, Google의 목표치는 2.5초 미만입니다.
더 알아보고 싶다면 물어보세요
LCP는 핵심적인 사용자 경험 지표이자 Google 순위 요인입니다. 사용자가 페이지에 접속할 때 전체 페이지 로드 시간에는 관심이 없습니다. 사용자가 신경 쓰는 것은 주요 콘텐츠를 보고 읽거나 상호작용을 시작할 수 있는 시점입니다. LCP는 바로 그 순간, 즉 가장 큰 콘텐츠 요소가 표시되는 시점을 측정합니다. LCP를 잘 관리하면 페이지가 빠르게 느껴지고, 그렇지 못하면 다른 지표가 괜찮더라도 페이지가 느리게 느껴집니다.
LCP 최적화에는 세 가지 접근이 필요합니다. 서버 응답 시간(TTFB) 개선, 렌더링 차단 리소스 제거, 이미지 최적화입니다. 각 접근은 서로 다른 LCP 병목을 해결하며, 이를 함께 적용하면 극적인 개선 효과를 얻을 수 있습니다.
최대 콘텐츠풀 페인트(LCP)는 페이지에서 화면에 보이는 가장 큰 콘텐츠 요소의 렌더링 시간입니다. 이는 큰 이미지, 동영상, 헤드라인 또는 텍스트 블록일 수 있습니다. LCP는 사용자가 페이지로 이동한 시점부터 해당 요소가 표시될 때까지를 측정합니다. Google의 LCP 문서에서 자세한 기술 정보와 최적화 전략을 확인할 수 있습니다.
LCP는 합격/불합격으로 나뉘는 이분법적 지표가 아니라 연속적인 점수입니다. Google은 LCP 2.5초 미만을 "좋음", 2.5-4초를 개선 필요, 4초 초과를 나쁨으로 정의합니다. 사용자는 LCP가 2초 미만인 페이지를 매우 빠르다고 느낍니다. LCP가 3-4초인 페이지는 눈에 띄게 느리게 느껴지며, LCP가 5초를 넘는 페이지는 이탈하는 경우가 많습니다.
LCP는 페이지 로드 중 더 큰 콘텐츠 요소가 나타나면 바뀝니다. 큰 이미지가 3초 시점에 로드되면 LCP는 1초에서 3초로 뛰어오릅니다. 이 점이 중요합니다. 초기 페인트 시간만 최적화해서는 안 되며, 모든 큰 콘텐츠 요소가 빠르게 로드되도록 해야 합니다.
첫 바이트까지의 시간(Time to First Byte, TTFB)은 탐색 시작부터 서버가 HTML 문서의 첫 바이트를 반환할 때까지의 시간입니다. TTFB는 LCP의 하한선을 결정합니다. TTFB가 2초라면 브라우저가 아직 HTML조차 받지 못했으므로 LCP는 2초보다 나아질 수 없습니다. TTFB 단축은 LCP 단축의 전제 조건입니다.
좋은 TTFB는 600밀리초 미만입니다. 600-1800ms의 TTFB는 개선이 필요하며, 1800ms를 넘으면 나쁨입니다. TTFB가 느리다면 먼저 서버 최적화에 집중하세요. 아무리 프런트엔드를 최적화해도 느린 서버를 만회할 수는 없습니다.
TTFB가 느려지는 흔한 원인: 비효율적인 백엔드 코드, 데이터베이스 쿼리, 서버 과부하입니다. 느린 호스팅도 높은 TTFB의 원인이 됩니다. 공유 호스팅은 매우 느린 경우가 많으므로, 더 나은 성능을 위해 VPS나 클라우드 호스팅으로 업그레이드하세요. 사용자와 가까운 서버에서 콘텐츠를 제공하는 CDN을 사용하면 TTFB를 줄일 수 있습니다.
PageSpeed Insights는 "서버 응답 시간(Server response time)" 항목에서 TTFB를 보여 줍니다. TTFB가 병목이라면 우선 개선 항목으로 강조 표시됩니다.
LCP는 페이지에서 무엇이 가장 큰 콘텐츠 요소인지에 따라 달라집니다. 블로그 글에서는 큰 히어로 이미지가, 상품 페이지에서는 상품 사진이, 뉴스 사이트에서는 기사 헤드라인이 가장 큰 요소일 수 있습니다. LCP 요소를 식별하는 것이 최적화의 첫 단계입니다.
Chrome DevTools로 LCP 요소를 식별하세요. DevTools를 열고 Performance 탭으로 이동해 녹화를 시작한 뒤 페이지를 새로고침합니다. Performance 기록에서 "Largest Contentful Paint" 표시를 찾고, 그 위에 마우스를 올리면 어떤 요소가 LCP를 발생시켰는지 확인할 수 있습니다. 요소를 파악했다면 이를 최적화하세요.
LCP 요소는 이미지인 경우가 많습니다. 이미지는 용량이 크고 HTML 파싱 이후에 로드되기 때문입니다. 대부분의 사이트에서 이미지 로딩 최적화가 LCP에 가장 큰 영향을 줍니다. 스크롤해야 보이는 영역(below-the-fold)의 이미지는 지연 로딩(lazy loading)하여 첫 화면(above-the-fold) 콘텐츠의 LCP를 앞당길 수 있습니다.
미리 로드(preload)는 렌더링에 필요해지기 전에 리소스 다운로드를 일찍 시작하도록 브라우저에 지시하는 것입니다. HTML head의 `` 태그를 사용해 LCP 이미지나 기타 중요 리소스를 미리 로드하세요. 이는 브라우저에 "이 리소스를 즉시 다운로드하라"고 알려 줍니다.
예: ``는 CSS 파싱을 기다리지 않고 히어로 이미지 다운로드를 즉시 시작하도록 브라우저에 지시합니다. 리소스 크기에 따라 LCP를 100-500ms 줄일 수 있습니다.
미리 로드는 신중하게 사용하세요. 너무 많은 리소스를 미리 로드하면 대역폭이 낭비됩니다. 가장 중요한 리소스(히어로 이미지, 핵심 폰트, 필수 CSS)만 미리 로드하세요. Google의 Core Web Vitals 최적화 가이드에서 미리 로드 모범 사례를 설명합니다.
LCP 요소가 이미지라면 이미지 파일 크기와 로딩 전략을 최적화하세요. 세 가지 방법이 있습니다.
이미지를 압축하세요. TinyPNG, ImageOptim, Squoosh 같은 도구로 품질 손실 없이 압축합니다. JPEG 압축으로 파일 크기를 10-40배 줄일 수 있습니다. 4G 네트워크에서는 이미지 크기 100KB마다 LCP가 100-200ms 늘어납니다. 압축은 ROI가 높은 작업입니다.
최신 포맷을 사용하세요. WebP는 JPEG보다 25-35% 작고, AVIF는 그보다 더 작습니다. HTML `
이미지 크기를 지정하세요. width와 height 속성을 포함하면 레이아웃 이동을 방지하고, 이미지가 로드되기 전에 브라우저가 공간을 확보할 수 있습니다. LCP를 직접 개선하지는 않지만, 또 다른 Core Web Vitals 지표인 누적 레이아웃 이동(CLS)을 개선합니다.
렌더링 차단 CSS는 CSS가 다운로드되고 파싱될 때까지 브라우저가 페이지를 렌더링하지 못하게 합니다. 큰 CSS 파일은 렌더링을 지연시킵니다. 핵심 CSS는 인라인으로 넣고 나머지는 지연 로드하여 렌더링 차단 CSS를 최소화하세요.
핵심 CSS(Critical CSS)는 첫 화면(above-the-fold) 콘텐츠에 필요한 CSS입니다. 이 CSS를 `
출처
아닙니다. LCP는 주요 콘텐츠가 표시되는 시점을 측정하고, 로드 시간은 모든 리소스의 다운로드가 끝나는 시점을 측정합니다. 페이지의 LCP는 좋아도 전체 로드는 느릴 수 있습니다. 전체 로드 시간보다 LCP가 더 중요합니다.
주요 원인은 세 가지입니다. 느린 TTFB, 렌더링 차단 CSS/JavaScript, 최적화되지 않은 이미지입니다. 서버 성능을 개선하거나 CDN을 사용해 TTFB를 개선하세요. 중요하지 않은 JavaScript는 지연 로드하고 이미지는 압축하세요.
이미지는 가장 큰 콘텐츠 요소인 경우가 많아 LCP를 결정합니다. 이미지 파일 크기를 줄이는 것이 가장 큰 효과를 냅니다. 스크롤해야 보이는 영역의 이미지를 지연 로딩하면 초기 LCP가 개선됩니다.
먼저 Sorank를 경험한 사람들
