...
ウェブホスティングのロゴ

DNSプリフェッチとプリコネクトがロード時間を大幅に短縮できる理由

DNSプリフェッチング Preconnect は、ブラウザが DNS、TCP、TLS を実際の呼び出し時に起動するのではなく、事前に準備するため、最初の応答までの時間を短縮します。これにより、私は複数の 往復 これは、特にモバイル接続の場合、数百ミリ秒から1秒程度をすぐに消費します。.

中心点

  • 早期解散: DNSルックアップを優先し、待ち時間を短縮する
  • 完成した接続: プリコネクトによる TCP/TLS の提供
  • 重要な資源: フォント、スクリプト、API を高速化
  • 測定可能に優れたFCP/LCP および TTFB を最適化
  • スリムな選択: 重要なドメインのみ優先的に扱う

DNSプリフェッチとプリコネクトが時間を節約する方法

ブラウザがファイルをロードする前に、 DNSルックアップ, 、その後TCPおよびTLSハンドシェイクが続きます。各段階では、ネットワーク上で往復通信が発生し、通信量が増えると レイテンシー 顕著な効果があります。DNSプリフェッチは、リソースがパーサーに現れる前に名前解決がすでに実行されているため、最初のステップの負担を軽減します。プリコネクトはさらに進んで、暗号化を含む接続を積極的に構築します。これにより、実際のファイルの取得が、さらなる遅延なく直接開始できるようになります。.

ブラウザへのこの準備的な指示は、 リソースのヒント そして、彼らは実際のデバイスで速度を低下させる要因、つまりネットワークの起動コストに焦点を当てています。私は、外部リソースの最初のバイトまでの時間を最小限に抑え、 エフシーピー および LCP に影響を与えます。特にサードパーティのウェブサイトでは、フォント、タグマネージャー、CDN が早期に利用可能になります。これにより、最初の表示がスムーズになり、操作が著しく高速化されます。その結果、ウェブサイトは「隠れた」接続の確立を待つことなく、反応が速い印象を与えます。.

限界、副作用、そして合理的な制限

ヒントは確かに役立つけど、どこでも自由に予習できるってわけじゃないよ。早期の解答や関連付けは、一時的にコストがかかるんだ。 リソース: オープンソケット、TLS用CPU、モバイルモデムの電波切り替え、そして潜在的なエネルギー消費量の増加。HTTP/2/3では、並列ストリームは効率的ですが、1つのオリジンあたりの同時接続数は限られています。したがって、私は以下の点を考慮しています。

  • 接続スロット: プレコネクトが多すぎると、他の重要な転送がブロックされる可能性があります。.
  • バッテリー：モバイルデバイスは、より少ないが的を絞ったウォームアップの恩恵を受けます。.
  • キャッシュヒット: OSキャッシュでのDNSヒットは、追加のプリフェッチの利点を打ち消します。.
  • タイムアウト: 事前接続は、使用されない場合、ブラウザによって切断されることがあります。.
  • コンプライアンスサードパーティの場合、プレコネクトだけで接続が開始されることがあるため、同意（コンセント）を得る前に望ましくない結果になる可能性がある。.

したがって、私は以下を扱います。 分析/広告 保守的：DNSプリフェッチは最大、同意後にのみプリコネクト。 フォント/CDN 或いは 重要なAPI その有用性が確実であるため、私は意図的にPreconnectを早期に設定しています。.

実践：どのヒントがいつ有用か

をセットした。 DNSプリフェッチ 繰り返しアクセスするドメインで、複数のファイル（フォント、アナリティクス、CDN など）が配信されている場合。これにより、重要な要素が表示される前に、繰り返しの DNS 解決を省くことができます。表示部分が大きく依存するドメインについては、以下を選択します。 プリコネクト. これは、多くの場合、フォントソース、メインCDN、または中央APIエンドポイントに関係します。重要度の低いプロバイダについては、多くの場合、早期のネーム解決だけで十分です。.

