시리즈물/데이터 수집을 위한 크롤링

HTTP 103 Early Hints 기준

포도알77 2026. 9. 18. 22:13

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

HTTP 103 Early Hints는 서버가 최종 응답을 준비하는 동안 브라우저에 먼저 보낼 수 있는 정보성 상태 코드입니다. 목적은 HTML이 도착하기 전에도 중요한 연결이나 리소스 요청을 조금 더 일찍 시작하게 만드는 것입니다.

핵심은 “서버 생각 시간이 있는 문서 요청에서, 최종 응답에 포함될 가능성이 높은 Link 힌트를 먼저 보낸다”는 점입니다. 모든 사이트에 넣는 성능 옵션이라기보다, 첫 문서 응답이 늦고 초기에 필요한 리소스가 분명할 때 검토할 기능입니다.

103 Early Hints는 어디에 끼어드나

일반적인 문서 요청에서는 브라우저가 HTML 응답을 받은 뒤 <link rel="preload">, 스타일시트, 스크립트, 폰트 같은 하위 리소스를 발견합니다. 서버가 동적 페이지를 만들느라 시간이 걸리면 그만큼 하위 리소스 발견도 늦어집니다.

103 Early Hints는 이 빈 시간을 활용합니다. 서버는 최종 200 OK 응답을 보내기 전에 103 Early Hints 응답으로 Link 헤더를 먼저 보낼 수 있고, 브라우저는 이를 보고 preconnectpreload를 시도할 수 있습니다.

HTTP/2 103
link: </main.css>; rel=preload; as=style
link: <https://cdn.example.com>; rel=preconnect

HTTP/2 200
content-type: text/html; charset=utf-8
link: </main.css>; rel=preload; as=style

RFC 8297은 103을 최종 응답 전에 보낼 수 있는 정보성 응답으로 정의합니다. 보통 103에 담은 헤더 필드는 최종 응답에도 함께 넣지만, 최종 응답을 만들면서 그 힌트가 더 이상 맞지 않다고 판단되면 달라질 수 있습니다. 그래서 103은 계약이 아니라 힌트입니다.

어떤 리소스에 쓰는 것이 맞나

가장 먼저 볼 기준은 중요도입니다. 초기 렌더링에 직접 영향을 주는 CSS, 웹 폰트, 핵심 스크립트, 자주 쓰는 CDN origin처럼 문서 초반에 필요한 대상이 후보가 됩니다. 반대로 나중에 사용자 행동으로 필요한 리소스는 103으로 앞당겨도 체감 효과가 작을 수 있습니다.

두 번째 기준은 안정성입니다. Early Hints는 HTML이 아직 나오기 전에 보내므로, 요청 결과에 따라 달라지는 리소스에는 맞지 않습니다. 해시가 자주 바뀌는 파일, A/B 테스트로 자주 갈리는 번들, 로그인 상태에 따라 달라지는 파일을 섣불리 preload하면 잘못된 요청이나 중복 다운로드가 생길 수 있습니다.

세 번째 기준은 캐시 가능성입니다. Chrome 문서는 Early Hints로 preload한 리소스가 HTTP cache에 저장되고 나중에 페이지에서 다시 사용되는 구조를 설명합니다. 따라서 캐시할 수 없는 리소스를 preload하면 같은 리소스를 다시 가져오는 문제가 생길 수 있습니다.

후보 적합한 경우 주의할 점
preconnect 초기 화면에서 거의 항상 쓰는 외부 origin이 있음 CORS가 필요한 폰트 등은 연결 조건을 따로 봐야 함
preload CSS 문서 렌더링을 막는 핵심 스타일시트가 안정적임 as=style처럼 올바른 타입 힌트가 필요함
preload 폰트 초기 텍스트 렌더링에 필요한 폰트가 명확함 폰트는 CORS 조건과 캐시 정책을 함께 확인해야 함
동적 이미지 초기 대표 이미지 URL이 안정적이고 캐시 가능함 반응형 이미지 조건은 브라우저 구현 차이를 확인해야 함

HTML preload와 무엇이 다른가

HTML 안의 <link rel="preload">는 브라우저가 HTML을 받은 뒤에야 발견됩니다. Link 응답 헤더는 HTML 본문보다 조금 먼저 처리될 수 있지만, 서버가 최종 응답 헤더도 늦게 만들면 효과가 제한됩니다.

103 Early Hints는 최종 응답 헤더보다도 먼저 보낼 수 있다는 점이 다릅니다. 서버가 템플릿 렌더링, 권한 확인, API 호출 등으로 최종 문서를 준비하는 동안 브라우저가 연결 준비나 일부 리소스 다운로드를 시작할 수 있습니다.

