103 Early Hints: 서버 생각 시간 동안 주요 리소스 사전 로드

2026년 3월 Arjen Karel이 마지막으로 검토함

103 Early Hints란 무엇인가요?

Early Hints는 웹 서버가 최종 응답을 보내기 전에 전송되는 HTTP 상태 코드(103)입니다. 이를 통해 서버는 로딩 프로세스 초기에 이미지나 스타일시트와 같은 특정 리소스가 페이지 렌더링에 중요하다고 브라우저에 알릴 수 있습니다.

대부분의 동적 페이지는 생성하는 데 시간이 걸립니다. 서버는 데이터베이스를 쿼리하고, 애플리케이션 로직을 실행하며, HTML을 조립합니다. 그 처리 시간 동안 브라우저는 그냥 기다립니다. 103 Early Hints는 브라우저가 실제 응답을 기다리는 동안 무엇을 가져와야 할지 알려줌으로써 그 간극을 채웁니다.

Early Hints는 Chrome 버전 106에서 제거된, 더 이상 사용되지 않는 HTTP/2 Server Push를 대체합니다. Server Push는 리소스를 최종 응답과 함께 번들로 묶어 브라우저가 이미 캐시한 바이트를 자주 푸시했습니다. Early Hints는 힌트만 제공하기 때문에 해당 문제를 피합니다. 브라우저가 이를 실행할지 여부를 결정합니다.

브라우저 지원

103 Early Hints는 전 세계 브라우저의 93%에서 지원됩니다:

• Chrome 103+ 및 Edge 103+: preconnect 및 preload 완벽 지원 (2022년 6월부터)
• Firefox 123+: preconnect 및 preload 완벽 지원 (2024년 2월부터)
• Safari 17+: preconnect만 지원. Safari는 103 응답에서 preload를 지원하지 않습니다

Safari의 제한 사항은 중요합니다. Early Hints 전략이 전적으로 이미지나 폰트의 preload에 의존한다면 Safari 사용자는 혜택을 받지 못할 것입니다. Safari가 최소한 리소스 출처에 대한 연결을 워밍업할 수 있도록 preload 힌트와 함께 preconnect 힌트를 포함하세요.

Early Hints는 HTTP/2 또는 HTTP/3에서만 작동합니다. HTTP/1.1, iframe 또는 탐색이 아닌 요청(non-navigation requests)에 대해서는 작동하지 않습니다. 브라우저는 preload 및 preconnect에 대한 힌트만 처리합니다. dns-prefetch 및 prefetch는 103 응답에서 지원되지 않습니다.

103 Early Hints는 어떻게 생겼나요?

브라우저가 페이지를 요청하면, 서버는 HTML 생성을 완료하기 전에 즉시 103 응답을 반환합니다. 이 응답은 브라우저에 LCP 이미지 및 스타일시트 가져오기를 시작하라고 알려줍니다:

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image
Link: </style.css>; rel=preload; as=style

그동안 서버는 페이지를 생성합니다. 준비가 되면 최종 응답을 보냅니다:

HTTP/2 200 OK
Content-Length: 1234
[the rest of the response]

브라우저가 200 응답을 받을 때쯤이면 이미 이미지와 스타일시트 다운로드를 시작한 상태입니다. 이러한 유리한 시작 덕분에 Largest Contentful Paint가 더 빨라집니다.

103 Early Hints 전송 방법

가장 쉬운 방법부터 제어 수준이 가장 높은 방법까지 세 가지 주요 옵션이 있습니다.

Cloudflare (가장 쉬움)

성능 향상을 위해 이미 Cloudflare를 사용 중이라면 토글 한 번으로 Early Hints를 활성화할 수 있습니다. Speed > Settings > Content Optimization으로 이동하여 Early Hints를 켭니다. 무료 등급을 포함한 모든 요금제에서 사용할 수 있습니다.

Cloudflare는 오리진 서버의 200 응답에서 Link 헤더를 캐시합니다. 후속 요청에서는 요청을 오리진으로 전달하기 전에 해당 캐시된 헤더를 103 응답으로 보냅니다. 애플리케이션에서 Link 헤더를 전송하여 힌트를 제공할 수 있습니다:

header("Link: </image.webp>; rel=preload; as=image", false);
header("Link: </style.css>; rel=preload; as=style", false);

NGINX (1.29.0부터 네이티브 지원)

NGINX는 1.29.0 버전(2025년 6월)에 네이티브 103 Early Hints 지원을 추가했습니다. early_hints 지시문은 백엔드에서 클라이언트로 103 응답을 전달합니다:

map $http_sec_fetch_mode $early_hints {
    navigate $http2$http3;
}

server {
    location / {
        early_hints $early_hints;
        proxy_pass http://backend.example.com;
    }
}

sec-fetch-mode 맵은 HTTP/2 또는 HTTP/3를 통한 탐색 요청에 대해서만 힌트가 전송되도록 보장합니다. 백엔드 애플리케이션에서 103 응답을 생성해야 하며 NGINX는 이를 통과시킵니다.

Apache (2.4.58+)

