LCP란 무엇인가

LCP(Largest Contentful Paint, 최대 콘텐츠 렌더링 시간)는 사용자가 페이지로 이동한 뒤 화면에 보이는 가장 큰 이미지나 텍스트 블록, 동영상이 그려질 때까지 걸린 시간을 재는 구글의 로딩 지표다.

코어 웹 바이탈 세 지표 중 로딩을 맡는다.

구글은 이 값에 이전 페이지를 떠나는 시간, 연결을 맺는 시간, 리디렉션 시간, 첫 바이트까지의 시간이 모두 포함된다고 명시한다. 실제 사용자 환경에서 잰 값과 실험실 값이 자주 어긋나는 이유가 여기에 있다 (web.dev, 최대 콘텐츠 렌더링 시간(LCP)).

같은 약자가 다른 뜻으로도 쓰인다. 구글 “LCP” 1페이지에는 리그 오브 레전드 아시아 태평양 리그(League of Legends Championship Pacific), 액정 폴리머 소재, 소아 고관절 질환(LCP병)이 웹 지표와 함께 뜬다.

이 문서는 웹 성능 지표 LCP만 다룬다.

LCP는 몇 초를 넘으면 나쁨인가?

2.5초 이하면 좋음, 4초를 넘으면 나쁨이고, 판정은 페이지 조회의 75번째 백분위수로 한다. 평균이 아니라 방문의 75%가 기준 안에 들어야 통과다.

판정LCP기준
좋음2.5초 이하75번째 백분위수
개선 필요2.5초 초과 4초 이하75번째 백분위수
나쁨4초 초과75번째 백분위수

기준값은 달성 가능성을 따져 정했다. 구글은 실적이 우수한 사이트들이 “1.5초 및 2초 기준점은 일관되게 달성할 수 없지만 2.5초 기준점은 일관되게 달성할 수 있는 것으로 나타났다”고 적었고, 4초 기준을 적용하면 휴대전화 출처의 약 26%가 나쁨으로 분류돼 목표 범위인 10~30%에 들어간다고 설명했다 (web.dev, Core Web Vitals 측정항목 기준 정의).

검색 순위와의 관계는 구글이 직접 선을 그었다. 코어 웹 바이탈은 순위 시스템에 쓰이지만, 좋은 점수가 상위 노출을 보장하지 않으며 “검색엔진 최적화만을 위해 Core Web Vitals에서 완벽한 점수를 얻으려고 하는 것은 시간 낭비일 수 있다”고 안내한다 (Google 검색 센터, 페이지 경험 이해하기).

웹 전체로 보면 통과율은 기기에 따라 갈린다. HTTP Archive 2024년 웹 연감 기준 데스크톱은 사이트의 72%, 휴대전화는 59%가 좋음 판정을 받았다 (HTTP Archive, Web Almanac 2024 Performance).

LCP는 어떤 요소를 재는가?

img 요소, svg 안의 image 요소, 포스터 이미지가 있는 video 요소, CSS url() 함수로 불러온 배경 이미지가 있는 요소, 텍스트 노드를 포함한 블록 요소만 후보가 된다. CSS 그라데이션 배경은 제외된다 (web.dev, LCP, 위 인용).

브라우저는 사용자가 콘텐츠로 여기지 않을 요소도 걸러낸다. 불투명도가 0인 요소, 화면 전체를 덮는 배경, 실제 콘텐츠를 가리는 자리 표시자 이미지가 그런 경우다.

가장 큰 요소는 로딩 도중 바뀔 수 있다. 브라우저는 첫 프레임을 그린 직후 가장 큰 요소를 보고하고, 이후 더 큰 요소가 렌더링될 때마다 다시 보고하며, 아직 로드되지 않은 이미지나 글꼴 차단 기간의 텍스트는 렌더링된 것으로 치지 않는다.

실제 웹에서 LCP 요소는 대부분 이미지다. 2024년 웹 연감은 데스크톱 페이지의 83.3%, 모바일 페이지의 73.3%에서 LCP 요소가 이미지이고, 텍스트는 각각 16.3%와 26.3%라고 집계했다 (HTTP Archive, 위 인용).

LCP 시간은 어떻게 쪼개지는가?

LCP는 서로 겹치지 않는 네 구간의 합이다. 구글은 이 구간별로 병목을 찾으라고 권한다 (web.dev, 최대 콘텐츠 렌더링 시간 최적화).

