103 Early Hints: サーバーの処理時間中に重要なリソースをプリロードする
ページが準備される前に、サーバーの処理時間を利用してLCP画像と重要なCSSをプリロードする

103 Early Hintsの概要
103 Early Hintsは、サーバーが最終的なレスポンスの前に送信する軽量のHTTPステータスコードです。サーバーがまだページの処理を行っている間に、ブラウザはLCP画像やメインのスタイルシートなど、重要なリソースの取得を開始できます。
テストでは、103 Early Hintsを使用することでLCP画像の表示が35%高速化しました。ヘッダーにスタイルシートも含めた場合、その改善はさらに大きくなりました。

Arjen Karelによる最終レビュー: 2026年3月
103 Early Hintsとは?
Early Hintsは、Webサーバーが最終的なレスポンスを送信する前に送信される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の戦略を画像やフォントのプリロードに完全に依存している場合、Safariユーザーはその恩恵を受けることができません。Safariが少なくともリソースのオリジンへの接続をウォームアップできるように、preloadヒントと一緒にpreconnectヒントを含めるようにしてください。
Early HintsはHTTP/2またはHTTP/3でのみ機能します。HTTP/1.1、iframe内、または非ナビゲーションリクエストでは機能しません。ブラウザは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を送信する方法
最も簡単なものから最も細かく制御できるものまで、主に3つのオプションがあります。
Cloudflare(最も簡単)
パフォーマンス向上のためにすでにCloudflareを使用している場合、Early Hintsはトグル1つで有効にできます。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によると、103 Early Hintsを使用しているトップサイトは約5%にすぎません。主な障壁は、各ページでどのリソースをヒントとして指定すべきかを把握することであり、これはほとんどの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への影響を測定するために、2つのシナリオをテストしました。
1. LCP画像のみにEarly Hintsを使用した場合
HTMLでの通常のプリロードと比較して、103 Early Hintsを使用すると、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が10万人以上の顧客を対象に測定した結果(デスクトップの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によってブラウザでどれだけの時間が節約されたか、サーバーが実際に応答するまでにどれだけの時間がかかったかという全体像を把握できます。