Apache는 mod_http2를 사용하여 103 응답을 자체적으로 생성할 수 있습니다. H2EarlyHints 지시문으로 이를 활성화하고 힌트를 줄 리소스를 정의하세요:

H2EarlyHints on
H2EarlyHint Link "</style.css>;rel=preload;as=style"
H2EarlyHint Link "</image.webp>;rel=preload;as=image"

NGINX와 달리 Apache는 애플리케이션에서 생성할 필요 없이 서버 수준에서 103 응답을 생성합니다.

Early Hints가 도움이 될 때 (그리고 그렇지 않을 때)

103 Early Hints는 데이터베이스 쿼리, API 호출, 템플릿 렌더링과 같은 동적 페이지 등 서버가 응답하는 데 눈에 띄는 시간이 걸릴 때 가장 효과적입니다. Time to First Byte가 느릴수록 브라우저가 힌트에 따라 조치를 취할 시간이 더 많아집니다.

Early Hints는 다음과 같은 경우에는 이점이 적습니다:

• 서버가 100ms 미만으로 응답할 때. TTFB가 이미 빠르다면 브라우저가 채울 간격이 없습니다. 대신 HTML의 리소스 우선순위 지정에 집중하세요.
• 페이지가 캐시에서 제공될 때. 완전히 캐시된 HTML 응답은 너무 빨리 로드되어 103 응답이 먼저 시작할 틈이 거의 없습니다.
• 너무 많은 리소스에 힌트를 줄 때. 10개 이상의 리소스에 힌트를 주면 연결이 포화 상태가 되어 속도가 느려질 수 있습니다. Shopify의 조사에 따르면 모바일 기기에서 공격적인 힌트 제공은 TTFB, FCP 및 LCP 전반에 걸쳐 성능 저하를 가져왔습니다. 2~4개의 주요 리소스만 유지하세요.

93%의 브라우저 지원에도 불구하고 채택률은 여전히 낮습니다. 2025년 Web Almanac에 따르면 상위 사이트의 약 5%만이 103 Early Hints를 사용합니다. 주요 장벽은 각 페이지에 대해 어떤 리소스에 힌트를 주어야 할지 아는 것이며, 이는 대부분의 CMS에서 자동으로 처리하지 않는 부분입니다.

Early Hints가 작동하는지 확인하는 방법

Chrome DevTools를 열고 Network 패널로 이동하여 페이지를 새로 고침합니다. 문서 요청을 클릭하고 응답 헤더를 확인합니다. Early Hints가 작동하는 경우 타이밍 내역에서 200 앞에 103 상태가 표시됩니다.

명령줄에서 curl을 사용하여 확인할 수 있습니다:

curl -v --http2 https://example.com 2>&1 | grep "< HTTP"

103과 200 응답이 모두 표시되어야 합니다.

테스트 결과

First Contentful Paint 및 Largest Contentful Paint에 미치는 영향을 측정하기 위해 두 가지 시나리오를 테스트했습니다.

1. LCP 이미지에만 Early Hints 적용

103 Early Hints를 적용한 경우, HTML의 일반적인 preload와 비교하여 LCP 이미지가 화면에 35% 더 일찍 나타났습니다.

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image

2. 대형 스타일시트 및 LCP 이미지에 Early Hints 적용

힌트에 85kb의 CSS 파일을 추가하자 차이가 더욱 두드러졌습니다. FCP는 1.8초에서 1.4초로, LCP는 3.2초에서 2.0초로 개선되었습니다.

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image
Link: </style.css>; rel=preload; as=style

이 수치는 Cloudflare가 100,000개 이상의 고객을 대상으로 측정한 결과와 일치합니다. 데스크톱의 50번째 백분위수에서 6%, 75번째 백분위수에서 16%의 LCP 개선을 보였습니다. Shopify는 블랙 프라이데이와 사이버 먼데이 기간 동안 p50에서 500ms의 LCP 개선을 확인했습니다. 서버 응답 시간이 느린 페이지에서 가장 큰 이득을 얻을 수 있는데, 이때가 바로 Early Hints가 작동할 시간이 가장 많은 때입니다.

Early Hints 및 TTFB

알아두어야 할 측정상의 뉘앙스가 있습니다. Chrome 133부터 브라우저의 responseStart 타이밍(대부분의 도구에서 TTFB를 보고하는 데 사용됨)에는 103 응답이 포함됩니다. 즉, 서버의 실제 처리 시간이 변경되지 않았더라도 Early Hints를 활성화하면 보고되는 TTFB가 줄어듭니다.

서버 처리 시간을 별도로 측정해야 하는 경우, Chrome 133에서는 최종 200 응답 헤더가 언제 도착하는지 보고하는 새로운 firstResponseHeadersStart 타임스탬프를 도입했습니다. 두 값을 모두 추적하는 Real User Monitoring 도구를 사용하면 전체적인 그림을 파악할 수 있습니다. Early Hints가 브라우저에 얼마나 많은 시간을 절약해 주었는지, 서버가 실제로 응답하는 데 얼마나 걸렸는지 알 수 있습니다.