하위 구간잘 최적화된 페이지의 비중
첫 바이트까지의 시간 (TTFB)페이지 로드 시작부터 HTML 첫 바이트 수신까지약 40%
리소스 로드 지연TTFB부터 브라우저가 LCP 리소스를 요청하기 시작할 때까지10% 미만
리소스 로드 시간LCP 리소스 자체를 내려받는 시간약 40%
요소 렌더링 지연리소스 로드 완료부터 요소가 화면에 그려질 때까지10% 미만

이름에 “지연”이 붙은 두 구간은 0에 가깝게 만드는 것이 목표다. LCP 요소가 시스템 글꼴로 그린 텍스트라면 리소스 로드 지연과 로드 시간은 0이 된다.

크롬 사용자 데이터로 실측하면 이미지 다운로드는 병목이 아니었다. 구글이 2024년 8월 공개한 분석에서 LCP가 나쁜 출처의 대부분은 p75 LCP 시간의 10% 미만을 LCP 이미지 다운로드에 썼고, 가장 큰 구간은 TTFB였다 (web.dev, LCP 최적화 방법에 관한 일반적인 오해).

LCP 등급TTFB이미지 로드 지연이미지 로드 시간렌더링 지연
좋음600ms350ms160ms230ms
개선 필요1,360ms720ms270ms310ms
나쁨2,270ms1,290ms350ms360ms

웹 연감도 같은 결론이다. LCP가 나쁜 사이트는 TTFB에만 2.27초를 쓰는데 이는 좋음 기준 2.5초와 맞먹는 길이이고, LCP 등급과 무관하게 리소스 로드 지연이 로드 시간보다 길었다 (HTTP Archive, 위 인용).

LCP는 어떻게 측정하는가?

실제 사용자 데이터인 필드 값과 통제된 환경의 랩 값을 구분해서 본다. 순위 판정에 쓰이는 것은 필드 값이다.

  1. 서치 콘솔 Core Web Vitals 보고서. 크롬 사용자 환경 보고서(CrUX) 데이터를 URL 그룹 단위로 느림, 개선 필요, 빠름으로 나눠 보여주고, 색인된 URL만 표시한다 (Search Console 고객센터, Core Web Vitals 보고서).
  2. PageSpeed Insights. 같은 CrUX 필드 값과 Lighthouse 랩 값을 한 화면에 보여준다. 개별 URL을 즉시 검사할 때 쓴다.
  3. Chrome DevTools와 Lighthouse. 랩 환경에서 LCP 요소가 무엇인지, 네 하위 구간이 각각 몇 밀리초인지 확인한다.
  4. 자바스크립트 PerformanceObserver. largest-contentful-paint 항목을 구독하면 페이지 안에서 직접 LCP 값과 요소를 받을 수 있다 (web.dev, LCP, 위 인용).

가장 큰 요소가 가장 중요한 요소가 아닐 때는 Element Timing API로 원하는 요소의 렌더링 시점을 따로 잰다.

직접 재 보면 어디서 시간이 새는가?

서치폴라리스 페이지 두 개를 브라우저 성능 API로 재 봤다. 2026년 9월 19일 데스크톱 크로미움에서 각 1회 측정한 랩 값이다.

측정한 주소TTFBLCPLCP 요소리소스 로드 지연리소스 로드 시간렌더링 지연
/wiki/prompt-engineering/153ms436ms본문 문단 텍스트00283ms
/blog/rag/1,635ms1,956ms썸네일 이미지19ms261ms41ms

두 페이지 모두 2.5초 안에 들었지만 구성은 정반대다. 위키 페이지는 LCP 요소가 텍스트라 다운로드할 리소스가 없었고, 블로그 페이지는 LCP의 84%가 서버 응답을 기다리는 시간이었다.

블로그 페이지의 썸네일은 HTML에 바로 적혀 있어 TTFB 뒤 19밀리초 만에 요청이 시작됐고, 다운로드도 261밀리초로 짧았다. 이 페이지에서 이미지를 더 압축해도 LCP는 거의 줄지 않고, 줄이려면 TTFB를 손봐야 한다.

위 표는 1회 랩 측정이라 순위 판정과 무관하고, 병목이 어느 구간인지 찾는 용도로만 쓴다.

LCP는 어떻게 개선하는가?

