HTTP
導入
HTTPは依然としてウェブエコシステムの基礎であり、データ交換の基盤を提供し、さまざまな種類のインターネットサービスを可能にしています。これは活発に開発されているプロトコルであり、最新バージョンのHTTP/3は2年以上前に標準化され、新しいDNS HTTPSレコードなど、それを有効にするための新しいオプションが最近利用可能になりました。同時に、ウェブプラットフォームは、ウェブ開発者がHTTPを介してリソースがいつ、どのように要求およびダウンロードされるかに影響を与えるために使用できる、ますます多くの高レベルの機能を公開しています。これには、リソースヒント（たとえば、preloadやpreconnect）、103 Early Hints、Fetch Priority APIなどのオプションが含まれます。
この章では、まずHTTP/1.1、HTTP/2、HTTP/3の採用の現状と、その使用が時間とともにどのように進化してきたかを見ていきます。次に、新しいウェブプラットフォームの機能について考察し、それらがどの程度サポートされており、実際にどのように使用されているかを把握します。
HTTPバージョンの採用
概念的には、HTTP/2とHTTP/3の採用がどの程度広まっているかを把握するのは簡単なはずです。データセットで観測されたウェブページを読み込むために、各プロトコルバージョンがどのくらいの頻度で使用されたかを報告するだけです。これは、以下のグラフでまさに行ったことです。
これらの結果は一見すると妥当に見えるかもしれませんが、実際にはかなり誤解を招くものです。実際、後で見るように、ウェブ全体でのHTTP/3のサポートは、上記の7〜9%ではなく、実際には30%に近いです。この不一致は、HTTP/3が使用される前に発見される必要があるという事実によるものであり、Web Almanacに使用されている方法論は、主要な発見オプション（alt-svcを介したHTTP/3を参照）にはあまり適していません。これにより、多くのHTTP/3対応サイトが依然としてHTTP/2で読み込まれ、したがってHTTP/3が過小報告されています。これについては後で詳しく説明しますが、今のところ、HTTP/2とHTTP/3をHTTP/2+という単一のラベルにグループ化して、少なくともHTTP/1.1と一般的に比較することで、この問題を回避します。
したがって、2024年にはホームページの21〜22%しかHTTP/1.1で読み込まれていないことがわかります。これは、2022年の34%や、とくに2020年のHTTP/1.1とHTTP/2+がほぼ50/50の割合だったのとは著しい違いです。しかし、これはページのメインドキュメント（HTML）がどのように読み込まれるかを見ているだけです。HTTPの採用を見るもう1つの方法は、すべてのリクエスト（サブリソースやサードパーティを含む）に使用されるバージョンを見ることです。これにより、結果はさらにHTTP/2+に偏ります。
これは、多くのウェブサイトがさまざまなサードパーティドメイン（たとえば、アナリティクス、プラグイン/タグ、ソーシャルメディア統合）から追加のリソースを読み込むためです。その規模から、これらの外部サービスは、多くの場合、HTTP/2+のサポートを自ら提供するか、いわゆるCDNまたはコンテンツ配信ネットワーク（たとえば、Akamai、Cloudflare、Fastly）を利用してそれを行います。実際、CDNは私たちのデータセットで観測されたウェブサイトで非常に頻繁に使用されており、データセット内の13億を超えるリクエストのなんと54%がCDNから提供されています！
これらの企業は、通常、新しい標準やプロトコルを実装する最前線にいます。新しい機能を有効にすると、すべての顧客が利用できるようになり、通常、世界的な採用が急速に増加します。したがって、CDNが依然としてHTTP/2+採用の主要な推進力の1つであることがわかります。すべてのCDNリクエストの4%未満がHTTP/1.1経由で行われています。これは、CDNノードから提供されていないリクエストとは対照的で、そのうち最大29%が依然としてHTTP/1.1を使用しています。
これらの結果を総合すると、新しいHTTPバージョンの全体的な採用はこれまで以上に高くなっていますが、「取り残される」危険にさらされているサイトもまだたくさんあることがわかります。これらは主に、CDNを利用できない、または利用したくない（おそらく小規模な）プロジェクトですが、オリジンでHTTP/2+を有効にするための技術的なノウハウや動機もありません。概念的には、これは理にかなっています。新しいバージョンには、複雑さの観点から、とくにHTTP/3の場合はCPU使用率の観点から、いくつかのコストが伴うためです。そして、HTTP/1.1はもちろんまだ完全に機能しますが、パフォーマンス/効率の面でいくつかの欠点がある可能性があります。HTTP/2+のみが複数のリソースを1つの接続に多重化できるだけでなく、リソースの優先順位付けやヘッダー圧縮などの追加機能も備えているためです。
それでも、個人的には、コンテンツだけでなく、使用される技術スタック、そしてプロトコルも含めて、ウェブ上で選択の自由があるのは良いことだと感じています。重要なことに、現在のCDNへの（パフォーマンスとセキュリティのための）過度の依存には、独自の欠点もあります。一部の人々は、いくつかの大企業を中心にウェブが「中央集権化」されることを恐れています。まだそこまでには至っていないと思いますが、以前に書いたように、新しいプロトコルを大規模に展開するための技術的なノウハウを持っているのが、ますますCDN/大企業だけになっているという憂慮すべき事実についてです。ここで正しい答えはわかりませんが、両方の側面を強調するのは良いことだと感じています！これについてどう思うかは別として、CDNがすでに今日のウェブの大部分を占めており、新しいHTTPバージョンの採用を推進していることは明らかです。
それでは、哲学的な話から（深く）技術的な話に戻り、Web AlmanacデータセットがなぜHTTP/3の使用率が低いのかを正確に探ってみましょう！
HTTP/3サポートの発見
HTTP/3の採用を測定するのは難しい場合があります。なぜなら、ほとんどの最新のブラウザやクライアントは、これまで見たことのないドメインからページを初めて読み込むときにHTTP/3を試さないからです。その理由は複雑で、以前のWeb Almanac（2020年と2021年）で詳しく説明されています。要するに、対象ドメインでHTTP/3が利用できない場合（たとえば、サーバーがまだサポートしていない場合や、ネットワークがプロトコルをブロックしている場合）、ブラウザがHTTP/2（またはHTTP/1.1）にフォールバックするのに（非常に）長い時間がかかる可能性があるということです。
これはHTTP/2とHTTP/1.1ではそれほど問題になりません。なぜなら、両方ともTCPプロトコル上で実行されるからです。サーバーがHTTP/2をサポートしていない場合、ブラウザが設定した既存のTCP接続上でHTTP/1.1を続行でき、「即時フォールバック」が得られます。しかし、HTTP/3は異なります。TCPをQUICという新しいトランスポートプロトコルに置き換え、それがUDPプロトコル上で実行されるためです。ブラウザがQUIC+HTTP/3接続をサポートしていないサーバーにのみ開いた場合、そのサーバーはHTTP/2やHTTP/1.1にフォールバックできません。なぜなら、それはQUIC/UDPではなくTCP上でしか可能ではないからです。HTTP/3接続がタイムアウトするのを待つ必要があり（数秒かかる場合があります）、その後で初めてHTTP/2またはHTTP/1.1用の新しいTCP接続を開くことになります。これはエンドユーザーにとって非常に目立つでしょう。
ユーザーがこの潜在的な遅延に悩まされないようにするため、ブラウザは実際には、サーバーがサポートすることを100%確信している場合にのみHTTP/3を試します。しかし、どうすれば100%確信できるのでしょうか？もちろん、サーバー/デプロイメントが最初にHTTP/3をサポートしていることをブラウザに明示的に伝えた場合です！
これを行うには、主に2つの方法があります。
-
alt-svcHTTPレスポンスヘッダー: HTTPサーバーは、HTTP/2またはHTTP/1.1でリソースが要求されたときにHTTP/3のサポートをアドバタイズします。 - DNS HTTPSリソースレコード: DNSサーバーは、接続確立前に名前解決中にHTTP/3のサポートを示します。
最初のオプションは今日もっとも人気がありますが、HTTP/3のサポートを発見するために最初にHTTP/2またはHTTP/1.1での「ブートストラップ」接続が必要になるという欠点があります。2番目のオプションは、最初のHTTP接続が行われる前に解決されるドメインネームシステム（DNS）に情報を直接入れることで、この欠点を取り除きます。しかし、これははるかに新しく、執筆時点ではあまりサポートされていません。
Web Almanacデータセットで実際のHTTP/3のサポートを正しく把握するには、両方を別々に考慮する必要があります。なぜなら、それらは矛盾した結果をもたらすからです。
alt-svc経由のHTTP/3
上記で説明したように、ブラウザが以前にドメインに接続したことがない場合、もっともサポートされている可能性が高いTCP経由でHTTP/2またはHTTP/1.1のみを試します。各HTTP/2またはHTTP/1.1の応答に対して、サーバーは特別なalt-svc HTTP応答ヘッダーを送信して、少なくとも指定された期間（ma（max-age）パラメーター）はHTTP/3もサポートすることを保証していることを示すことができます。
alt-svc HTTPレスポンスヘッダーが表示されており、www.akamai.comのUDPポート443でALPN値h3とmax-ageが26時間のHTTP/3をサポートしていることを示しています。alt-svcレスポンスヘッダーの例。
alt-svcは代替サービスの略です。現在HTTP/2サービスを使用しており、HTTP/3サービスも利用可能です（通常はUDPポート443）。それ以降、ブラウザがサーバーへの新しい接続を必要とするとき、HTTP/3でも確立を試みることができます！したがって、このメカニズムを使用すると、サーバーがHTTP/3をサポートしていても、最初の読み込みはH2またはHTTP/1.1で行われるため、HTTP/3は通常、サイトの2回目のページ読み込みからのみ使用されます。そして、これがここでの問題の核心です。Web Almanacは設計上、最初のページ読み込みのみを測定するためです。
結果をウェブサイト間で比較可能かつ公正にするために、各ページを新しいブラウザプロファイルで、HTTP/ファイル/DNS/alt-svc/…キャッシュに何もない状態で読み込みたいと考えています。したがって、alt-svcメカニズムは、最初のHTTP/2接続のみを使用し、HTTP/3には決して到達しないため、私たちの方法論では概念的に役に立ちません。これが、データセットで使用されているプロトコルでHTTP/3の採用を直接測定すること（上記の最初の画像で行ったように）が誤解を招く理由であり、HTTP/3が過小報告されています。
それでは、alt-svcを介してHTTP/3のサポートがどのようにアナウンスされているかを純粋に見て、データセットに実際には表示されなくても、サイトがどの程度のサポートを主張しているかを把握しましょう。
alt-svc経由）は2022年以降着実に増加しています。
2022年6月にHTTP/3のサポートを最後に見たとき、プロトコルはまだ完全に標準化されていませんでした。それでも、一部の大手企業による早期の展開により、HTTP Archiveデータセットのサイトの約18%がHTTP/3のサポートを示していました。2年後の今、新しいプロトコルのサポートは着実に増加し、26%（デスクトップ）から28%（モバイル）に達し、全体で10%近く増加していることがわかります。それでも低いように思えるかもしれませんが、実際にはHTTP/2の進化と非常によく似ており、標準化後2年目（2017年）には同様に約30%の普及率が見られました。
モバイルのホームページがデスクトップのホームページよりもHTTP/3のサポートが少し良いことを宣伝しているのは、いくぶん興味深いことです。これは、HTTP/3が主にモバイル/セルラーネットワークで利点をもたらすため（したがって、サイト所有者は主にそのために有効にしたいと思うかもしれません）、また、一部の企業環境では依然としてネットワーク上でHTTP/3をブロックする傾向があるため（デスクトップクライアントで有効にするのがあまり面白くなくなります）、説明できる可能性があります。
上記のHTTP/2+と同様に、HTTP/3のサポートは主にCDNから来ていますが、私の意見ではかなり極端な形です。データセットで見られるすべてのHTTP/3応答の約85%がCDNから来ています。これは、すべてのHTTP/2+リクエストの約55%と比較されます。これは、今日、オリジンでHTTP/3を自己展開しているウェブサイト所有者が非常に少ないことを示しており、新しい技術の急速な採用が（悲しいことに）大企業だけのものになるかもしれないという上記の私の点を再強調しています。しかし、これは完全に予想外ではありません。人気のある「既製」のウェブサーバーの多くは、NodeJS、Apache、nginxなどのプロジェクトを含め、まだ安定した、成熟した、デフォルトでオンのHTTP/3サポートを持っていません。接続移行や0-RTTなど、プロトコルのより高度な機能の一部を使用するスケーラブルなHTTP/3展開を実行することは、決して簡単ではありません。それでも、近い将来、より多くの人々がHTTP/3を自己ホストすることを期待しています。
ここで重要な注意点は、すべてのCDNが同等に高いHTTP/3サポートを示しているわけではないということです。
HTTP/3 alt-svc |
CDN |
|---|---|
| > 90% | Facebook, Automattic, jsDelivr |
| 50% - 90% | Cloudflare, Cedexis |
| 10% - 50% | Google, Amazon Cloudfront, Fastly, Microsoft Azure, BunnyCDN, Alibaba, CDN 77 |
| 1% - 10% | Akamai, Sucuri Firewall, Azion, KeyCDN |
| < 1% | Twitter, Vercel, Netlify, OVH CDN, EdgeCast, G-Core CDN, Incapsula |
alt-svc応答の割合。
まず、一部の企業はHTTP/3に全面的に注力しているように見えます。たとえば、Facebookは応答の99.86%でHTTP/3のサポートを示しています！これは、Twitter/Xのような同様の企業とは対照的で、alt-svcをまったく送信しません。次に、明らかにHTTP/3をサポートしている一部のCDNでさえ、高い割合に達することはめったになく、Cloudflareが78%でトップを走り、Akamaiがわずか7%で追随しています。
これは、CDNが新しいプロトコルをどのように有効にするかと関係がある可能性がもっとも高いです。たとえば、Cloudflareは無料プランでデフォルトで有効にしているため、高い（ただし普遍的ではない）使用率につながっています。対照的に、Akamaiは顧客が構成で手動で機能を有効にする必要があり、多くの人が遅い/乗り気でないようです。したがって、すべてのCDN顧客が有効にすれば、ウェブ上のHTTP/3サポートの量は約28%よりもはるかに高くなる可能性があります。
最後に、Automatticのようなより専門的なデプロイメントがHTTP/3に大きく傾倒している（99.92%）のに対し、VercelやNetlifyのような他のデプロイメントがほぼゼロのHTTP/3サポートを示しているのは、いくぶん驚くべきことです。後者の理由については推測することしかできませんが、主に、新しいプロトコルを大規模に設定および維持することの複雑さによるものと想定しています。これらの新しい新興企業は、まずスタックの他の部分に焦点を当てることを好むかもしれません。
結論として、現在、Web Almanacデータセットのすべてのウェブサイトの約27%がalt-svcを介してHTTP/3のサポートをアナウンスしていることがわかります。互換性のあるCDNを使用しているすべてのウェブサイトが有効にすれば、この数ははるかに高くなる可能性があります。しかし同時に、データセットで見た実際のHTTP/3リクエストの数ははるかに低く、7〜9%の間です。説明したように、これは使用されている方法論によるものであり、それらの7〜9%のほとんどはDNSレコードを使用した別のHTTP/3発見方法から来ているため、次にそれらを見てみましょう。
DNS経由のHTTP/3
alt-svc HTTPレスポンスヘッダーを介してHTTP/3のサポートをアナウンスすることにはいくつかの欠点があり、新しいプロトコルはサーバーへの2番目の接続からのみ使用されるようになることを理解しました。この非効率性をなくすには、ブラウザがサーバーへの最初の接続を開く前にHTTP/3のサポートを発見する必要があります。幸いなことに、接続が設定される前にまだ起こることが1つあります。それはDNS解決です。
ドメインネームシステム（DNS）は、しばしば大きな電話帳として説明され、ホスト名（たとえばwww.example.org）を1つ以上のIPアドレスに変換できます（AおよびAAAAクエリはそれぞれIPv4およびIPv6の結果を返します）。しかし、本質的に、DNSは、IPアドレス（およびCNAMEなどの関連メタデータ）以外のものも保持できる、非常に大規模で分散したキー値ストアと考えることもできます。いくつかの例には、MXレコードで電子メールの詳細を一覧表示することや、TXTレコードを使用してドメインの所有権を証明すること（たとえば、Let’s Encryptの場合）が含まれます。
過去数年間、とくにサービスバインディング（SVCB）とHTTPSレコードという新しい概念で、DNSに他の情報を追加する作業が進行中です。これらの新しいレコードは、クライアントにサービス/オリジンに関するIPアドレスだけでなく、はるかに多くの情報を提供します。HTTPS対応かどうか、プライバシーを強化するために新しい暗号化されたクライアントハローを使用できるかどうか、または私たちの目的のために、どのプロトコルをどのポートでサポートしているかなどです。これは、現在、リダイレクトの連鎖や上記のalt-svcなどの遅い方法で行われることが多い、またはHSTSプリロードなどの帯域外の方法を必要とする、最初の接続設定/サービス発見を少し効率的にすることを目的としています。また、複雑な負荷分散設定（たとえば、複数のCDNを組み合わせる場合）にも役立つことを目的としています。
しかし、SVCBに関する完全な議論はここでは時間がかかりすぎるため、新しいHTTPSレコードを介してHTTP/3のサポートをアナウンスする方法にのみ焦点を当てます。他のブログ投稿やドキュメント、詳細がより広いアプリケーションについて書かれているものがたくさんあるためです。実際のHTTPSレコードの例を見てみましょう。
digコマンドラインツールからのスクリーンショット。DNS HTTPSレコードがalpn h3とh2をリストし、blog.cloudflare.comのipv4hintとipv6hintの両方を提供していることを示しています。ご覧のとおり、blog.cloudflare.comは、応答のalpn="h3,h2"部分を介して、HTTP/3とHTTP/2の両方のサポートを示しています（優先順位順！）。ALPNはアプリケーション層プロトコルネゴシエーションの略で、元々はサーバーがサポートするアプリケーションプロトコルとバージョンを示すためのTLS（トランスポート層セキュリティプロトコル）拡張機能でした。たとえば、上記で説明したHTTP/2からHTTP/1.1への正常なフォールバックを可能にするためです。
一般的なアプローチとALPN名は、DNS HTTPSレコードにも再利用されます。さらに、この例では、オプションのipv4hintとipv6hintエントリが示されています。これにより、ユーザーを特定のサービスの特定のエンドポイントに誘導できます。たとえば、デプロイメント内のすべてのマシンが実際にHTTP/3をサポートしているわけではない場合、たとえばマルチCDN設定の場合などです。
結論として、ブラウザがHTTPSレコードのDNSをクエリし（通常はAおよびAAAAクエリと並行して、またはそれより前に行われます）、その後ALPNリストにh3が表示された場合、サーバーへの最初の接続でHTTP/3を試すことも許可/推奨されます。これにより、alt-svcのブートストラップのオーバーヘッドが回避されます。
それでは、Web Almanacデータセットで、新しいDNSレコードが実際にどの程度使用されているかを見てみましょう。一般的な使用状況を見ると、モバイルとデスクトップの両方のページの約12%に何らかのHTTPSレコードが定義されていることがわかります。ただし、それらすべてがalpnセクションにh3オプションを含んでいるわけではありません。それはわずかに低く、9%（デスクトップ）と10%（モバイル）です。
h3 ALPNトークンが設定されたDNS HTTPSレコードを使用し、91%がDNS HTTPSレコードをまったく使用しないか、h3 ALPNトークンが設定されていないものを使用していました。モバイルでは、ページの10%がHTTP/3対応のDNS HTTPSレコードを使用していました。これは、データセットで考慮されたすべてのページの9〜10%（または2,000万以上）がDNSを介してHTTP/3のサポートを示していることを意味します。ただし、これは自動的にHTTP/3がブラウザで実際に使用されることを意味するわけではありません。この章の最初の画像で示したように、実際にHTTP/3で読み込まれたページは約7%（デスクトップ）から9%（モバイル）にすぎませんでした。これは間違いなくDNS HTTPSの採用と同じ桁数ですが、まったく同じではありません。
これには、新しいプロトコルをブロックするネットワーク、HTTP/3がHTTP/2接続への「競争」に何らかの形で負けること（これについては次のセクションその他の考慮事項で説明します）、DNS HTTPSレコードが誤って構成されていること、レコードのDNS応答が遅延すること、接続の合体によりHTTP/2接続が再利用されることなど、さまざまな理由が考えられます。それでも、ページ読み込みプロセスの早い段階でHTTP/3のサポートを示すこの新しい/代替方法は、alt-svcアプローチを改善する強力な可能性を秘めていることを示しています！これは、HTTP/3で観測されたすべてのページ読み込みの99%が実際にDNS HTTPSレコードの存在によってトリガーされたことを確認したため、とくにWeb Almanacの方法論に当てはまります（1%の不一致は少し奇妙ですが、将来の分析の良いトピックです）。
また、2023年10月にJan Schaumannが行った同様の調査と比較するのも興味深いです。彼は、テストされた1億以上のドメインのうち、HTTPSレコードを提供したのは約4%にすぎず、Trancoリストの上位100万ドメインではなんと25%以上に増加したことを発見しました。彼は、DNS HTTPSレコードの採用は「Cloudflareがすべてのドメインでデフォルトでレコードを設定することによって効果的に推進されている」と結論付けました。これは、新しい機能の採用を推進するのは大手CDNであるという以前の調査結果と一致するため、私たちのデータが何を示しているかを見てみましょう。
h3 DNSレコード |
CDN |
|---|---|
| > 60% | なし（まだ！） |
| 50% - 60% | Cloudflare |
| 2% - 50% | BunnyCDN, Alibaba |
| < 2% | Akamai, Amazon Cloudfront, Microsoft Azure, Fastly, Netlify, Google, Incapsula, Azion, Sucuri Firewall, Vercel |
| < 0.05% | Automattic, OVH |
Cloudflareがここで明らかにリーダーであることがわかります。ホストされているサイトの50%以上でHTTPS DNSレコードにh3を設定しています。他の大手CDNのほとんどは、ある程度のサポートがあり、機能をテストしているようですが、2%を超えることはめったにありません。ここでの興味深い例外はAutomatticで、alt-svcを介してほぼ普遍的なHTTP/3サポートがありましたが、DNS HTTPSレコードではわずか0.04%でした。これ以外では、CDNを介して読み込まれなかった850万ページのうち、HTTP/3サポート用にDNS HTTPSレコードが構成されていたのはわずか0.46%であり、（良くも悪くも）最先端の機能の採用を大規模に推進しているのはCDNであるという私たちの結論を再び裏付けています。
今後数年間のWeb AlmanacでDNS HTTPSおよびSVCBレコードの使用を追跡し、その採用がどのように進化するか、そしてそれがデータセット内の実際のHTTP/3の使用にどのようにマッピングされるかを見るのは興味深いでしょう。
その他の考慮事項
実際には、最新のブラウザで使用されるプロトコル選択/接続設定プロセスには、さらに多くの複雑さがあります。
1つの例は、Happy Eyeballs（はい、本当に！）と呼ばれるアルゴリズムです。これは、いくつかの異なるオプションをテストして選択する方法を説明しています。これは、HTTP/2とHTTP/3のどちらかを選択するために使用されますが、元々発明されたIPv4とIPv6にも使用されます。このアルゴリズムは、通常、異なる接続を互いに「競争」させ、その後「勝者」を選択してページ読み込みを続行します。つまり、HTTP/2が競争に勝った場合、HTTP/3がサポートされていてもHTTP/2が表示されることがあります。このデータはまだデータセットで追跡されていないため、これがどのくらいの頻度で発生するかはわかりませんが、実際には、これはテスト場所や使用されているネットワークにも大きく依存します。
もう1つの例は、接続の合体（私の意見では、単に「接続の再利用」と呼ぶべきだった）という概念です。これは、ブラウザは新しい接続を開く代わりに既存の接続を再利用することを好むべきだというものです。実際には、2つのドメイン（a.comとb.com）が同じTLS証明書を共有している場合、ブラウザはb.com/main.jsを取得するためにa.comへの既存の接続を再利用できます（そしてしばしばそうします）。a.comがHTTP/3を有効にしていてb.comが有効にしていない場合、これが引き起こす頭痛の種を想像できるでしょう… Web Almanacデータセットでこれがどのくらいの頻度で発生するかはまだ分析していませんが、個人的な経験から、これをデバッグする問題から、それは間違いなくそこにあると断言できます！
cdn.shopify.comからリソースを読み込むページのうち、そのドメインへのHTTP/2とHTTP/3の両方の接続が見られるページの割合。
最後に、ブラウザは既存の（HTTP/2）接続が閉じるのを常に待ってから新しい（HTTP/3）接続を開くわけではありません。HTTP/2でのページ読み込みが進行中であっても、はるかに積極的に切り替えようとすることがあります！これにより、「ハイブリッド」なページ読み込みが発生する可能性があり、リアルユーザーモニタリング（RUM）メトリックの解釈やHTTP/2とHTTP/3のパフォーマンスの比較が非常に困難になります。データセットでこれがどのくらいの頻度で発生するかを測定するのは少し難しいですが、個々のページ読み込み中にHTTP/2とHTTP/3の両方の接続が開かれたドメインがいくつあるかを見ることで、アイデアを得ようとしました。とくにサードパーティでは高いデュアルプロトコルの使用が見られ、たとえばconnect.facebook.comは同じページ読み込みで34%の時間でHTTP/2とHTTP/3の両方を見ており、cdn.shopify.comは96%のケースで切り替わっています。ただし、常にこれほど高いわけではありません。www.facebook.comは興味深いことに、使用されているページの12%でしか切り替えが見られず、さまざまなwp.comトラッカーは1〜6%しか示していません（おそらく、これらのドメインから読み込まれるリソースが少なく、切り替える時間/必要がないためです）。1つの注意点は、これらの切り替えは、CORSの理由で新しい接続が必要になったり、iframeで使用されたりするなど、他の要因の影響も受ける可能性があることです。それでも、データは、これらの「ハイブリッド」なページ読み込みが非常に一般的であり、考慮に入れるべきであることを示していると私は信じています。ただし、これがパフォーマンスメトリック（Largest Contentful Paintなど）にどのような正確な影響を与えるか/与えることができるかはまだ不明です。
これらすべては、今日、ネットワーク層で多くのことが起こっているという私たちのこれまでの話を補強するだけであり、データセットから実際の採用を適切に判断することから、CDNサポートなしでプロトコルを自分で展開すること、RUMデータからの結果を正しく分析およびデバッグすることまで、すべてをより困難にします。これらの新しい機能の採用は、大規模な展開からのサポートにより着実に増加していますが、おそらく比較的すぐに横ばいになり、小規模な展開、とくに個人が新しいプロトコルを使い始めるまでには長い時間がかかるでしょう。HTTP/1.1がまだかなりの量で見られるように、HTTP/2もしばらくの間どこにも行かないと予想しています。
おそらく、プロトコルの内部を二度と見たくないと思わせたところで、ALPNやSVCBが何を表すかを理解しなくても、その動作を微調整できるいくつかの高レベルの機能について考えてみましょう。
高レベルのブラウザAPI
この章の最初の部分で見たように、HTTP/2とHTTP/3の採用は増加しており、それは（ほとんどの場合）良いことです。これらの新しいプロトコルは、エンドユーザーに具体的な利益をもたらす多くのパフォーマンスとセキュリティのベストプラクティスを実装しています。しかし、開発者にとって、プロトコルとその機能は、直接調整する方法がほとんどないため、しばしばブラックボックスのままです。基本的には、CDNまたはサーバー構成でチェックボックスをオンにして、ブラウザとサーバーが正しく動作することを期待するだけです。
しかし、ネットワーク上で何が起こるかに影響を与えることができるいくつかの高レベルの機能（画像の遅延読み込み、async/defer javascript属性、リソースヒント、Fetch Priority APIなど）があります。これらは技術的には必ずしもHTTPプロトコルに直接関連しているわけではありませんが、接続確立やリソース多重化などの一部のプロトコル機能が実際にどのように使用されるかに大きな影響を与える可能性があるため、この章でいくつか説明します。
リソースヒント
まず、「リソースヒント」があります。これは、ネットワーク接続の（一部の）設定から、単一のリソースの読み込み、ページ全体の事前フェッチまで、さまざまなネットワーク関連の操作でブラウザをガイドするために使用できるディレクティブのグループです。主なものは、dns-prefetch、preconnect、preload、prefetch、modulepreloadです。エコシステムでその地位を見つけるのに少し苦労したprerenderオプションもありましたが、そのユースケースは現在、主に新しいSpeculation Rules APIに移行しました。
dns-prefetchはすべてのモバイルページの33%（デスクトップでは32%）で使用され、preconnectは28%のページ（デスクトップとモバイル）で使用され、preloadは19%のページ（デスクトップとモバイル）で使用され、prefetchは6%、modulepreloadは1%で使用されています。これらのディレクティブは長年にわたって目覚ましい普及を遂げており、データセットの全ページの30%以上がdns-prefetchを使用し、28%がpreconnectを利用し、preloadは20%に近づいています。
個人的には、dns-prefetchの使用率が高いことにいくぶん驚いています。私の意見では、ほとんどの場合、代わりにpreconnectを使用すべきだからです。preconnectは、無視できるほどのオーバーヘッドでより多くのこと（TCP+TLSまたはQUICハンドシェイクを含む完全な接続の確立）を行い、非常に広くサポートされています。さらに（純粋に逸話的ですが）、開発者が同じドメインに対してdns-prefetchとpreconnectをすぐ後に使用しているのをよく見かけます。これは今日ではほとんど役に立ちません。preconnectは自動的にDNSルックアップも含まれており、前述のとおり広くサポートされているためです。それでも、これらのディレクティブの全体的な使用率が高いことは、パフォーマンスにとって良いことです。重要なアセット（画像やフォントなど）をホストしている可能性のあるサブドメインやサードパーティドメインへの接続設定の遅延を隠すのに役立つためです。
（少なくとも私にとっては）予想外の良いニュースは、これらのヒントを過度に使用しているページが非常に少ないことです。一般的に、プリロードスキャナーなどの機能を通じて、ブラウザが自分で物事を正しく処理することに頼るべきです。リソースヒントは、ブラウザが十分な情報を持っていないとわかっている場合にのみ、控えめに使用すべきです。たとえば、サードパーティのドメイン/リソースがHTMLに直接記載されておらず、CSS/JSファイルにのみ記載されている場合などです。そして、これはまさにほとんどの人が行っていることです（やった！）。90パーセンタイルでさえ、ページは3つのdns-prefetch、2つのpreconnect、2つのpreloadディレクティブしか使用しません。これは素晴らしいことです！
とくにpreloadについては、ページで実際に使用されずに無駄にプリロードされるリソースがいくつあるかも調べました。結果は再び非常に心強いものでした。デスクトップページの4%未満が1つまたは2つのリソースを無駄にプリロードしており、2%未満が3つ以上の未使用のプリロードを持っています！
それでも、ほとんどのページは正しく処理しているように見えますが、最悪の違反者のいくつかを見るのはいつも楽しいです。通常、構成ミスや機能が何をするためのものかについての誤解のために、あまりにも多くのヒントを含んでいるページが常にあります。
たとえば、あるページにはなんと3215個のプリロードがありました！しかし、よく見ると、フレームワークの構成ミス/コードのバグが原因で、まったく同じ画像を何度もプリロードしていることが明らかでした。
2番目に悪い違反者は、「わずか」2583個のプリロードで済ませていました。すべてGoogle Fontsのさまざまなアジアのフォントの異なるバージョン/サブセットでした。最後に、あるページは驚くべき1259個の画像をプリロードし、それらを「滑らかな」スクロール背景アニメーションに変えていました。間違いなく、ここではプリロードが意図した効果を向上させるために良い方法で使用されていると言えるかもしれませんが、一般的にはお勧めしません！
幸いなことに、2024年6月のクロール以降、データセットの最悪の問題ケースのいくつかは修正されています。たとえば、「セクシーな海賊ポーカー」サイトは2095個からわずか14個のプリロードに減りました（そのまま進め、仲間たち！）。
最後の希望の光は、1,000を超えるdns-prefetchまたはpreconnectディレクティブを持つページがなかったことです。最悪のものは、それぞれわずか590と441のドメインを利用していました。
一般的に、リソースヒントは、大きな効果を得るために控えめに使用すべき強力な機能であり、ほとんどの開発者が理解しているようです。それでは、preloadについて具体的に詳しく見ていきましょう。これは、広くサポートされているより強力なヒントの1つであり、（誤って使用された場合）パフォーマンスにプラスとマイナスの両方の大きな影響を与える可能性があるためです。
プリロード
一般的に言えば、preloadは、メインのHTMLドキュメントに直接リンクされていないが、開発者として後で重要/必要になるとわかっているリソースをブラウザに通知するために主に使用すべきです。たとえば、JS fetch()またはCSS @importおよびurl()で動的に読み込まれるものなどです。それらをプリロードすると、ブラウザはサーバーからより早く要求できるようになり、パフォーマンスが向上する可能性がありますが、プリロードしすぎると低下する可能性もあります。
具体的な良い例としては、フォント（通常はCSS経由で読み込まれ、ブラウザが実際にテキストをレンダリングする必要がある場合にのみ要求されます）、動的にインポートされるJSサブモジュールまたはコンポーネント、およびCSSまたはJS経由で読み込まれる（Largest Contentful Paint、LCP）画像（そもそもそうすべきではないかもしれませんが、他に選択肢がない場合もあります）などがあります。
上記で見たように、全ページの約20%がpreloadを利用しており、as属性でプリロードしようとしているリソースの種類を明示的に示す必要があるため、サイトがそれをどのように使用しているかについて、より多くの情報を得ることができます。
preloadを使用しているページの割合を示す棒グラフ。フォントはすべてのデスクトップおよびモバイルページの8.6%でプリロードされ、スタイルシートはデスクトップページの7.6%およびモバイルページの7.5%でプリロードされ、スクリプトのプリロードはデスクトップページの7.6%およびモバイルページの7.3%で見られ、画像はデスクトップページの3.7%およびモバイルページの3.8%でプリロードされ、フェッチコールはモバイルおよびデスクトップページの両方の0.2%でプリロードされます。予想どおり、フォントはプリロードのもっとも人気のあるターゲットであり、ページの約8.6%で発生しています。
しかし、いくぶん予想外だったのは、スタイルシートとスクリプトのプリロードの使用率が高いことでした。これらは概念的には役立つ可能性がありますが、7.5%以上のページがプリロードを必要とする場合、おそらくクリティカルパスの深さを減らすべきです。実際には、人々はHTMLで言及される直前にリソースをプリロードすることで機能を誤用することがよくあります。たとえば、同じファイルの<link rel=stylesheet>の上の行にstyle.cssの<link rel=preload>を置くなどです。これは実際には何も行いません。
私がこれまで見てきたより悪い問題は、人々がasyncおよびdefer JSファイルをpreloadすることです。多くの場合、<body>の下部にある<script>タグを介して読み込まれるものです。これは見た目ほど無害ではありません。これらのプリロードは、実際のレンダリングブロッキングJSや重要な画像など、他のリソースを積極的に遅延させる可能性があるためです。これは、ブラウザがこれらのスクリプトが実際に読み込まれるときにasync/deferとしてタグ付けされることを知らないため、デフォルトではレンダリングブロッキングスクリプトとして高い優先度で読み込むように設定されているためです！。7.5%のページのうち、このようにpreloadを誤用しているページがいくつあるかを確認するためのクエリは実行しませんでしたが、私の個人的な経験から、かなり広まっている可能性があります。
対照的に、おそらくあまりにも多くのasync/defer JSスクリプトがプリロードされている一方で、潜在的にあまりにも少ない JavaScriptモジュール（<script type=module>）がこのヒントの恩恵を受けています。すべてのデスクトップページの約9.6%がすでにJSモジュールを使用していますが（これは驚くほど高いと思いました）、そのうちの約13%（全ページの1.24%）しか少なくとも1つのモジュールをプリロードしていません。JSモジュールメカニズムには動的にコードを読み込むための広範なサポートがあり、パフォーマンスを向上させるためにプリロードの恩恵を受ける可能性があるため、これはもう少し高いと予想していました。
潜在的に、これは、厄介なCORS関連の理由により、JSモジュール専用の特別な種類のプリロード（予測どおりmodulepreloadと呼ばれます）が実際に必要になるためです。この特別な種類を使用するには、あまりにも多くの人が知らないか、JSモジュールが完全に理解されるには新しすぎるか、人々が実際には動的インポートや深いインポートツリーを使用していないためかもしれません。将来のWeb Almanacの分析で明らかになるでしょう。
別の、より肯定的な注意点は、画像をプリロードするページが4%未満であることです。これは、ページの79%（デスクトップ）から69%（モバイル）が画像などの外部ソースURLであるLCP要素を持っているため、はるかに高いと予想していました。
CSSと同様に、HTMLに直接リンクされている画像をプリロードすることは通常かなり役に立ちません（たとえば、imgやpictureタグとして）。ブラウザは通常、プリロードなしでも画像を十分に早く発見するためです。幸いなことに、開発者はこの間違いを頻繁に犯していないようです。データセットでは、LCP要素として<img>を持つすべてのページ（デスクトップで46%、モバイルで41%）のうち、実際にその画像をプリロードしているのは1%未満です（デスクトップで0.7%、モバイルで0.9%）。
対照的に、プリロードの恩恵を受けることができる画像もあります。たとえば、CSSを介して背景画像として読み込まれるLCPなどです。これらは通常、遅れて発見されるためです。データセットでは、デスクトップページの27%とモバイルページの25%がLCP要素として<div>を持っており、これは多くの場合、CSSの背景画像があることを意味します。これらのケースのうち、2.3%（デスクトップ）と2%（モバイル）が実際にLCPリソースURLをプリロードしており、<img>の場合の2倍以上です！これは良いことですが、私の意見では、人々は実際にはこのユースケースでプリロードを過小評価している可能性があります。ただし、LCPの背景画像のみをプリロードすべきであり、他のものはプリロードすべきではないことに注意してください！
鋭い読者は、画像をプリロードするページの総数（約3.8%）がLCP要素をプリロードするページ（合計約1.3%）よりもかなり高いことに気づいたかもしれません。これにより、人々は他にどのような画像を、なぜプリロードしているのか疑問に思います…これも将来の分析に任せるのが最善です！
最後に、一般的なリソースヒントと同様に、外れ値や明らかな間違いを見るのも興味深いです。preloadが機能するには、as属性を設定する必要があり、いくつかの選択されたタイプにしか設定できません: fetch, font, image, script, style, track。それ以外は、プリロードが無駄になります。したがって、17,000以上のページ（全体の約0.11%）が空の値を使用し、0.03%〜0.01%が無効な（ただしありそうな）値（stylesheet、document、videoなど）を利用しているのを見るのは興味深いです。その他の注目すべき（幸いにもはるかに頻度の低い）値には、派手なCormorant Garamond Bold、クールなslick、スパイシーなhabanero、そして超絶技巧的なPoppinsなどがあります。
103 Early Hints
リソースヒントは通常、ページのHTMLの<head>内にある<link rel=XYZ>タグを介して伝えられます。しかし、ご存じないかもしれませんが、リソースヒントはHTMLページのHTTPレスポンスヘッダーでも送信できます（ただし、構文が少し異なります）。実際、ほとんどの人がこれを知らないと確信しています。なぜなら、このオプションを利用しているのは全ページの約0.04%（または約5,500のデスクトップホームページ）にすぎないからです。これは、HTMLタグを使用している約20%と比較されます。しかし、これはあまり驚くことではありません。私の意見では、HTTPヘッダーオプションがHTMLタグオプションよりも簡単または優れているケースは非常に少ないからです。
しかし、（比較的新しい）103 Early Hints機能により、これは少し変わるかもしれません。このメカニズムは、HTTPサーバープッシュの正当な後継者と呼ばれることもあります。これにより、サーバーは、リクエストに対する実際の最終応答（たとえば、200 OKまたは404 Not Found）の前に、中間的な103応答（HTTP 1XX範囲のステータスコードの一部）を返すことができます。
これは、HTMLがCDNエッジでキャッシュされていないCDN設定でとくに役立ちます。そのシナリオでは、CDNはHTMLのリクエストをオリジンサーバーに転送しながら、非常に迅速に103 Early Hints応答をブラウザに返すことができます。この103応答には、preconnectおよびpreloadリソースヒントのリスト（HTTPレスポンスヘッダーとしてエンコード）を含めることができ、ブラウザは最終的なHTML応答が届くのを待っている間に実行を開始できます。
preconnectし、4つのCSSファイルをpreloadするLink:ヘッダーを持つ103 Early Hintsの例を示しています。すべてがうまくいけば、外部ドメインへの接続は準備ができており、プリロードされたリソースはHTMLが届くまでにブラウザのキャッシュにあり、印象的なパフォーマンス向上をもたらします！
残念ながら、103 Early Hintsの採用は、2022年の最初の調査以来、あまり増加していません。当時の全デスクトップページの1.6%から、今年はわずか2.9%にすぎません。しかし、この機能を適切に構成するのは簡単ではなく、完全なメリットを得るには通常、CDNまたは同様に分散されたデプロイメントを使用する必要があるため、これはそれほど驚くことではありません。
サポートもいくぶんまだら模様で、SafariとFirefoxは最近サポートを追加したばかりで（Safariはpreconnectのみを許可）、Cloudflareでしばらく無効になっていました、Akamai CDNは今年7月に一般提供を開始したばかりです。それでも、Cloudflareが2022年から無料の顧客にもこの機能を提供していることを考えると、普及率はもう少し高いと予想していました。
驚くべきことに、Early Hintsの圧倒的多数が1つのデプロイメント、Shopify（Cloudflareの顧客）から来ていることがわかります。これは、Early Hintsをサポートするデスクトップページの2.9%のうち90%を占めています。つまり、新しい機能を採用した非Shopifyのデスクトップホームページは約39,000ページしかありません。したがって、Web Almanacのデータセットで見られるものに基づいて、その真の可能性について広範な結論を導き出すのは困難であり、あまり役に立ちません。
それでも、いくつかの興味深い傾向があります（主にShopifyのデプロイメントから）。preconnectの量は10パーセンタイルから90パーセンタイルまでほぼ安定しています（通常、https://cdn.shopify.com に2回preconnectします。1回はcrossoriginあり、1回はなし）。一方、preloadはp75で1と低く、p90で2に増加します。
興味深いことに、スタイルシートはEarly Hintsで最もプリロードされるリソースタイプであり、スクリプトの約4倍です。フォントはHTMLでのプリロードで最も人気がありましたが、ここでは画像よりも人気がありません。これは非常に奇妙だと思います。私の意見では、フォントはEarly Hintsでもプリロードするのに優れたターゲットですが、画像は避けるべきです。Early Hintsのプリロードは現在レスポンシブ画像をサポートしていないためです（HTMLのプリロードはもちろんサポートしています、心配しないでください！）。
結論として、103 Early Hintsはまだデータセットにいくぶん欠けていますが、より多くのデプロイメントがサポートし、構成が容易になるにつれて、たとえば自動Early Hintsなどで、そしてより多くの人々がその可能性に気づくにつれて、これは時間とともに改善されると感じています！
Fetch Priority API
上記で説明したリソースヒントは、接続が開かれるときやリソースが要求されるときに影響を与えることができますが、その後何が起こるかについてはあまり言及していません。接続はどのように使用されますか？リソースはどのようにダウンロードされますか？それは、Fetch Priority API（以前は「Priority Hints」と呼ばれていました）などの他の機能の範囲であり、HTTP/2およびHTTP/3接続でリソースがどのようにスケジュールされるかを制御するのに役立ちます。
HTTP/1.1からHTTP/2またはHTTP/3に切り替える主な理由の1つは、必要な接続が少なくなることです。新しいプロトコルでは、多くのリソースを単一の接続に「多重化」できます（同時に要求および読み込み）。一方、HTTP/1.1では、同様の効果を得るために複数の並列接続を開く必要があります。各接続には特定のオーバーヘッド（TCP+TLS/QUICハンドシェイク、サーバーでのメモリ、競合する輻輳制御など）が伴うため、設定および維持する接続が少ない方が効率的です。
ただし、ここでの違いは数年前ほど明確ではありません。2021年には、プロトコルバージョン間でp50とp75で4つの接続差がありましたが、現在は3つに縮小しています。これは、HTTPキャッシュのパーティショニング、crossoriginの悩み、またはおそらくより多くのサードパーティが使用されているなどの側面による可能性があります。しかし、新しいプロトコルが実際に接続数を減らし、効率を向上させることは依然として明らかであり、p10では必要な接続は半分しかありません！
しかし、単一の基盤となる接続を共有するリソースが増えた今、通常、すべてを1つの大きな並列フローでダウンロードするのに十分な帯域幅がないため、最初に何をダウンロードするかを何らかの方法で決定する必要があります。この「リソーススケジューリング」は、HTTP/2およびHTTP/3の「優先順位付けメカニズム」によって管理されます。これが実際にどのように機能するかは、ここで詳しく説明するには少し複雑すぎるため、Fetch Priority APIを理解するために必要な基本に焦点を当てます（詳細はブログ投稿、講演、学術論文、そしてもちろんweb.devにあります）。
一般的に、ブラウザは各リクエストに優先度を割り当てます。これは、ページ読み込みにとってどれほど重要かを示すものです。たとえば、<head>内のHTMLドキュメントとレンダリングブロッキングCSSはhighest優先度を取得する可能性がありますが、重要度の低いリソース（<body>内の画像やasyncまたはdeferとしてタグ付けされたJSなど）はlowを取得する可能性があります。サーバーがブラウザから複数のリクエストを並行して受信すると、どの順序で応答するかを知っています。最高の優先度から最低の優先度まで、同じ優先度の値を持つリソースのリクエスト順序に従います。
highの値を使用して画像カルーセルの最初の画像の優先度を上げるFetch Priority APIの例を示しています。一方、lowを使用して、最初に非表示になっている他の画像の優先度を下げています。ブラウザは、リソースの優先度を決定するために、複雑なヒューリスティック（「経験則」）のセットを使用します。HTMLドキュメント内の位置、タイプ、async/deferなどの読み込み修飾子などの要因に基づいています。しかし、これは、ブラウザが間違えることがある、またはより賢明な選択をするのに十分な情報がないことを意味することもあります。
ここでの良い例はLCP画像です。ブラウザは、HTMLからどの画像がLCP要素になるかを正確に予測することはできません。そのため、通常、すべての画像を同じ優先度で、発見順に要求します。したがって、LCP画像がHTMLの下の方にある場合（たとえば、デフォルトで非表示になっているメニューのいくつかの画像の下）、おそらくそうあるべきよりも遅く読み込まれることになります。
これらの理由から、Fetch Priority APIができました！これにより、ブラウザのデフォルトのヒューリスティックを微調整/調整して、個々のリソースに高い（または低い）優先度の値を割り当てることができます。つまり、そうでなければ読み込まれるよりも早く/遅く読み込まれるようになります。これは、リソースにhighまたはlowの値を持つfetchpriority属性を追加することで行われます。
画像だけでなく、<script>や<link>タグ、さらにはfetch()呼び出しなど、多くのものに使用できます（ただし、そこではpriority属性だけです。なぜなら、名前を付けるのは難しいからです）。Fetch Priority APIはChromeでしばらくサポートされており、Safariは昨年後半にサポートを追加し、Firefoxは2024年10月にこの機能を導入しました。それでは、実際にどのように使用されているか見てみましょう！
Fetch Priorityの採用は2024年に飛躍的に増加しました！2023年の約7%から2024年には少なくとも1つのfetchpriority属性を使用するページが26%に増加したのは、本当に驚くべき結果です。多くのページでは1つ以上のインスタンスが使用されており、90パーセンタイルではページあたり2回、デスクトップページでは95パーセンタイルで最大9回使用されています（リソースヒントと同様に、もちろんやりすぎている人もいます。あるページでは信じられないことに2382回も使用されています！）。
fetchpriority=highを持つ<img>タグを持つデスクトップページの割合。
LCP画像にfetchpriorityがどのように使用されているかを見てみましょう。これは、この新機能の主な動機付けとなるユースケースの1つだからです。たとえば、LCPとして<img>要素を持つデスクトップページの46%のうち、12%（または全デスクトップページの5.6%）がfetchpriority=highとしてタグ付けされています。これは間違いなく（はるかに）高くなる可能性がありますが、幸いなことに、LCP <img>をfetchpriority=lowとしてタグ付けしたのはわずか0.14%なので、良しとします！
悲しいことに、これは、16%以上のデスクトップページが依然としてLCP画像を遅延読み込みしているという事実によって相殺されます。これは絶対にすべきではありません…幸いなことに、中にいたいのか外に出たいのかわからない猫によって書かれたページは4,500ページしかありませんでした（したがって、loading=lazyとfetchpriority=highの両方を持つLCP要素があり、これは奇妙です）。
また、LCP画像が一般的にどの初期優先度で要求されたかも調査しました。デフォルトでは、Chromeの画像はlow優先度ですが、HTMLの最初の5つの画像の1つである場合はmedium優先度になります。ブラウザがビューポート内にあると早期に判断した場合、または予想どおりfetchpriority=highが使用されている場合、画像はhigh優先度に昇格できます。
再び、LCPとして<img>要素を持つすべてのデスクトップページを見ると、42%がlowで始まり（したがって、トップ5にさえ入っていません！）、45%がmedium（少し良い）、そしてわずか12%がhighとして要求されています（ほぼ完全にfetchpriority=highによるものです）。したがって、過去2年間でフェッチ優先度が印象的かつ急速に普及したにもかかわらず、多くのページでLCPをfetchpriority=highとしてタグ付けすることで、「手軽な」最適化を行う大きな機会がまだあります。もちろん、最初にloading=lazyを削除した後です！
再びプリロード
fetchpriority属性は<link>タグでも使用できます。これはCSSスタイルシートだけでなく、（ご想像のとおり！）<link rel=preload>にも役立ちます。したがって、上記でプリロードに多くの時間を費やしましたが、フェッチ優先度がここでも本当に違いを生むため、いくつかの追加のニュアンスのためにここで再検討しましょう。
概念的には、プリロード自体はリソースの優先度を変更しません/すべきではありません。ブラウザによって発見され、したがって要求されるときだけです。これは、たとえば画像に当てはまります。LCPをプリロードしても、preloadにfetchpriority=highを追加しない限り、依然としてlow優先度になります。これは、人々にとってしばしば予想外です！
他のケースでは、プリロードは優先度を「変更」するように見えます。たとえば、async/defer JSをプリロードする場合（上記でも説明）、ブラウザはpreloadから十分なコンテキストを取得しないため、lowではなくhigh優先度を割り当てます。これらの場合、JSプリロードでfetchpriority=lowを使用して、ブラウザのヒューリスティックをあるべき場所に「修正」することは非常に役立ちます。
fetchpriority=highが設定されているプリロードのうち、画像である割合。
データセットで人々がpreloadとfetchpriorityをどのように組み合わせているかを見てみました。fetchpriorityを使用したプリロードを持つすべてのデスクトップページ（全デスクトップページの約2%）のうち、印象的な73%がfetchpriority=highの画像用です。これはLCP画像には確かに良い考えですが、いくつかの粗いエッジがあり、<head>の上部で誤って使用するとフットガンになる可能性があります。実際には、ドキュメントの下の方にあるJSを遅延させます。このため、今日では、LCPをプリロードするのではなく、HTMLにfetchpriority=highを直接<img>に付けておくことをお勧めします。
一方、これらのプリロードの16%はfetchpriority=lowのスクリプト用であり、少なくとも一部のウェブマスター（これは2005年か？！）がasync/deferの潜在的な問題を認識しており、それらを防ごうとしていることを示しています。スタイルについては、人々は本当に何を望んでいるのかわからないようです（またはユースケースが多様です）。3%がhighとして読み込まれ、5%がlowとして読み込まれます。これらのニュアンスの多くはweb.devでも議論されているので、そこで必ず読んでください。
最後に、興味深いことに、0.06%のページがfetchpriorityにhighestの値を付けて何かをプリロードしようとしています。これはサポートされていません（highまたはlowしか使用できません）！
まとめ
要約すると、HTTPが1990年代初頭に発明されたにもかかわらず、その第3バージョンは依然としてインターネット上で波紋を広げており、まもなく30%に達するはずの着実に増加する採用を見つけています。これは、DNS HTTPSレコードなどのいくつかの新しい機能の導入によって支援されており、HTTP/3やその他の新しいプロトコル機能の発見と使用をより速く、より簡単にします。
新しいプロトコルバージョンは通常、開発者にとってブラックボックスとして提示されますが（実際、fetch()でHTTP/3を意識的に使用することさえできません）、基礎となる動作を微調整できるいくつかの高レベルの機能が存在します。たとえば、リソースヒントは、103 Early Hints応答内で使用できるようになったため、より強力になりました。これにより、ブラウザはHTMLがわかる前でもプリコネクトおよびプリロードできます。補完的に、Fetch Priority APIは、HTTP/2およびHTTP/3の高度に多重化された接続でサーバーからリソースがダウンロードされる順序を決定するブラウザのヒューリスティックを改善するのに役立ちます。開発者は、これらの機能のいくつかに非常に簡単にたどり着きました（とくにFetch Priorityはわずか2年で25%以上の使用率に上昇しました）が、他の機能には躊躇しています（3%未満の使用率で、103 Early Hintsは使用が難しいか、多くの人に知られていないようです）。
それでも、まだ課題は残っています。CDNは、これらの新しいテクノロジーの多くが急速に採用される原動力となっています（全HTTP/3トラフィックの85%がCDNを介して提供されました）。これは、私の意見では、エコシステムにとって「良い」面と「悪い」面の両方があります。良い面は、新しいテクノロジーを迅速に実戦テストし、すぐに大きな市場シェアを与えることで、生存の可能性を確保することです。悪い面は、これによりウェブがいくつかの大企業を中心にますます中央集権化し（データセットの全リクエストの54%がCDNから提供されました）、それらを使用しない人々が取り残されるリスクがあることです。
これは、ウェブが下位層でどのように機能するかの複雑さの増大と密接に関連しています。HTTP/3のようなプロトコルは理解するのが複雑で、ましてや展開するのは困難ですが、「より単純な」高レベルの機能でさえ、実際に正しく適用するのは難しい場合があります（プリロードされたスクリプトの量が多いのはいくぶん懸念されます）。誤用や自滅の可能性は十分にあり、すべてがそうあるべきほど十分に文書化されているわけではありません（LCP画像を遅延読み込みするページの16%がその証拠です）。
それでも、私はここに明確な希望の光を見ています。人々が犯す間違いを探すのが私の仕事ですが（そうすれば修正を手伝うことができます！）、明らかな間違いのほとんどが、個人的な経験から時々思われるほど広まっていないことに pleasantly surprised しました。これらの新しい機能がより広いウェブでさらに採用されるにつれて、そのままであることを願いましょう。うまくいけば、開発者がネットワークプロトコルの基礎となる機能に慣れるにつれて、固有の複雑さの一部が採用の障壁でなくなり、HTTP/3でさえCDNのルーツを超えて移動できるようになるでしょう。それを実現するために協力しましょう！
