Lighthouse LCP request discovery: 검사 항목과 해결 방법

LCP request discovery는 LCP 이미지에 대해 무엇을 알려줍니까?

LCP request discovery는 기존의 "Preload Largest Contentful Paint image"와 "Largest Contentful Paint image was lazily loaded"를 대체한 Lighthouse 13 인사이트입니다. 방문자가 기다리는 대형 사진인 LCP 이미지를 HTML에서 바로 발견할 수 있는지 점검합니다. 즉, HTML이 도착한 즉시 브라우저가 높은 우선순위로 이미지 다운로드를 시작할 수 있었는지를 확인합니다. 해결 방법은 명확합니다. loading="lazy" 없이 fetchpriority="high"를 적용하여 사진을 HTML 내 <img>로 배치하는 것입니다.

빠른 해결책만 확인하고 싶다면 WordPress, 페이지 빌더, Shopify 또는 Next.js 항목으로 바로 이동하십시오.

LCP request discovery의 세 가지 검사는 무엇을 의미합니까?

Lighthouse 13 및 PageSpeed Insights에서는 "LCP 이미지를 HTML에서 즉시 발견할 수 있게 설정하고 lazy loading을 방지하여 LCP를 최적화하십시오"라는 안내가 표시됩니다. 그 아래에는 각각 초록색 또는 빨간색으로 표시되는 세 가지 검사 항목이 있습니다.

대형 사진에 loading="lazy"가 적용된 호텔 홈페이지의 검사 결과입니다. DevTools 쓰로틀링을 적용한 Lighthouse 13.6 기준입니다.

• fetchpriority=high should be applied: 브라우저가 fetchpriority="high" 없이 LCP 이미지를 요청했습니다. 사진이 preload로 로드된 경우 이 항목은 "fetchpriority=high should be applied to the image preload request"로 표시되며, preload에도 해당 속성이 필요하다는 뜻입니다. 검사를 통과하면 "fetchpriority=high applied"로 바뀝니다.
• Request is discoverable in initial document: 사진 URL이 HTML 자체의 <img> 또는 preload에 포함되어 있어, preload scanner(HTML을 미리 읽는 브라우저 내부 기능)가 이를 바로 찾을 수 있는 상태입니다. 스타일시트에 지정된 배경 이미지, JavaScript로 슬라이드를 생성하는 슬라이더, URL을 data-src로 옮긴 lazy loading 스크립트 등은 이 검사를 빨간색으로 만듭니다.
• LCP resources shouldn’t use loading=lazy: 사진에 loading="lazy"가 지정되어 있어, 브라우저가 레이아웃 계산을 끝내고 해당 이미지가 화면에 보인다는 점을 확인한 뒤에야 요청을 보냅니다.

검사 항목 중 하나라도 빨간색이면 전체 안내가 빨간색으로 표시됩니다. 하단의 LCP element(HTML과 썸네일)는 Lighthouse가 모바일 화면에서 측정한 요소를 보여줍니다. Unscored는 이 항목 자체가 점수에 직접 반영되지는 않는다는 의미이지만, LCP는 Performance 점수의 25%를 차지하며 Google은 실제 방문자가 겪는 성능을 기준으로 순위를 매깁니다. 이 안내는 LCP 요소가 <img>, CSS 배경 이미지, 비디오 포스터와 같은 이미지일 때만 나타납니다.

LCP 이미지가 늦게 시작되면 왜 페이지가 느려집니까?

모바일 기기에서 방문자는 대형 사진이 들어갈 빈 공간을 둘러싼 헤드라인과 텍스트만을 1초 이상 보게 됩니다.

HTML이 다운로드되는 동안 Chrome의 preload scanner는 문서를 미리 읽어 내려가며 loading="lazy"가 없는 <img> src 또는 srcset의 모든 이미지를 요청합니다. 이것이 사진 로드가 시작될 수 있는 가장 빠른 시점입니다. 그 외의 모든 방식은 이보다 늦게 시작됩니다. 스타일시트에 있는 사진은 스타일시트 다운로드와 레이아웃 계산을 기다려야 합니다. style 속성에 있거나 loading="lazy"가 적용된 사진은 레이아웃 계산을 기다리는데, 이 단계는 모든 render blocking 스타일시트가 먼저 처리되어야 합니다. 슬라이더나 lazy loading 스크립트는 해당 스크립트가 다운로드되고 실행될 때까지 기다린 후에야 사진을 요청합니다.