ここでは、少ないほど良いと言えます。なぜなら、事前接続が多すぎると、ネットワークに一時的な負荷がかかり、他の場所で不足しているスロットを占有してしまうからです。そのため、私はまず最初の候補をいくつかリストアップし、測定を行った後にそのリストを拡張しています。コンテンツ配信では、この情報を CDNのウォームアップとプリフェッチング, エッジノードが早期に反応するようになります。この相互作用により、地理的なレベルでの待ち時間がさらに短縮されます。その結果、最初の呼び出しが著しく高速化され、後続のページもスムーズに表示されます。.

HTMLの実装：スニペットと落とし穴

実装 ヘッド 短くて効果的です。よく使うフォントドメインには、以下を使用しています。 <link rel="dns-prefetch" href="//fonts.googleapis.com">. 。そのために、プロトコルとCORSを使ってPreconnectを設定します。 <link rel="preconnect" href="https://fonts.googleapis.com" crossorigin>. 属性 クロスオリジン 後で CORS ルールでリソースが読み込まれる場合に役立ちます。ブラウザがすぐに処理できるように、このタグは最上部近くに配置しています。.

純粋に DNS ベースの前処理には、プロトコルに依存しない表記を使用します。 //example.com, 、Preconnect では、私は https://. DevTools で、ブラウザが実際に早期に接続を確立しているかどうかを確認します。一部のブラウザはすでに推測を行っていますが、明示的なヒントによって、私の最も重要なエンドポイントが優先されます。サードパーティのドメインをすべて予熱しないように注意しています。そうすることで、 ネットワーク負荷 小さくても、決定的な数ミリ秒を勝ち取ろう。.

サーバーサイド配信：リンクヘッダーと 103 アーリーヒント

HTMLにヒントを設定する必要はありません。 HTTPリンクヘッダー サーバーは、HTML が到着する前に、ブラウザに同じ信号を送信することができます。 103 初期のヒント サーバーが実際の応答をレンダリングしている間に、DNS/接続が並行して起動する可能性が高くなります。.

HTTP/1.1 103 早期ヒント リンク: ; rel=preconnect; crossorigin リンク: ; rel=preconnect; crossorigin リンク: ; rel=dns-prefetch HTTP/1.1 200 OK
...

重要：ヘッダーでは、常に 絶対 プロトコル付きURL。HTMLバージョンと同じで、両方が一貫性を保てるように、リストはシンプルにしています。.

ブラウザのサポートと特徴

主要なブラウザは DNS プリフェッチとプリコネクトをサポートしていますが、微妙な違いがあります。

  • サファリ プレコネクト接続を保守的に構築することが多い。ドメインが本当に早く必要になる場合は、このヒントが役に立つ。.
  • Firefox ヒントを尊重しますが、独自のヒューリスティックを優先します。そのため、ヒントが多すぎると、期待したほど効果がない場合があります。.
  • クローム 投機ではより攻撃的ですが、明確なヒントは優先順位において重要な起源を強調しています。.
  • HTTP/2/3 の結合：同じ証明書で、1つの接続が複数のサブドメインに対応できる。 唯一の そのため、ターゲットを絞ったプレコネクトで十分である。.

詳細： クロスオリジン のために プリコネクト 関連性のある、 dns-プリフェッチ 効果がない。それでも、特に後でフォントやAPIがCORSで読み込まれる場合は、Preconnectで統一して設定する。.

追加の優先度：プリロード、フェッチ優先度、順序

ヒントは補完し合うことができます：Preconnect は扉を開きます。, プリロード 必要なファイルをアクティブに取得します。 フェッチプライオリティ さらに、ブラウザに、本当に最初に表示すべきものを指示することもできます。.

<link rel="preconnect" href="https://cdn.example.com" crossorigin>
<link rel="preload" as="image" href="/hero.jpg" fetchpriority="high">
<img src="/hero.jpg" alt="ヒーロー" fetchpriority="high">