네 하위 구간 중 가장 긴 곳부터 줄인다. 구글은 한 구간을 줄여도 시간이 다른 구간으로 옮겨 갈 수 있으니 네 구간을 모두 봐야 한다고 경고한다 (web.dev, LCP 최적화, 위 인용).

  1. TTFB를 줄인다. 사용자와 가까운 CDN, HTML 캐시, 서버 응답 최적화가 먼저다. 국내 사례로 TOAST UI는 서버 최적화, CDN, 자원 캐시, 서드파티 연결 선행을 첫 단계로 정리했다 (TOAST UI, LCP 최적화하기, 2020).
  2. 리소스 로드 지연을 없앤다. LCP 이미지 주소를 초기 HTML에 직접 적어 미리 로드 스캐너가 찾게 하고, 지연 로딩(loading=“lazy”)을 걸지 않으며, fetchpriority=“high”를 준다. 구글은 LCP 이미지인 페이지의 35%가 이미지 주소를 초기 HTML에서 찾을 수 없었고 fetchpriority를 쓰는 페이지는 15%에 그쳤다고 지적한다 (web.dev, Core Web Vitals를 개선하는 가장 효과적인 방법).
  3. 리소스 로드 시간을 줄인다. 이미지 크기 조정과 압축, WebP나 AVIF 포맷, HTML과 같은 출처에서 호스팅하기가 해당한다. 다만 위 실측처럼 이 구간은 보통 가장 짧다.
  4. 요소 렌더링 지연을 없앤다. 렌더링을 막는 CSS와 자바스크립트를 줄이고, 웹 글꼴 차단을 피하며, 클라이언트 렌더링에 기대는 페이지는 서버 사이드 렌더링이나 사전 렌더링으로 바꾼다.

하지 말아야 할 것도 분명하다. 국내 프런트엔드 블로그 yceffort는 LCP 요소를 지연 로드하지 말 것, 페이드 인 효과를 넣지 말 것, 외부 호스팅하지 말 것, 클라이언트에서 만들지 말 것을 든다 (yceffort, Largest Contentful Paint (LCP) 최적화하기, 2022).

효과는 매출로 확인된 바 있다. Vodafone은 방문 페이지 A/B 테스트에서 LCP를 31% 개선한 버전이 매출 8%, 리드 대비 방문율 15%, 장바구니 추가 후 방문 비율 11% 상승을 기록했다 (web.dev, Vodafone: LCP를 31% 개선하여 매출 8% 증대).

자주 묻는 질문

LCP 뜻은 무엇인가?

웹 성능에서는 최대 콘텐츠 렌더링 시간(Largest Contentful Paint)이고, 게임에서는 리그 오브 레전드 아시아 태평양 리그, 소재 공학에서는 액정 폴리머, 의학에서는 소아 고관절 질환의 약자다. 구글 검색량 기준 “LCP”는 월 5,400회, “LCP 뜻”은 110회다 (2026-09-19 서치폴라리스 실측, 구글 키워드 플래너).

LCP 측정 방법은 무엇인가?

필드 값은 서치 콘솔 Core Web Vitals 보고서와 PageSpeed Insights에서, 랩 값은 Lighthouse와 Chrome DevTools에서 본다. 페이지 안에서 직접 재려면 PerformanceObserver로 largest-contentful-paint 항목을 구독한다.

LCP 로드 지연은 어떻게 줄이는가?

LCP 이미지 주소를 초기 HTML에 적고, 지연 로딩을 풀고, fetchpriority=“high”를 지정한다. 웹 연감은 LCP 등급과 무관하게 로드 지연이 로드 시간보다 길다고 집계했으므로 압축보다 이 조치가 먼저다 (HTTP Archive, 위 인용).

React 앱의 LCP는 왜 느리고 어떻게 개선하는가?

클라이언트에서 자바스크립트가 실행된 뒤에야 LCP 요소가 만들어지면 리소스 로드 지연과 렌더링 지연이 함께 커진다. TOAST UI는 핵심 자바스크립트 최소화, 서버 측 렌더링, 사전 렌더링을 해법으로 정리했다 (TOAST UI, 위 인용).

참고 자료

우리 브랜드는 AI 답변에 나오고 있을까?

서치폴라리스가 AI 검색 가시성을 진단하고 GEO 실행까지 대행합니다.

GEO 최적화 서비스 보기