이 대기 시간인 resource load delay는 대개 실제 다운로드보다 더 오래 걸립니다. LCP가 나쁜 사이트의 중앙값 기준을 보면, 이미지가 다운로드를 시작하기까지 1,290 ms를 대기하고 실제 다운로드에는 350 ms밖에 걸리지 않습니다(web.dev).

페이지 빌더로 구축한 WordPress 사이트 형식의 호텔 홈페이지에서 동일한 사진을 7가지 방식으로 배치한 뒤, 쓰로틀링이 적용된 모바일 환경에서 각각 로드해 보았습니다:

CPU 속도를 4배 낮춘 환경에서 Slow 4G 네트워크로 5회 측정한 중앙값(초)입니다. HTML은 매번 0.58초에 도착했습니다.

모바일 화면에 맞는 더 작은 파일로 교체할 수 없는 style 속성 방식을 제외하면, 모든 버전에서 동일한 63 kB 사진을 로드했습니다. 차이를 가른 것은 요청 시작 시점이었습니다. HTML에 직접 포함된 사진은 HTML이 도착하자마자 요청되었지만, 다른 방식들은 1.7초 시점의 첫 페인트나 2.4초 시점의 스크립트 실행까지 기다려야 했습니다.

동일하게 쓰로틀링된 모바일 환경에서 로드 시작 2.5초 시점의 호텔 페이지입니다.

fetchpriority="high"는 브라우저가 시작부터 이 이미지가 중요하다는 점을 인식하게 만들어 연결 대역폭을 우선 배분하도록 합니다. 수십 개의 스크립트와 스타일시트가 경쟁하는 복잡한 페이지에서 이는 LCP 속도를 눈에 띄게 개선합니다. Google은 Google Flights에서 2.6초에서 1.9초로 단축된 결과를 확인했습니다. 다만 이는 브라우저가 이미 발견한 사진에만 유효합니다. 스타일시트나 스크립트에 포함된 사진이라면 HTML 변경이 먼저 이루어져야 합니다.

이미지에 fetchpriority=high가 있는데도 왜 여전히 빨간색으로 표시됩니까?

이 검사는 LCP 이미지를 로드한 실제 네트워크 요청을 확인합니다. 로그아웃 상태에서 페이지 소스를 열어 사진의 파일명을 검색하십시오. 주된 원인은 다음과 같습니다(해결 방법은 아래 참조):

• 직접 작성하지 않은 preload. 테마, 호스트 또는 CDN이 Link 헤더나 103 Early Hints를 통해 사진 preload 요청을 보낼 수 있습니다. 캐시 플러그인이나 Next.js가 head 영역에 <link rel="preload">를 추가하기도 합니다. 헤더를 확인하려면 DevTools의 Network 패널을 열고 첫 번째 요청(페이지 자체)을 클릭한 뒤 Headers 항목을 확인하십시오.
• lazy loading 플러그인의 이미지 재작성. discoverable 검사도 함께 빨간색이라면 사진에 data-src나 data-lazy-src가 지정되어 있는지 확인하십시오. 플러그인이 URL을 해당 속성으로 이동시켜 스크립트가 나중에 사진을 요청하도록 만든 것입니다.
• WordPress가 다른 이미지에 속성을 지정한 경우. WordPress는 첫 화면의 첫 번째 대형 이미지(50,000 픽셀 이상)에 fetchpriority="high"를 부여합니다. 가령 600x200 픽셀처럼 두 배 크기로 업로드된 로고가 먼저 등장하면 해당 속성을 가로채 갑니다.
• Lighthouse가 다른 이미지를 측정한 경우. 안내문 하단의 LCP element에 측정된 이미지가 표시됩니다. 모바일에서는 별도의 모바일 hero 이미지가 사용되고 데스크톱 사진은 CSS로 숨겨졌는데, 정작 속성은 데스크톱 사진에만 적용되어 있는 경우가 이에 해당합니다.

lazy loading 스크립트가 적용되어 두 검사가 빨간색으로 표시된 호텔 페이지입니다. DevTools 쓰로틀링을 적용한 Lighthouse 13.6 기준입니다.