私は、ファイルが 間違いなく それが必要なんだ。そうしないと、パイプが詰まるリスクがある。ヘッダーの順番は重要だよ：ヒントを一番上に、次に重要なプリロード、その後にスタイルとスクリプトを置くんだ。.

プラグインなしのWordPress：クリーンな統合

時点では ワードプレス ドメインを一元的に保存し、タグを wp_head 配列を使った小さな関数で十分です。この関数は、ターゲットドメインを反復処理し、それぞれプリフェッチタグとプリコネクトタグを記述します。この関数を非常に低い優先度でフックに追加し、ヘッド領域の先頭に配置します。これにより、すべてのテンプレートが恩恵を受け、リストは 1 か所だけで管理できます。これにより、重複したエントリが回避され、 テーマコード スリムだ。

例： $origins = ['//fonts.googleapis.com','//cdn.example.com']; それから： echo ''; およびオプション echo '';. ソースコードで、出力が本当に一番上にあるか確認するよ。それから、DNS、TCP、TLSフェーズが早く始まるか測るんだ。そうすることで、実際の ユーザー から、後で使用しないドメインを削除してください。.

WordPress を深く掘り下げる：wp_resource_hints と同意の管理

WordPress は、 wp_resource_hints 統合インターフェース。そこに Preconnect/DNS-Prefetch を入力して、テンプレートコードの負荷を軽減します。さらに、サードパーティ向けのヒントも追加できます。 同意 連結する。.

add_filter('wp_resource_hints', function($hints, $rel){
  $critical = ['https://fonts.googleapis.com', 'https://cdn.example.com'];
  if ($rel === 'preconnect') { $hints = array_merge($hints, $critical); }
  if ($rel === 'dns-prefetch') {
    $hints = array_merge($hints, ['//fonts.googleapis.com', '//cdn.example.com']);
  }
  return array_values(array_unique($hints));
}, 1, 2);

同意が必要なサービスについては、小さなクエリ（クッキー、サーバーフラグ）を組み込み、同意を得た後にのみプレコネクトを実行します。これにより、サードパーティシステムへの時期尚早な接続を回避します。.

推測ではなく測定：私のテストワークフロー

私は基本的なランニングから始めます。 灯台, 、DevTools、および合成テストを使用します。次に、ヒントを追加し、同一のネットワークプロファイルでメトリクスを比較します。特に、外部ソースの TTFB、Above-the-Fold の FCP および LCP に注目しています。ウォーターフォールビューで、DNS、TCP、TLS がより早く開始されているかどうかを確認します。まさにその部分で効果が確認できなければ、ヒントを再度削除します。.

私は複数のネットワーク環境とデバイスでテストしています。 モバイルラジオ ラウンドトリップの影響をより強く受ける。WebPageTest や類似のツールで、ファーストバイト、スタートレンダリング、ビジュアルコンプリートをチェックする。ドメインのリストは少なく抑え、スプリントで調整する。変更は、その効果を明確にするために、変更前後のグラフで裏付ける。そうすることで、ブラウザに過度な負担をかけることなく、最適化の効果を維持できる。.

DevToolsの検証：成功したヒントを認識する方法

ネットワークビューでは、典型的なパターンに注意を払います。

  • 初期の DNS/TCP/TLS フェーズ 後続のリクエストなし：これはプレコネクトのヒットです。.
  • コネクションの再利用: 後のリクエストはダウンロードに直接ジャンプします。DNS/TCP/TLS にはウォーターフォールバーが表示されません。.
  • イニシエーター「その他」„: 一部のツールはヒントをこのように表示します。ヒントの有無による起動時間を比較します。.

さらに、同時接続数が許容範囲内にあるかどうかも確認します。ヒントが未使用のまま期限切れになった場合は、そのヒントが時期尚早だったか、あるいは不要だったということなので、その数を減らします。.

プリロード、プリフェッチ（ナビゲーション）、HTTP/3 との連携

