Chrome은 이미지 요청 우선순위를 어떻게 결정할까요?

DebugBear의 이미지 요청 우선순위 글을 바탕으로 정리하고, Chrome·web.dev 공식 자료로 동작과 실무 판단 기준을 보충했습니다. 이미지는 원래 글에서 소개한 관찰 예시이며, 현재 모든 Chrome 버전의 측정 결과를 뜻하지 않습니다.

LCP 이미지가 늦게 뜰 때 fetchpriority="high"를 붙이면 해결될까요? 그럴 수도 있지만 먼저 구분할 것이 있습니다. 이미지를 늦게 발견한 것인지, 발견하고도 요청이 밀린 것인지, 다운로드 후 화면에 그리는 일이 늦어진 것인지입니다.

fetchpriority는 상대적 요청 중요도를 알리고, preload는 리소스를 일찍 발견하게 합니다. 둘은 함께 쓸 수 있지만 같은 문제를 푸는 속성은 아닙니다.

Chrome의 기본 규칙을 읽는 법

이미지는 보통 Low 우선순위에서 시작합니다. 레이아웃 과정에서 뷰포트 안에 있다고 확인되면 High로 올라갈 수 있어요. Chrome 117부터는 처음 발견되는 큰 이미지 5개를 Medium으로 올려 초기 발견과 실제 중요도 판단 사이의 간격을 줄이는 휴리스틱도 도입했습니다.

상황 Chrome에서 기대할 수 있는 처리
기본 이미지 요청 보통 Low에서 시작
처음 5개 큰 이미지 후보 Medium으로 상향 가능
레이아웃에서 뷰포트 내 위치 확인 기본 설정 이미지는 High로 상향 가능
fetchpriority="high" 발견 시점부터 높은 상대적 중요도 전달
fetchpriority="low" 덜 중요한 리소스라는 힌트 전달

이것은 웹 표준이 모든 브라우저에 강제하는 스케줄 표가 아닙니다. fetchpriority 역시 최종 시작 시점이나 완료 순서를 보장하는 명령이 아니라 힌트예요. web.dev Fetch Priority 설명

이미지 기본 우선순위 Low 우선순위로 시작하는 요청의 관찰 예시

리소스 로딩 타임라인 초기 리소스와 이미지 요청의 타임라인 예시

초기 Tight Mode는 덜 중요한 요청의 동시 진행을 제한하는 Chrome의 스케줄링 단계입니다. 모든 이미지를 첫 렌더링 이후까지 차단한다는 뜻은 아니며, Chrome 117에서 도입된 동작에서는 해당 Medium 이미지 중 최대 2개를 병렬로 가져올 수 있습니다.

회색 대기 구간도 무조건 “우선순위가 낮아서”라고 해석하면 안 됩니다. DevTools Timing에는 Queueing, Stalled, DNS, 연결, 서버 응답 대기 등 서로 다른 구간이 있습니다. 실제로 어느 구간이 길었는지 확인해야 해요. Chrome DevTools 타이밍 설명

‘큰 이미지’ 규칙은 최적화 목표가 아니다

공식 설명의 큰 이미지 기준은 면적 10,000px² 초과입니다. 초기에는 HTML에서 알 수 있는 크기 등을 사용하고, 크기가 알려지지 않은 이미지도 후보가 될 수 있습니다. 이 조건은 첫 5개라는 제한이나 명시적인 우선순위 설정과 함께 적용됩니다. 구체적인 크기 판단은 Chromium 구현 사항입니다. Chromium의 해당 우선순위 계산 구현

중간 우선순위 이미지 처음 5개의 큰 이미지가 Medium으로 설정되는 예시

크기 미지정 이미지 크기가 알려지지 않은 이미지의 관찰 예시

작은 크기 이미지 작은 이미지가 Low로 시작하는 관찰 예시

1
2
3
4
5

<!-- 크기 정보로 큰 이미지 후보임을 판단할 수 있는 예시 -->
<img src="banner.jpg" alt="행사 안내" width="200" height="100">

<!-- 작은 이미지의 예시 -->
<img src="icon.jpg" alt="" width="10" height="10">

여기서 width와 height를 지우거나 실제와 다르게 지정해 우선순위를 유도하는 것은 좋은 최적화가 아닙니다. 크기는 올바른 비율과 레이아웃 공간 확보를 위해 제공하고, 중요도는 해당 힌트로 전달하는 편이 명확합니다. web.dev 레이아웃 이동과 이미지 크기

먼저 LCP 후보 하나의 요청을 추적한다

LCP는 다운로드 완료 시각이 아니라 큰 콘텐츠가 화면에 표시되는 시점과 관련 있습니다. 이미지가 LCP 요소인 경우 시간을 다음처럼 나눠볼 수 있어요. web.dev LCP 최적화