방문자는 LCP 이미지를 보기까지 얼마나 기다립니까?

실제 방문자가 얼마나 기다리는지는 field data에 나타납니다. CoreDash에서 모바일 LCP Breakdown을 열고 More dimensions 아래의 LCP Priority를 선택하십시오. 각 행은 LCP 이미지가 로드된 방식을 나타내며, p75 LCP가 하위 구간별로 나뉘어 표시됩니다. 초록색 구간은 HTML이 도착한 후 이미지 다운로드가 시작될 때까지의 대기 시간인 load delay입니다. URL별로 그룹화하면 이 대기 시간이 길게 나타나는 템플릿을 식별할 수 있습니다.

모바일 환경의 CoreDash(p75): 각 LCP Priority 행의 초록색 구간을 비교하십시오.

이미지 다운로드가 얼마나 늦게 시작되었는지 DevTools에서 어떻게 확인합니까?

Chrome DevTools의 Performance 패널에서 페이지의 trace를 기록한 뒤 Insights 사이드바에서 LCP request discovery를 여십시오. 페이지 빌더의 스타일시트에 사진이 배경으로 지정된 호텔 테스트 페이지의 경우, 이 인사이트는 HTML의 첫 번째 바이트인 "가장 빠른 시작 시점(earliest start point)"으로부터 얼마나 지난 후에 사진 요청이 시작되었는지를 보여줍니다. Network 트랙의 빗금 막대가 바로 그 대기 시간을 나타냅니다.

사진 요청이 스타일시트 로드 후에야 시작됩니다. Chrome DevTools Performance 패널, 모바일 쓰로틀링 환경.

Network 패널에서 사진 옆의 Initiator 열은 해당 사진을 요청한 파일을 표시합니다. 제때 시작된 경우에는 HTML이, 지연된 경우에는 스타일시트나 슬라이더 스크립트가 나타납니다.

LCP request discovery는 어떻게 해결합니까?

페이지 소스에서 사진의 파일명을 검색하십시오. <img>의 src나 srcset에 있다면 브라우저가 일찍 발견할 수 있습니다. 반면 data-src나 스타일시트에 있거나 소스에서 아예 찾을 수 없다면 구조를 변경해야 합니다. 모든 환경에서의 공통 목표는 단 하나입니다. 해당 LCP 이미지 하나에 대해 loading="lazy" 없이 fetchpriority="high"를 적용하여 HTML 내 <img>로 렌더링하는 것입니다. 직접 작성하지 않은 preload가 있다면 fetchpriority="high"를 추가하거나 아예 비활성화하십시오. 별도의 모바일 hero 이미지를 사용하는 대신 두 화면 모두 하나의 사진을 사용하도록 바꾸거나, 모바일용 <source>와 fetchpriority="high"가 지정된 <img>로 구성된 <picture> 태그 하나로 교체하십시오.

WordPress 및 lazy loading 플러그인

WordPress는 첫 번째 이미지들을 lazy loading에서 제외하고 첫 대형 이미지에 fetchpriority="high"를 적용합니다. 그럼에도 경고가 빨간색으로 뜬다면 보통 플러그인이 이 기본 동작을 덮어쓰고 있기 때문입니다:

• WP Rocket: 기본으로 활성화되는 Optimize Critical Images 기능은 실제 방문자 데이터를 통해 LCP 이미지를 학습하고, fetchpriority="high"를 적용해 미리 preload하며 LazyLoad 대상에서 제외합니다. 캐시가 재생성된 후 다시 테스트하십시오.
• Perfmatters: Exclude Leading Images 및 Preload Critical Images를 모바일 첫 화면에 표시되는 이미지 개수(대개 1개)로 설정하십시오.
• LiteSpeed Cache: 사진 파일명을 Lazy Load Image Excludes에 추가하거나 Viewport Images를 활성화하십시오.
• FlyingPress: 사진에 loading="eager"와 preload가 적용되어 있는지 확인하십시오. 되어 있지 않다면 lazy loading에서 제외하십시오.