DNSプリフェッチングとプリコネクトは、 リソースのヒント, 、プレロードおよびプレフェッチと組み合わせて、今後のナビゲーションに使用します。プレロードは、重要な CSS ファイルやフォントなど、確実に必要であり、非常に早い段階で利用可能にする必要があるファイルに使用します。ナビゲーションプレフェッチは、予想される後続ページで、その可能性を予測できる場合に役立ちます。HTTP/3 はさらに、 レイテンシー, 接続の確立とパケット損失は異なる方法で処理されるためです。この件については、ある記事で背景情報を読みました。 HTTP/3 とプリロード.

これらの技術を分類するために、以下の表で概要を簡単に示します。「おそらく必要」と「確実に必要」を明確に区別することで、ブラウザが優先順位を適切に設定できるようになっています。適切な組み合わせにより、過負荷を防ぎ、初期のヒントのヒット率を高めることができます。これにより、ネットワークを混雑させることなく、重要なものを早期に読み込むことができます。これにより、 効率性 チェーン全体。.

ヒント 目的 代表的な使用例 HTMLの例
DNSプリフェッチ 初期 名前解決 同じサードパーティドメインの複数のファイル <link rel="dns-prefetch" href="//cdn.example.com">
プリコネクト 昔 TCP/TLS-構築 クリティカルフォント、中央CDN、Above-the-Fold用API <link rel="preconnect" href="https://cdn.example.com" crossorigin>
プリロード 昔 ファイル検索 優先度の高い、確実に必要な CSS/フォント/画像 <link rel="preload" as="style" href="/critical.css">

特別なケース：フォント、結合、証明書

時点では フォント 利益が特に高くなる場合が多い。私はスタイルシートドメイン（例えば、CSS宣言のAPI）と、既知であれば、バイナリファイルを提供するドメインにプリコネクトします。さらに、意味のある フォント表示, レイアウトジャンプを減らすため。アバブ・ザ・フォールドの資産が多い画像CDNの場合は、HTTP/2/3が同じ接続で複数のファイルを効率的に転送するので、単一のプレコネクトが有効です。.

と一緒に 接続の結合 ブラウザは、証明書とALPNが一致する場合、複数のホストに対してH2/H3接続を利用できます。その場合、多くの場合、中央のオリジンへのプレコネクトで十分です。これにより、追加のハンドシェイクなしで隣接ホストへのリクエストが高速化されるかどうかを測定します。.

SEOとユーザー体験への影響

LCP や INP などの Core Web Vitals は、 ネットワークの起動 およびブロック。DNSプリフェッチとプリコネクトを正しく設定すると、フォントや重要なスクリプトが早く表示されます。これにより、表示の構築が改善され、テキストが後でジャンプするリスクが減少します。ユーザーはより早く操作を開始でき、待ち時間が短縮されます。これらの効果により、離脱率が低下し、ポジティブな 信号 検索エンジンへ。.

測定値だけでなく、体感速度も重視しています。最初のレンダリングが速いほど、そのセッション全体の期待値が高まります。スムーズに起動するサイトは、ユーザーに長く滞在してもらえる傾向があります。これはコンバージョン率と信頼性の向上につながります。このように、小さなコードの工夫が大きな効果をもたらすのです。 ＳＥＯ そして販売。

ホスティング：増幅器としてのインフラストラクチャ

優れたリソースヒントは、高速な環境でその潜在能力を最大限に発揮します。 プラットフォーム. 遅いサーバーはメリットを台無しにする一方、HTTP/2 または HTTP/3 による高速の「プレコネクトホスティング」はメリットを何倍にも増やします。私は、応答時間の短さ、クリーンな TLS、サーバー側での適切なキャッシュに注意を払っています。比較すると、パフォーマンスを優先するホスティング環境が優れています。ここでは、節約した分だけ見返りがあります。 ミリ秒 2倍になる。.

