HTML fetchpriority 속성 기준 정리

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

fetchpriority는 브라우저가 외부 리소스를 가져올 때 상대적인 우선순위를 판단하도록 주는 HTML 힌트입니다. 이미지를 빨리 받게 하거나, 덜 중요한 스크립트의 우선순위를 낮추고 싶을 때 검토합니다. 다만 이 값은 강제 명령이 아니라 힌트이므로 실제 처리 방식은 브라우저 구현에 따라 달라질 수 있습니다.

2026년 8월 3일 기준 WHATWG HTML Standard와 MDN 문서에 따르면 fetchpriority는 img, link, script 요소에서 사용되는 속성입니다. 값은 high, low, auto 세 가지이며, 생략하거나 잘못된 값을 넣으면 auto 상태로 처리됩니다.

fetchpriority는 무엇을 바꾸나

브라우저는 문서를 파싱하면서 이미지, CSS, JavaScript, font 같은 리소스를 여러 개 요청합니다. 이때 브라우저는 리소스 종류, 발견 시점, 렌더링 영향 등을 보고 내부 우선순위를 정합니다. fetchpriority는 이 내부 판단에 개발자가 추가 신호를 주는 역할을 합니다.

중요한 점은 같은 목적지의 리소스 안에서 상대적인 우선순위를 알려준다는 것입니다. high를 붙였다고 네트워크가 무조건 빨라지는 것은 아니며, low를 붙였다고 요청이 취소되는 것도 아닙니다. 브라우저가 리소스 스케줄링을 할 때 참고하는 신호로 이해하는 편이 정확합니다.

어떤 요소에 붙일 수 있나

HTML 문서에서는 주로 다음 세 요소에서 사용합니다.

요소	대표 사용처	주의할 점
img	초기 화면의 핵심 이미지, LCP 후보 이미지	모든 이미지에 high를 붙이면 구분 신호가 약해질 수 있습니다.
link	rel="preload"로 미리 가져오는 리소스	as, crossorigin, 실제 사용 리소스와의 매칭을 함께 봐야 합니다.
script	외부 JavaScript 파일	스크립트 실행 순서와 다운로드 우선순위는 같은 문제가 아닙니다.

MDN은 이 속성이 2024년 10월부터 최신 장치와 브라우저 버전 전반에서 Baseline으로 제공된다고 설명합니다. 그래도 성능 최적화 값은 브라우저별 구현 차이가 남을 수 있으므로, 중요한 페이지에서는 실제 측정으로 확인하는 것이 좋습니다.

값은 어떻게 고르면 되나

high는 사용자 경험에 큰 영향을 주는 리소스에 제한적으로 씁니다. 대표적으로 첫 화면에서 가장 큰 콘텐츠로 잡힐 가능성이 높은 hero 이미지나 중요한 LCP 후보 이미지가 있습니다. 이미 preload로 일찍 발견되게 한 이미지에 우선순위 힌트를 추가하는 방식도 가능합니다.

low는 초기 렌더링에 덜 중요한 리소스에 씁니다. 예를 들어 접힌 영역 아래 이미지나, 페이지 초기 표시에는 덜 중요한 외부 리소스가 후보입니다. 다만 lazy loading, preload, async·defer 같은 다른 로딩 전략과 역할이 겹치지 않는지 같이 봐야 합니다.

auto는 브라우저 기본 판단에 맡기는 값입니다. 대부분의 리소스는 auto로 두는 편이 무난합니다. 우선순위 힌트는 브라우저가 잘못 추정하기 쉬운 소수 리소스를 보정하는 용도로 쓰는 것이 안전합니다.

preload와는 어떻게 다른가

preload는 브라우저가 리소스를 더 일찍 발견하도록 돕는 선언입니다. 반면 fetchpriority는 발견된 리소스를 가져올 때 상대 우선순위를 알려주는 힌트입니다. 즉 둘은 같은 기능이 아니라 서로 보완할 수 있는 기능입니다.

예를 들어 초기 화면의 큰 이미지를 CSS 배경이나 늦게 파싱되는 위치에서 쓰면 브라우저가 늦게 발견할 수 있습니다. 이 경우 link rel="preload" as="image"로 발견 시점을 앞당기고, 필요하면 fetchpriority="high"로 우선순위 신호를 추가할 수 있습니다.

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
<img src="/hero.webp" alt="서비스 화면" fetchpriority="high">

다만 같은 리소스를 preload와 실제 사용 위치에서 다룰 때는 URL, CORS 설정, 이미지 후보 선택이 어긋나지 않아야 합니다. 잘못 맞추면 미리 받은 리소스를 실제 렌더링에 재사용하지 못할 수 있습니다.

 

 

사용 기준은 어떻게 잡으면 되나

• 초기 화면의 핵심 이미지처럼 사용자 경험 영향이 분명한 리소스에만 high를 검토합니다.
• 접힌 영역 아래 이미지나 초기 렌더링과 거리가 있는 리소스에는 low를 검토합니다.
• 일반 리소스는 auto 또는 속성 생략으로 두고 브라우저 기본 판단을 따릅니다.
• preload가 필요한 문제인지, 우선순위 보정이 필요한 문제인지 먼저 나눠 봅니다.
• 적용 후에는 Lighthouse, WebPageTest, 브라우저 개발자 도구의 Network 패널 등으로 실제 요청 순서와 LCP 변화를 확인합니다.

FAQ

fetchpriority를 쓰면 LCP가 항상 좋아지나

아닙니다. LCP 후보 이미지가 늦게 발견되거나 브라우저가 중요도를 낮게 판단하는 상황에서는 도움이 될 수 있지만, 이미 충분히 빨리 발견되고 있는 리소스라면 효과가 작을 수 있습니다. MDN도 과도하거나 부정확한 우선순위 지정은 성능을 떨어뜨릴 수 있다고 설명합니다.

모든 이미지에 high를 붙이면 되나

그렇게 쓰면 우선순위 신호의 의미가 약해집니다. 여러 리소스가 모두 높다고 표시되면 브라우저가 실제로 무엇을 먼저 받아야 하는지 구분하기 어렵습니다. high는 초기 화면에서 중요한 소수 리소스에만 쓰는 편이 낫습니다.

script에 fetchpriority를 붙이면 실행 순서도 바뀌나

아닙니다. fetchpriority는 가져오기 우선순위 힌트입니다. 스크립트의 파싱 차단, 실행 순서, 비동기 실행은 async, defer, module script 규칙처럼 별도 기준으로 판단해야 합니다.