로고는 실제로 표시되는 크기로 업로드하여 fetchpriority 속성이 본문 사진에 정상 적용되도록 하십시오. lazy loader는 하나만 유지하십시오. 그렇지 않으면 한 플러그인에서 제외해도 다른 플러그인에 의해 지연 로드될 수 있습니다. 커버(Cover) 블록의 '고정 배경(Fixed background)' 옵션은 사진을 style 속성의 배경 이미지로 변경하므로, 이 옵션을 꺼서 사진이 <img>로 출력되도록 하십시오. 필자의 플러그인 WP Core Web Vitals는 실제 방문자 데이터를 기반으로 화면 크기별 LCP 이미지를 파악해 가장 먼저 높은 우선순위로 로드합니다.

Elementor 및 기타 페이지 빌더

Elementor 컨테이너나 섹션의 배경으로 설정된 사진은 Elementor CSS로 처리되므로, 브라우저는 해당 CSS와 레이아웃 처리가 완료된 뒤에야 사진을 발견합니다. hero 사진에는 이미지 위젯을 사용하십시오(이미지 위젯을 사용한 Elementor hero). 그러면 'Optimized Image Loading'(설정 > 성능)이 WordPress 기본 방식과 동일하게 이를 처리합니다. 기본 활성화된 'Lazy Load Background Images' 옵션은 공지 바 아래에 위치한 배경 hero 이미지의 로드를 지연시킬 수 있습니다. 다른 페이지 빌더에서도 첫 번째 사진에는 반드시 이미지 요소를 사용하십시오.

슬라이더

첫 번째 슬라이드는 loading="lazy" 없이 fetchpriority="high"가 적용된 HTML 내 <img>여야 합니다. 나머지 슬라이드에는 loading="lazy"와 fetchpriority="low"를 적용합니다. JavaScript로 슬라이드를 렌더링하는 슬라이더는 스크립트 실행이 끝난 뒤에야 첫 슬라이드 요청을 시작합니다. 첫 번째 슬라이드를 HTML에 직접 출력하는 슬라이더를 사용하거나 모바일에서는 단일 사진을 표시하십시오. Elementor 이미지 캐러셀의 Lazyload 스위치는 모든 슬라이드 URL을 data-src로 변경하므로 이 옵션을 끄십시오.

Shopify

Dawn, Horizon 및 이를 기반으로 제작된 테마는 템플릿의 첫 번째 섹션에 있는 이미지에 fetchpriority="high"를 적용해 즉시 로드합니다. 따라서 배너나 슬라이드쇼를 첫 번째 섹션으로 배치하십시오. Dawn 상품 페이지에서는 메인 사진에 fetchpriority가 빠져 있습니다. snippets/product-thumbnail.liquid에서 lazy_load가 false인 경우(첫 번째 사진) image_tag에 fetchpriority: 'high'를 추가하십시오. 테마 업데이트 시 이 파일이 덮어쓰여질 수 있으므로 업데이트 후 해당 속성이 유지되는지 확인하십시오. 앱이 JavaScript로 생성하는 hero 이미지는 테마 설정과 상관없이 늦게 시작되므로 테마 섹션을 사용하십시오.

기타 테마의 경우 섹션 파일에서 loading: 'lazy' 또는 data-src가 지정된 lazyload 클래스를 찾고, 섹션 위치에 따라 우선순위를 동적으로 지정하십시오:

{%- liquid
  assign fetch_priority = 'auto'
  if section.index == 1
    assign fetch_priority = 'high'
  endif
-%}
{{ section.settings.image | image_url: width: 1600 | image_tag: widths: '750, 1100, 1600', sizes: '100vw', fetchpriority: fetch_priority }}

loading 파라미터가 없으면 image_tag는 네 번째 섹션부터 이미지를 lazy loading합니다.

CSS 배경 이미지

테마나 빌더에 이미지 옵션이 없다면 개발자의 수정 작업이 필요합니다. 먼저 배경 이미지를 <img>로 변경하십시오. 그러면 브라우저가 HTML에서 즉시 이미지를 발견할 수 있고, srcset을 통해 화면 크기별로 최적의 파일을 선택할 수 있습니다. object-fit 속성을 사용하면 기존 배경 이미지와 동일하게 여백을 채울 수 있습니다:

