LCP 하위 구간

LCP(Largest Contentful Paint, Core Web Vitals)를 순서대로 이어지는 네 구간으로 나눈 것. 네 구간을 더하면 LCP가 된다. LCP 숫자 하나만으로는 무엇을 고칠지 알 수 없어서, web.dev는 이 분해로 원인을 찾으라고 권한다.

LCP 요소가 시스템 폰트로 그린 텍스트처럼 리소스를 받을 필요가 없으면, Resource Load Delay와 Resource Load Duration은 0이다.

예시로 읽기

LCP 이미지를 스크립트가 나중에 <img>로 넣는 페이지를 생각해 보자.

0ms      페이지 이동 시작
600ms    HTML 첫 바이트 도착             TTFB                   = 600ms
1500ms   hero.jpg 요청 시작             Resource Load Delay    = 900ms
1800ms   hero.jpg 다운로드 끝           Resource Load Duration = 300ms
2000ms   이미지가 화면에 그려짐          Element Render Delay   = 200ms
                                       LCP                    = 2000ms

다운로드 자체는 300ms뿐인데, HTML을 받고도 이미지를 요청하기까지 900ms를 흘려보냈다. 이미지를 압축하는 것보다 HTML에 <img src>를 직접 쓰는 편이 효과가 크다.

잘 최적화된 페이지의 비율

두 "지연" 구간은 0에 가까울수록 좋다. web.dev는 이 비율을 가이드로만 보고 밀리초 목표로 바꾸지 말라고 한다. 위 예시는 지연 구간이 55%라서 먼저 지연을 줄여야 한다.

구간별 원인

• TTFB: 프론트엔드에서는 첫 바이트가 오기 전까지 아무것도 할 수 없다. 광고·단축 링크를 거치며 리다이렉트가 여러 번 쌓이거나, 분석용 URL 파라미터 때문에 CDN(Content Delivery Network) 엣지 캐시를 놓치고 원 서버까지 가는 경우가 흔한 원인이다. 연결 준비 비용도 여기에 들어간다(RTT와 연결 준비 비용)
• Resource Load Delay: 리소스를 늦게 발견하거나 낮은 우선순위로 요청한다. 스크립트가 <img>를 넣거나, 지연 로딩 라이브러리가 주소를 data-src에 숨기거나, CSS 배경 이미지라서 프리로드 스캐너가 못 찾는 경우다. LCP 이미지에 loading="lazy"를 걸면 안 된다(이미지 loading 속성). 브라우저가 중요하다고 판단하지 못하면 fetchpriority로 알린다. 다른 출처의 리소스는 그 출처에 새로 연결하는 시간까지 든다
• Resource Load Duration: 파일 크기, 서버까지의 거리, 동시에 받는 다른 리소스와의 대역폭 경합(HOL 블로킹과 HTTP/2 멀티플렉싱). 이미지 크기·포맷을 줄이고 CDN을 쓴다
• Element Render Delay: 리소스는 받았는데 그리지 못한다. <head>의 렌더링 차단 CSS나 동기 스크립트, LCP 리소스보다 늦게 끝나는 큰 스타일시트, 아직 DOM에 없는 요소(JS 대기), A/B 테스트 라이브러리가 숨긴 요소, 메인 스레드의 긴 태스크(이벤트 루프)가 원인이다 → 브라우저 렌더링 파이프라인

정리하면 Resource Load Delay는 "요청을 늦게 시작한 시간", Resource Load Duration은 "받는 데 걸린 시간", Element Render Delay는 "받고 나서 그리기까지 늦은 시간"이다. 이미지가 늦게 뜬다고 바로 이미지 압축부터 하지 않고, 어느 구간이 긴지 먼저 본다.

출처: web.dev — Optimize Largest Contentful Paint: LCP breakdown · web.dev — Optimize LCP: Optimal subpart times · web.dev — Optimize LCP: How to optimize each part