AI 에이전트로 LCP 수정하기: 필드 데이터에서 코드 수정까지
CWV Superpowers를 사용하는 완벽한 LCP 진단 워크플로: 필드 데이터에서 병목 단계를 식별하는 것부터 특정 코드 변경까지.
느린 Largest Contentful Paint에는 네 가지 잠재적 원인이 있습니다. 필드 데이터에 연결된 AI 에이전트는 실제 병목 현상이 무엇인지 식별하고 Chrome에서 이를 추적하며 수정 사항을 생성할 수 있습니다. 이것은 CWV Superpowers를 사용하는 전체 LCP 진단 워크플로입니다.
최종 검토자: Arjen Karel, 2026년 3월
Table of Contents!
네 가지 LCP 단계
Google은 LCP를 네 가지 단계로 나눕니다. 각 단계에는 다른 원인과 다른 수정 방법이 있습니다.
TTFB는 탐색 시작부터 HTML 응답의 첫 번째 바이트까지 걸리는 시간입니다. 느린 서버, CDN 누락, 캐싱 없음, 긴 데이터베이스 쿼리 등이 원인입니다. TTFB가 병목 현상인 경우 서버를 수정할 때까지 다른 것은 중요하지 않습니다.
Load Delay는 HTML을 수신하는 것과 브라우저가 LCP 리소스를 요청하는 것 사이의 간격입니다. 이것은 발견 문제입니다. LCP 이미지가 CSS 백그라운드에 있거나, JavaScript를 통해 로드되거나, 리디렉션 체인 뒤에 묻혀 있는 경우, 브라우저는 그것이 필요하다는 것을 발견할 때까지 가져오기를 시작할 수 없습니다.
Load Time은 요청 후 LCP 리소스를 다운로드하는 데 걸리는 시간입니다. 큰 이미지, 압축 누락, 느린 CDN, 반응형 srcset 없음 등이 원인입니다.
Render Delay는 리소스 다운로드가 완료된 후 브라우저가 실제로 화면에 페인팅하는 것 사이의 간격입니다. 렌더링 차단 스크립트, 웹 폰트 로딩, 또는 LCP 요소가 표시되기 전에 DOM을 조작하는 JavaScript 등이 원인입니다.
비례 추론으로 병목 현상 찾기
Core Web Vitals에 대한 공개 데이터는 Core Web Vitals의 실제 문제를 찾는 데 충분하지 않습니다. Lighthouse는 시뮬레이션된 Moto G Power에서 합성 테스트를 실행하고 하나의 LCP 시간을 보고합니다. CrUX는 28일간의 실제 Chrome 데이터를 URL당 단일 p75 값으로 집계합니다. 둘 다 무엇을 수정해야 할지 알려주지 않습니다.
더 안 좋은 점은: 어느 쪽도 의미 있게 세분화할 수 없다는 것입니다. CrUX는 캐시된 페이지 뷰, 캐시되지 않은 페이지 뷰, 새로운 방문 및 페이지 새로 고침을 하나의 p75로 결합합니다. 이들은 별개의 문제로 다뤄져야 합니다. 캐시된 페이지 뷰는 오래된 캐시 검증으로 인한 TTFB 병목 현상이 있을 수 있습니다. 페이지 새로 고침은 브라우저가 매 방문 시 LCP 이미지를 늦게 찾는 리소스 발견 문제를 숨길 수 있습니다. 혼합된 p75는 이 두 가지를 모두 가립니다.
CrUX는 2025년에 LCP 하위 파트를 추가했으며, 이는 도움이 됩니다. 그러나 여전히 요소, 뷰포트 또는 필터링이 없는 28일 p75입니다. "지난달 이 URL의 모든 방문자"에 대한 단계 비율을 봅니다. 문제가 있는 특정 디바이스 유형, 국가 또는 페이지 템플릿에서 무슨 일이 일어나고 있는지 볼 수 없습니다.
RUM 데이터는 이 모든 차원으로 세분화됩니다. CWV Superpowers는 세분화된 데이터를 쿼리하고 비례적으로 해석합니다. 병목 현상은 실패하는 특정 세그먼트의 전체 시간 중 가장 큰 점유율을 차지하는 단계입니다. 무의미한 평균이나 Lighthouse 시뮬레이션이 아닙니다. 실제 데이터입니다!
구체적인 예시. 모바일 제품 페이지에서 LCP가 3,800ms입니다. 캐시된 페이지 뷰의 첫 방문자에 대한 실제 사용자의 세부 정보:
- TTFB: 600ms (28.7%)
- Load Delay: 1,900ms (44.6%)
- Load Time: 800ms (19.3%)
- Render Delay: 500ms (7.4%)
Load Delay가 명백한 병목 현상입니다. 전체 LCP 시간의 절반이 브라우저가 이미지가 존재한다는 것을 발견하기 위해 기다리는 시간입니다. Lighthouse, CrUX 또는 수동 조사는 이 문제를 일으킨 방문자 특성의 정확한 조합을 찾는 데 정말 어려움을 겪었을 것입니다.
이 접근 방식에 대한 전체 설명은 웹 성능을 위한 비례 추론을 참조하세요.
브라우저가 이미지를 늦게 찾는 이유
Load Delay는 제가 보는 가장 일반적인 LCP 병목 현상입니다. 브라우저가 HTML을 수신했지만 훨씬 나중에까지 히어로 이미지가 필요하다는 것을 알지 못했음을 의미합니다.
세 가지 일반적인 원인이 있습니다. 이미지가 미리 로드 스캐너에 보이지 않는 CSS 백그라운드 이미지입니다. 이미지 URL이 JavaScript로 구성됩니다. 또는 이미지가 기술적으로 HTML에 있지만 브라우저가 너무 성급하게 따르는 지연 로딩 속성을 가지고 있습니다.
Chrome 추적을 엽니다. HTML 도착과 이미지 요청 발생 사이의 네트워크 워터폴에 큰 간격이 보일 것입니다. 그 간격이 바로 Load Delay입니다. 제가 감사하는 사이트들에서 모바일의 경우 1,500에서 2,500ms입니다. 브라우저가 HTML을 가지고 있지만 히어로 이미지가 필요하다는 것을 전혀 알지 못하는 전체 2초입니다.
에이전트도 동일한 간격을 봅니다. 워터폴을 CoreDash 세부 정보와 일치시키고 이미지가 왜 늦었는지 정확히 알려줍니다.
진단 모습
출력 모습은 다음과 같습니다:
AI 원인 식별: /product/running-shoes-42의 LCP 이미지 div.hero-banner > img.product-main이 미리 로드 힌트가 없고 fetchpriority="high"가 없기 때문에 1,980ms 늦게 발견되었습니다. CoreDash 데이터: 모바일에서 LCP 3,820ms(나쁨), p75. Load Delay가 전체의 52%로 병목 현상입니다. Chrome 추적 확인: HTML 첫 번째 바이트와 네트워크 워터폴의 이미지 요청 사이의 1,940ms 간격.
이것이 전체 진단입니다. 에이전트가 파일을 찾고, diff를 작성했습니다. 당신은 그것을 확인하고 배포합니다.
단계별 일반적인 수정 사항
Load Delay: <head>에 미리 로드 힌트를 추가합니다. LCP 이미지에 fetchpriority="high"를 설정합니다. 이미지를 CSS 백그라운드나 JavaScript에서 미리 로드 스캐너가 찾을 수 있는 HTML로 이동합니다.
Load Time: WebP 또는 AVIF로 변환합니다. 이미지 크기를 실제 디스플레이 크기에 맞게 줄입니다. 모바일 사용자가 데스크톱 크기의 이미지를 다운로드하지 않도록 반응형 srcset을 추가합니다. Core Web Vitals를 위한 이미지 최적화를 참조하세요.
Render Delay: LCP 요소가 표시되기 전에 실행되는 렌더링 차단 스크립트를 제거하거나 지연시킵니다. LCP 텍스트 요소에 영향을 주는 웹 폰트의 font-display를 확인합니다. 103 Early Hints를 사용하여 CSS를 더 일찍 전달합니다.
TTFB: CDN을 추가합니다. 서버 측 캐싱을 활성화합니다. 데이터베이스 쿼리 시간을 줄입니다. 103 Early Hints를 사용하여 서버가 아직 응답을 생성하는 동안 브라우저가 리소스 미리 로드를 시작할 수 있게 합니다.
수정 사항 확인
배포 후, 동일한 페이지 및 디바이스 세그먼트에 대한 CoreDash 필드 데이터를 쿼리합니다. 실제 사용자가 페이지를 로드함에 따라 필드 데이터가 업데이트됩니다. 저는 보통 트래픽 발생 후 24~48시간 뒤에 확인합니다. LCP p75가 떨어져야 하고, 병목 단계 분포가 이동해야 합니다.
이것이 단순히 숫자를 고치는 것과 경험을 고치는 것의 차이입니다. CrUX 업데이트를 위해 28일을 기다리거나 Lighthouse를 다시 실행하고 점수가 올라갔기를 바라지 않습니다. 문제가 있었던 디바이스 및 네트워크 세그먼트에서 실제 사용자 수치의 개선을 봅니다.
INP 진단(실험실에서 측정할 수 없는 지표)의 경우에도 동일한 세분화 워크플로가 적용됩니다. 세 가지 Core Web Vitals 모두에 걸쳐 AI 에이전트가 실험실 데이터 대비 필드 데이터를 어떻게 사용하는지에 대한 더 넓은 시각은 AI 에이전트 Core Web Vitals 디버깅을 참조하세요.