다만 최종 응답을 거의 즉시 보낼 수 있다면 103의 이점은 작습니다. 그런 경우에는 일반 Link 헤더나 HTML의 <link> 요소로도 충분할 수 있습니다.

 

 

브라우저와 보안 제한은 어떻게 봐야 하나

MDN과 Chromium 문서 기준으로 103 Early Hints는 주로 Link 헤더와 함께 사용됩니다. MDN은 호환성과 보안 이유로 HTTP/2 이상에서 사용하는 것을 권장한다고 설명합니다. Chromium 문서는 Chrome이 top-level navigation 요청의 preloadpreconnect를 처리하고, subresource 요청이나 iframe navigation, HTTP/1.1 이하에서는 무시한다고 설명합니다.

또 하나의 제한은 여러 103 응답 처리입니다. MDN과 Chromium 문서 모두 브라우저가 첫 번째 Early Hints 응답만 처리하는 동작을 설명합니다. 최종 응답이 cross-origin redirect로 이어지는 경우에는 Early Hints로 얻은 리소스나 연결이 버려질 수 있습니다.

Content-Security-Policy도 함께 고려해야 합니다. MDN은 103 응답에 CSP가 포함될 수 있고, Early Hint 처리 중 적용된다고 설명합니다. 최종 응답의 CSP와 맞지 않으면 먼저 받아 둔 리소스가 실제 렌더링에는 사용되지 않을 수 있습니다.

적용 전에 무엇을 측정해야 하나

Early Hints는 성능 기능이므로 적용 전후 측정이 필요합니다. 우선 서버가 최종 HTML 응답을 만드는 데 실제로 시간이 걸리는지 봐야 합니다. 서버 처리 시간이 짧다면 Early Hints를 추가해도 개선 여지가 크지 않습니다.

다음으로 LCP, FCP, 주요 CSS와 폰트의 시작 시점, CDN 연결 시작 시점을 봅니다. Chrome에서는 Early Hints로 시작된 리소스가 DevTools나 PerformanceResourceTiming에서 별도 initiator로 관측될 수 있지만, 구현 제한으로 항상 동일하게 표시된다고 가정하면 안 됩니다.

운영에서는 실패 비용도 같이 봐야 합니다. 잘못된 preload는 대역폭을 먼저 쓰고, 잘못된 preconnect는 불필요한 연결을 만듭니다. 사용자별로 달라지는 페이지에서는 안정적인 공통 리소스만 힌트로 보내는 편이 안전합니다.

설정 기준

적용 순서는 보수적으로 잡는 것이 좋습니다. 먼저 첫 방문 비중이 높은 landing page나 서버 렌더링 시간이 있는 문서 요청을 고릅니다. 그 다음 초기 화면에 거의 항상 필요한 origin 또는 리소스를 고르고, 마지막으로 캐시와 CSP, CORS 조건을 확인합니다.

# 안정적인 CDN origin에 먼저 연결
Link: <https://cdn.example.com>; rel=preconnect

# 초기 렌더링에 필요한 CSS를 미리 가져오기
Link: </assets/main.css>; rel=preload; as=style

처음부터 많은 리소스를 넣는 것은 피하는 편이 낫습니다. 하나의 핵심 CSS나 CDN origin처럼 효과와 실패 비용이 분명한 대상부터 시작하고, 실제 요청 waterfall과 사용자 지표를 보고 늘리는 방식이 안정적입니다.

FAQ

103 Early Hints를 쓰면 HTML이 더 빨리 오나?

아닙니다. 최종 HTML 생성 시간이 줄어드는 기능은 아닙니다. HTML을 기다리는 동안 브라우저가 일부 준비를 먼저 하게 만드는 기능입니다.

모든 preload를 103으로 옮기면 되나?

아닙니다. HTML을 보고 나서야 정확히 알 수 있는 리소스는 일반 HTML preload가 더 적절할 수 있습니다. 103에는 요청 결과와 무관하게 안정적인 후보만 넣는 것이 좋습니다.

HTTP/1.1에서도 쓸 수 있나?

상태 코드 자체는 정보성 응답이지만, 호환성과 보안 문제 때문에 현대 브라우저 환경에서는 HTTP/2 이상을 전제로 검토하는 편이 안전합니다. MDN도 HTTP/2 이상 사용을 권장한다고 설명합니다.

참고 기준

반응형

'시리즈물 > 데이터 수집을 위한 크롤링' 카테고리의 다른 글

HTTP Content-Digest 기준  (0) 2026.09.22
HTTP Priority 헤더 기준  (0) 2026.09.21
robots.txt crawl-delay 기준  (0) 2026.09.16
HTTP stale 캐시 기준  (0) 2026.09.15
HTTP Cache-Status 헤더 기준  (0) 2026.09.14
페이스북으로 공유카카오톡으로 공유카카오스토리로 공유트위터로 공유URL 복사