<section class="hero">
  <img class="hero-img" src="/wp-content/uploads/2026/10/terrace-1024.jpg"
    srcset="/wp-content/uploads/2026/10/terrace-768.jpg 768w, /wp-content/uploads/2026/10/terrace-1024.jpg 1024w, /wp-content/uploads/2026/10/terrace-1600.jpg 1600w"
    sizes="100vw" width="1600" height="1067" alt="Terrace above the sea" fetchpriority="high">
</section>

.hero { position: relative; }
.hero-img { position: absolute; inset: 0; width: 100%; height: 100%; object-fit: cover; }

배경 이미지를 그대로 유지해야 한다면, CSS의 미디어 쿼리와 fetchpriority="high"를 적용하여 화면 크기별로 CSS가 선택할 파일을 preload하십시오. 엉뚱한 파일에 preload를 걸면 사진이 중복 다운로드됩니다. 이 코드는 해당 페이지의 템플릿에만 추가해야 합니다. 768 px 미만에서 768 px 파일로 전환되는 CSS의 예시는 다음과 같습니다:

<link rel="preload" as="image" href="/wp-content/uploads/2026/10/terrace-768.jpg" media="(max-width: 767px)" fetchpriority="high">
<link rel="preload" as="image" href="/wp-content/uploads/2026/10/terrace-1600.jpg" media="(min-width: 768px)" fetchpriority="high">

Next.js, Astro 및 React

next/image는 기본적으로 lazy loading을 적용합니다. Next.js 15부터는 priority 속성(16 버전에서는 preload)이 이미지를 eager 방식으로 변경하고 preload하지만 fetchpriority는 적용하지 않으므로 검사 항목이 계속 빨간색으로 표시됩니다. priority를 쓰지 말고 두 속성을 직접 지정하십시오:

<Image src={hero} alt="Terrace above the sea" sizes="100vw" loading="eager" fetchPriority="high" />

Astro 5.10 이상에서는 <Image>의 priority prop이 두 속성을 모두 설정합니다. 브라우저에서 React가 렌더링하는 hero 이미지는 JavaScript 실행이 끝난 뒤에야 비로소 생성됩니다. <img>가 초기 HTML에 포함되도록 서버에서 렌더링하거나 페이지를 사전 렌더링(prerender)하십시오.

직접 수정할 수 없는 hero 이미지

사진을 동적으로 교체하는 A/B 테스트나 JavaScript로 hero를 구축하는 위젯은 이미지 로드를 지연시킵니다. 사진 URL이 고정되어 있다면 템플릿에 fetchpriority="high"를 적용한 preload를 추가해 조기에 로드시킬 수 있습니다. 서버 응답이 느리고 모든 화면 크기에서 동일한 이미지 파일을 사용한다면, 103 Early Hints를 통해 HTML이 도착하기도 전에 사진 다운로드를 시작할 수도 있습니다. 두 방법 모두 개발자의 작업이 필요합니다.

이제 LCP 이미지가 HTML과 함께 시작됩니까?

Lighthouse를 다시 실행하십시오. 세 검사 항목 모두 초록색이 표시되고 해당 사진이 LCP 요소로 지정될 것입니다. DevTools에서는 사진 요청이 HTML 바로 뒤에 시작됩니다. 검사를 통과했는데도 LCP가 여전히 느립니까? 그렇다면 LCP의 다른 구성 요소를 살펴보십시오. 느린 서버(time to first byte), 다운로드에 오랜 시간이 걸리는 사진(load duration), 혹은 페인트를 지연시키는 스타일시트와 스크립트(render delay)가 원인일 수 있습니다. 실제 방문자 데이터는 CoreDash에서 모바일 load delay를 확인하십시오. Search Console 데이터 갱신에는 최대 28일이 소요됩니다.

Core Web Vitals power hour는 이 글로 해결하기 어려운 까다로운 상황을 위한 서비스입니다. 자체 설정이 불가능한 페이지 빌더, 슬라이더, 앱에 의해 삽입된 사진이거나, 세 가지 검사를 모두 통과했음에도 모바일 LCP가 여전히 느린 경우가 이에 해당합니다. 실제 사이트의 trace를 HTML 수신부터 화면 표시까지 면밀히 추적하여 무엇이 로드를 가로막고 있는지 정확히 찾아냅니다.