演算能力に加えて、DNS設定も重要だよ。TTLが短いと変更が速く反映されて、CDN経由の配信がスムーズになるんだ。詳細を読む 最適なDNS TTL エントリが変更される頻度を評価します。プリフェッチおよびプリコネクトと組み合わせることで、高速な解決と迅速なハンドシェイクを実現します。これにより、名前からコンテンツまでのチェーンが厳密に保たれます。これにより、 一貫性 各拠点間の読み込み時間。.

データ保護とガバナンス

Preconnect はすでに 個人関連データ IPアドレスをサードパーティに送信する方法。規制のある環境では、同意を得た場合にのみ、このような接続を許可しています。純粋に機能的で必要なリソース（自社のCDNなど）については、Preconnectはそれほど重要ではありません。どのヒントをどのような理由で設定したかを記録し、同意管理と関連付けています。これにより、パフォーマンスとコンプライアンスのバランスを保っています。.

実践例と典型的なドメイン

フォントに関しては、Preconnect を使用しています。 fonts.googleapis.com また、静的フォントファイルドメインにはオプションで設定します。これにより、テキストのレンダリングが遅延することなく、レイアウトの乱れも発生しにくくなります。ショップのメイン CDN には、スタートセクションの重要な画像が早期に表示されるよう、Preconnect を設定しています。トラッキングやチャットウィジェットの場合、表示の構築が優先されるため、多くの場合 DNS Prefetch で十分です。このように設定しています。 優先順位 そして視認性も実用的です。.

API駆動のサイトでは、Above-the-Foldデータを配信するエンドポイントにはPreconnectを選択します。後読み込みされるモジュールについては、別ドメインのPrefetchで十分です。サードパーティがHTTP/2/3を提供しているかどうかを確認し、複数のファイルが1つの接続で流れるようにします。これにより、各Preconnectヒントの効果が向上します。テストのためにサービスを削除し、 ベースライン-違いを測定する。.

典型的なエラーパターンとそれを回避する方法

  • 未使用ドメインのヒント：測定によってそれらを排出させ、除去します。.
  • 誤った議事録: プレコネクトの場合は常に https:// 活用しなければ、その効果は失われてしまいます。.
  • 重複したエントリ: 集中管理、重複排除。.
  • プレコネクトが多すぎる：10人の中程度の候補者よりも、3人の優秀な候補者の方が良い。.
  • crossorigin を忘れる: CORS リソースへの事前接続を設定して、後々の障害を回避しましょう。.
  • プリコネクトではなくプリロードが必要: ファイルが確実に必要になる場合は、直接プリロードしてください。.

実施および保守に関するチェックリスト

まず、すべての外部監査から始めます。 情報源: フォント、CDN、スクリプト、API。その後、重要なドメインをプレコネクト用にマークし、残りをプリフェッチに割り当てます。タグをヘッドの上部に設定し、公開して、ネットワークプロファイルごとに少なくとも 3 回の実行を測定します。リストは最小限に抑え、定期的に整理しています。これにより、 効果 維持し、ページをスリムに保ちます。.

次に、その他の手法が有効かどうかを確認します。重要な CSS ファイルやメインフォントのプリロードなどです。HTTP/3 を確認し、サーバーと CDN チェーンが正常に応答しているかどうかを検証します。コンテンツのトラフィックが急増する場合は、CDN のウォームアップを短時間実施する予定です。変更点はすべて、変更履歴のようなメモに記録します。この継続的なメンテナンスにより、 透明性 パフォーマンス作品。.

簡単な要約

と一緒に DNSプリフェッチング ドメインを早期に解決し、Preconnect を使用して TLS を含む完全な接続を準備します。どちらもラウンドトリップを節約し、コンテンツが表示されるまでの時間を短縮します。少数の重要なドメインを選択し、その効果を測定して、リストを整理します。Preload、HTTP/3、および優れたホスティングと組み合わせることで、その効果はさらに高まります。構造化された事前対応を行うことで、顕著な効果を得ることができます。 ミリ秒 UXとSEOを向上させます。.

現在の記事