긴 구간 먼저 확인할 원인 개입 후보
HTML 첫 바이트까지 서버 응답, 리다이렉트, 네트워크 응답·캐시 경로 개선
HTML 응답 후 이미지 요청 시작까지 늦은 발견, 지연 로딩, 리소스 경쟁 초기 HTML 노출, 필요한 preload, 우선순위
이미지 요청 후 다운로드 완료까지 큰 전송량, 서버·네트워크 적절한 크기·포맷·캐시
다운로드 후 실제 표시까지 숨겨진 요소, 렌더링·스크립트 작업 표시 조건과 렌더링 병목 수정

모바일에서는 데스크톱과 다른 이미지나 텍스트가 LCP가 될 수도 있습니다. 히어로 이미지처럼 보인다는 이유만으로 대상이라고 가정하지 말고 Performance 패널에서 확인합니다.

우선순위 변경 레이아웃 후 이미지 우선순위가 바뀌는 예시. FCP 이후에만 일어난다는 규칙은 아닙니다.

상황에 맞게 속성을 조합하기

초기 HTML에 이미 있는 핵심 이미지

1
2
3
4
5
6
7

<img
  src="hero.jpg"
  alt="서명 진행 상황을 보여주는 제품 화면"
  width="1200"
  height="600"
  fetchpriority="high"
>

초기 HTML에서 곧바로 발견할 수 있다면 먼저 이 정도로 시작할 수 있습니다. LCP 후보 이미지에는 loading="lazy"를 붙이지 않는 편이 좋습니다. fetchpriority="high"를 붙여도 lazy loading의 발견·요청 지연을 대신 해제하지는 않아요. web.dev LCP 이미지 발견과 우선순위

fetchpriority high 중요한 이미지에 high 힌트를 적용한 요청 예시

CSS 배경 등 늦게 발견되는 핵심 이미지

1
2
3
4
5
6
7
8

<head>
  <link
    rel="preload"
    as="image"
    href="hero-bg.jpg"
    fetchpriority="high"
  >
</head>

CSS를 받아 해석해야만 URL을 아는 배경 이미지라면 preload가 발견 시점을 앞당길 수 있습니다. 실제 CSS에서 같은 리소스를 사용해야 하며, 페이지에서 쓰지 않는 이미지를 미리 가져오면 다른 요청과 경쟁만 늘어납니다.

프리로드 우선순위 이미지 preload가 있다는 이유만으로 High가 되지는 않는 예시

반응형 이미지라면 preload와 실제 srcset·sizes의 선택 결과도 맞아야 합니다. 그렇지 않으면 미리 받은 파일과 실제 표시할 파일이 달라질 수 있어요. 무조건 preload를 추가하기보다 Network에서 어떤 URL을 몇 번 받았는지 확인하는 것이 좋습니다. web.dev 반응형 이미지 preload

초기 화면에서 중요하지 않은 이미지

1
2
3
4
5
6
7
8

<img
  src="footer-decoration.jpg"
  alt=""
  width="800"
  height="400"
  loading="lazy"
  fetchpriority="low"
>

이 예시의 이미지는 순수 장식이므로 빈 대체 텍스트를 썼습니다. loading은 언제 불러올지, fetchpriority는 불러올 때 얼마나 중요한지에 대한 서로 다른 힌트입니다. 모든 하단 이미지에 두 속성이 반드시 필요한 것은 아니에요.

fetchpriority low 낮은 상대적 우선순위를 명시한 예시

변경 후 무엇이 좋아졌는지 확인하기

Network에서 Priority 열을 켜고 큰 요청 행이나 툴팁으로 초기·최종 우선순위를 확인합니다. 동일한 뷰포트, 네트워크 제한, 캐시 조건으로 변경 전후를 여러 번 비교하면 우연한 차이를 줄일 수 있어요. web.dev DevTools 우선순위 확인

판단 기준은 Priority가 High로 바뀌었는가에서 끝나지 않습니다. 해당 이미지의 요청 시작과 실제 LCP가 앞당겨졌는지, CSS·폰트·다른 핵심 콘텐츠가 그 대신 늦어지지 않았는지 봐야 합니다. 다운로드가 이미 충분히 빠른데 화면 표시를 스크립트가 막고 있다면 우선순위를 더 높여도 효과가 작습니다.

실제 사용자 데이터가 있다면 기기와 페이지 유형별 LCP 분포도 함께 확인합니다. 로컬에서 한 번 빨라진 결과와 실제 사용자 경험의 개선은 구분해야 해요.

실무에서 가져갈 원칙은 간단합니다. 핵심 리소스를 일찍 발견하게 하고, 필요한 대상에만 높은 중요도를 알리고, 나머지 병목은 해당 구간에서 해결한다. high를 많이 붙이는 것이 아니라 브라우저가 모르는 페이지의 의도를 정확히 알려주는 것이 목적입니다.