コンテンツにスキップ 
DNSプリフェッチとプリロードは、DNS、TCP、TLSを早期に起動し、重要なファイルを事前に提供することで、最初にコンテンツが表示されるまでの時間を積極的に短縮します。以下の使い方をお見せします。 DNSプリフェッチング, プリコネクトとプリロード ウェブサイト速度 コード、WordPressのセットアップ、試行錯誤を重ねた優先順位など、注目すべき点が多い。.
中心点
- DNSプリフェッチ早期の名前解決は待ち時間を短縮する。.
- プリコネクトあらかじめDNS、TCP、TLSを開いておく。.
- プリロード重要なファイルには積極的に優先順位をつける。.
- 優先順位付け数は少ないが、決定的な領域。.
- モニタリング滝のエフェクトをチェック.
DNSプリフェッチ：簡単に説明
と一緒に DNSプリフェッチング ブラウザはファイルをロードする前にあらかじめドメインのIPを解決するため、ドメインごとに20～250ミリ秒を節約できる。 レイテンシー. .例えば、フォントやアナリティクス、CDNなどのために必要な外部ホストのヒントをアバブエリアに設定する。ブラウザはバックグラウンドでDNSルックアップを実行し、最初のレンダリングまでのクリティカルパスを短縮します。最近のブラウザーは自動的にプリフェッチを使用することがありますが、私は明確なヒントを頭に入れて効果を確認しています。これにより、ラウンドトリップが減少し、初期のレンダリング開始が安定し、レンダリングプロセスが高速化します。 コアウェブ・バイタル.
を参照してください。
</link
相違点：DNSプリフェッチとプリコネクトの比較
プリフェッチは DNS-一方、PreconnectはTCPとTLSのハンドシェイクを開始し、接続を温存する。CSSやウェブフォントをレンダリングするCDNのようなクリティカルなホストには、PrefetchよりもPreconnectの方がいい。開いているソケットがすべてブラウザのスロットを占有するので、私は控えめに使っている。属性 クロスオリジン はCORSを持つ全てのホストに属し、後のリクエストが遅くならないようにする。選択と順序の明確な概要は、コンパクトな プリフェッチ・ガイド.
プリロード：特定ファイルのプリロード
特定の予荷重 ファイル パーサーが通常それらを要求する前に積極的にキャッシュに入れることで、FCPとLCPを高速化します。私は、重要なCSS、ヒーロー画像、WOFF2フォントなど、確実に必要なリソースにのみ使用しています。属性 フェッチプライオリティ は、他の重要な転送を完全に置き去りにすることなく、重み付けを上に向ける。私は、MIMEタイプ、as属性、実際の使用量が一致していることをチェックしている。の記事で説明されているように、HTTP/3は良い追加である。 HTTP/3 とプリロード と説明した。
ホスティング・セットアップのパフォーマンス向上
手っ取り早く ホスティング 低RTT、HTTP/3、近くのCDNがステージごとの待ち時間を短縮するためです。DNS、TCP、TLSが予熱され、Originが素早く反応するようになると、TTFBが最大1秒下がるのを定期的に見ています。遅延の大きいモバイルデバイスでは、節約されたラウンドトリップがそのままLCPに反映されるため、2倍の利益が得られます。私は、安定したTLS処理、OCSPステープリング、無駄のないTLS設定に注意を払っています。こうすることで、ブラウザーは少ない同時接続を最適に利用し、TLSを高速化することができます。 ウェブサイト速度.
簡単な比較：何のための技術か？
次の表は、効果、用途、タグの例をまとめたもので、各ホストに適した対策を選ぶのに役立ちます。私は、幅の広いホストにはプリフェッチ、重要なホストにはプリコネクト、重要なファイルにはプリロードを組み合わせています。同時に開いているコネクションの数は少なめにしています。これにより、パーサーの発見やレイトクリティカルなアセットのために十分なスペースを残すことができます。この概要では、次のような判断を下す。 優先順位付け 楽になった。.
| テクノロジー | 何が起こるのか | 代表的な使用例 | タグの例 | FCP/LCPへの影響 |
|---|---|---|---|---|
| DNSプリフェッチ | 初期 名前解決 | 後からリクエストされた外部ホスト | <link rel="dns-prefetch" href="//fonts.googleapis.com"> | レイテンシーによるが、中程度にポジティブ |
| プリコネクト | DNS + TCP + DNS + TCP ティーエルエス 予熱する | CDN、フォント、重要なAPI | <link rel="preconnect" href="https://cdn.example.com" crossorigin> | 往復の旅費を節約できる。 |
| プリロード | ファイル・アクティブ プリロード | クリティカルCSS、WOFF2、ヒーローイメージ | <link rel="preload" as="style" href="/critical.css"> | 正しく選択すれば、非常にポジティブ |
ワードプレスとの統合：クリーンでメンテナンスが容易
WordPressでは、ヒントをかなり早い段階で設定します。 ヘッド, パーサがボトルネックになる前に、ブラウザがそれらを見るようにする。ホストの重複排除を行い、https の存在を確認し、ブラウザに クロスオリジン は必要な場合のみ。以下のコードでは、エントリーを一番上に配置し、効果を最大にしています。また、デプロイ後に新しい外部ホストが追加されていないかチェックします。こうすることで、ヒントリストが無駄なく、最新に保たれ 効率的.
関数 add_dns_prefetch() { 以下のようにします。
$domains = ['//fonts.googleapis.com', '//www.googletagmanager.com', '//cdn.webhoster.de', 'https://fonts.gstatic.com']；
$printed = []；
foreach ($domains as $domain) { $key = preg.
$key = preg_replace('#^https?:#', '', $domain)；
if (isset($printed[$key])){ continue; }.
$printed[$key] = true；
echo '' ."\n";
if (strpos($domain, 'https://') === 0) { .
echo '' ."\n";
}
}
}
add_action('wp_head', 'add_dns_prefetch', 1)；;
ベストプラクティス：簡潔だが効果的
プレコネクトは3～5回に制限している ホスト, そうしないと、ブラウザが早々に多くのソケットをブロックしてしまうからだ。私はいつもヒントを頭の最初に置き、次にプリロード、そしてスタイルとスクリプトを置きます。フォントについては、プレコネクトと フォント表示：スワップ, そうすれば、テキストはすぐに表示され、CLSは低いままです。そうでなければ、帯域幅を無駄にし、必要なものに優先順位をつけていないことになる。サードパーティのスクリプトについては、すべての ドメイン 必要である。.
測定とモニタリング：成功を可視化する
DevToolsの "Network "タブで、次の順番を確認する。 DNS, TCPとTLSが以前より早く開始されたかどうかをチェックする。ウォーターフォールの前後を比較すると、ヒントが機能しているかどうかがはっきりとわかる。私はLighthouseやPageSpeed Insightsを使って、FCP、LCP、CLSやTTFBの傾向を観察している。WebPageTestはまた、レンダリング開始を記録する接続ビューとフィルムストリップを提供する。大きな変更があった後、私は測定を繰り返し、古いものを削除する。 ホスト ヒントリストから.
HTTP/3、QUIC、コネクション合体
QUIC経由のHTTP/3では、さらに次のことを節約できる。 往復, なぜなら、接続設定、損失処理、多重化がより効率的に機能するからです。私はCDNとオリジンがHTTP/3を提供しているかどうかをチェックし、選択的にPreconnectを使い続けている。コネクションの合体により、証明書とIPが一致する場合、別々のコネクションの数が減ります。これによって、同じ証明書を持つホストが、複数のサブドメインに共通の 接続. .全体的に、早いレンダーパスは、特に小さなファイルが多い場合に大きな利益をもたらす。.
CDNのウォームアップとプリフェッチを組み合わせる
私はトラフィックのピークが予想されるときにCDNをヒートアップさせ、これを次のように組み合わせる。 プリフェッチ とエッジホストのプリコネクトがある。これは、重要なオブジェクトがエッジ・キャッシュに保存され、ハンドシェイクがすでに準備されていることを意味する。これにより、特に最初の通話やモバイル環境下での待ち時間が短縮されます。実践的な手順は、以下の記事で見ることができる。 CDNウォームアップ, 私はこれをチェックリストとして使っている。ロールアウトの前に、私はキャッシュのヒット率をテストし、その結果を観察する。 TTFB-開発。.
ガバナンス：ヒントリストを常に最新の状態に保つ
私は短距離走を指導している。 インベントリー すべての外部ホストに新しいスクリプト、フォント、画像が追加されたかどうかを四半期ごとにチェックします。リストをすっきりさせるために、削除した統合はヒントと一緒に削除します。各ホストについて、目的、重要度、使用されている技術（プリフェッチ、プリコネクト、プリロード）を記録します。CDNやフォントの変更はすぐに入力し、孤立したエントリーが残らないようにしています。これにより、私はコントロールを維持し、オーバーヘッドを削減し、一貫した パフォーマンス.
ブラウザのサポート、ヒューリスティック、制限
ブラウザのヒントを次のように計算する。 信号 コマンドではありません。低帯域幅、アクティブなデータセーバー、またはバックグラウンドのタブでは、ブラウザは優先順位を調整したり、ヒントをスロットルすることができます。サファリはプリコネクトに対してより保守的で、ファイヤーフォックスは場合によってはDNSキャッシュに対して異なるヒューリスティックを持ち、モバイルの亜種はパラレルソケットを減らす。そのため、私は次のようなヒントを用意している。 正確に と過剰シグナリングの回避：少数のホストで、明確な として-値、正しい タイプ-情報フォントについて、私は以下の点に注目している。 クロスオリジン, そうでなければ、二重フェッチや遅いCORSブロックのリスクがある。プリフェッチを完全に制御したい場合は 。 或いは オフ 自動ヒューリスティックに影響を与える。.
HTTPヘッダーと103の初期ヒント
HTMLタグの他に、私は以下のものを使っている。 リンクヘッダ, サーバサイドレンダリングに最適です。103 アーリーヒントは、以下のヘッダも送信します。 曩に その結果、長い回線で数十ミリ秒を稼ぐことができる。.
# NGINX: リンクヘッダによるプレコネクトとプリロード
add_header Link '; rel=preconnect; crossorigin' 常に；
add_header Link '; rel=preload; as=style; fetchpriority=high' 常に；
add_header リンク '; rel=preload; as=font; type=font/woff2; crossorigin' 常に；;
# Apache (htaccess)
ヘッダ追加リンク '; rel=preconnect; crossorigin'
ヘッダ追加リンク '; rel=preload; as=image'
サーバーは 103 初期のヒント, リンクヘッダも早めに送る。重要 短い, というのも、各エントリーが解析の手間とコネクションオープンの可能性を発生させるからだ。.
SPAとサービスワーカー：ルートとデータのプリフェッチ
単一ページのアプリの場合、私はヒントを移動する。 状態ベースヒーローが表示されるとすぐに、次のルート（JSチャンク、クリティカルイメージ、APIスキーマ）のためのターゲットプリロードを開始する。Service Workerでは、プリロードの結果をキャッシュし、ナビゲーションイベントの後に使用することができる。プリフェッチがコストドライバーにならないように、明確なキャンセル基準（タブが隠れている、CPUがオーバーロードしている、ネットワークが弱い）を定義しています。ESモジュールには、早い段階で モジュールプリロード, 依存関係の連鎖が遅くならないように。.
をクリックしてください。
セキュリティ、データ保護、ガイドライン
私は政策の枠組みについて考えている。 せいやくじゅうそくもんだい の場合、プリロードをブロックすることができる。 フォントソース, スタイル・ソース 或いは img-src ターゲットを許さない。. クロスオリジン はフォントに必須であり、そうでなければキャッシュはすべてのオリジンで機能しない。すべてのヒントはブラウザへのシグナルであり、追跡スクリプトを加速させる可能性がある。また セーブデータ そして データセーバーこれらのモードでは、プリロードのアグレッシブさを減らし、セントラルホストのDNSプリフェッチだけをアクティブにしておく。.
計測の実践を深める：タイミングAPIとログ
滝のほかにも、私は次のようなものを使っている。 リソースタイミングAPI そして パフォーマンスオブザーバーのために 現場にて ヒントをパーサーの前に置くかどうか、またどのように置くかを測定する。 ドメイン検索開始, コネクトスタート そして セキュアコネクション開始 移動します。これにより、プレコネクトが本当に使用されたのか、それともブラウザによって拒否されたのかを認識することができる。.
new パフォーマンスオブザーバー((リスト) => {)
for (const e of list.getEntriesByType('リソース')){
if (e.name.includes('fonts.gstatic.com')){
console.log('DNS:', e.domainLookupEnd - e.domainLookupStart、
'TLS:', e.secureConnectionStart > 0 ? e.connectEnd - e.secureConnectionStart : 0、
'Start:', e.startTime.toFixed(1))；
}
}
}).observe({ type: 'resource', buffered: true })；
</script
このデータをサーバーログやCDNの統計（TLS再開率、HTTP/3シェア、キャッシュヒット）と比較する。TLSがほとんど常に再開されることがわかれば、アクティブなプリコネクトの数を減らし、パーサー検出用のスロットを解放することができる。.
WordPress徹底解説：コアフィルターをきれいに使う
WordPressには、リソースヒントのためのインフラがすでに備わっている。私は wp_resource_hints, そして、重複排除されたターゲットだけを渡す。プリロードには wp_enqueue_style/wp_enqueue_script を追加する。 として-属性 wp_style_add_data.
// コアフィルタによるプリコネクトとDNSプリフェッチ
add_filter('wp_resource_hints', function($urls, $relations_type) { { $critical = [...
$critical = [
'preconnect' => ['https://fonts.gstatic.com', 'https://cdn.example.com']、
'dns-prefetch' => ['//fonts.googleapis.com', '//www.googletagmanager.com', '//cdn.webhoster.de'].
];
if (!empty($critical[$relation_type])){
if (!in_array($u, $urls, true)) { $urls[] = $u; }.
}
return $urls；
}, 10, 2);
// プリロードを正しくエンキューする
add_action('wp_enqueue_scripts', function() {
wp_enqueue_style('critical', get_stylesheet_directory_uri() .'/assets/css/critical.css', [], null)；
wp_style_add_data('critical', 'preload', true)；
wp_style_add_data('critical', 'as', 'style')；
wp_register_style('font-inter', false)；
wp_enqueue_style('font-inter')；
add_action('wp_head', function() {)
echo '' ."\n";
}, 2);
}, 1);
また、最適化プラグイン(持ち越す, コンバインヒントがパーサーの背後に漏れないようにする。有効化した後、頭の中の順序が保持されているか、重複したプリロードがないかをテストする。.
トラブルシューティングとアンチパターン
- プレコネクトが多すぎる3-5ホスト以上はソケットを無駄にする。私は ファーストクリティカル ターゲット（フォント/CDN/API）。.
- 誤字・脱字: A
as="フォント"なしtype="font/woff2"は、誤った優先順位や重複リクエストにつながる可能性がある。. - 未使用のプリロード未使用のリソースはすべて回線を詰まらせる。私は、安全に使用されないプリロードはアバウトに削除している。.
- 忘れられたクロスオリジンフォントや外部CDNでは、CORSの問題やキャッシュロスにつながります。.
- HTMLオーダーヒントはheadの先頭に置かなければならない。スタイルの前にプリロードし、次にCSSをレンダリングし、次にクリティカルなJSをレンダリングする。.
- サイズなしの画像セット私はこう付け加えた。
imagesizes, ブラウザが正しく選択し、無駄のないダウンロードができるように。.
".
根拠のある優先順位をつける
私はいくつかの質問に基づいて決める。） ホスト／資産は早期に保証されるか 必要か？2) どのくらいの高さ レイテンシー（モバイル、グローバル、コールドCDN）は？3) 代替案はあるか (インラインCSSサブセット、フォントのセルフホスト）？4) 接続は再利用可能か (合体、H3、再開）？5) 障害 メジャー・パーサーの発見？それは次のようなものだ：広範で有利な利益にはプリフェッチ、ウォームアップには選択的にプリコネクト、次のような場合にはプリロードのみ。 保証 必要なファイルをきれいに入力し、正しい優先順位をつける。.
概要
私はこうしている。 DNS 広範で有利なレイテンシを得るためのプリフェッチ、少数だが中心的なホストのためのプリコネクト、そして確実に必要とされるファイルのためのプリロード。頭の中のシーケンスと惜しみない選択が最大の効果をもたらす。私はすべての変更を測定し、ウォーターフォールをチェックし、定期的にヒントリストを調整する。HTTP/3、近くのCDN、賢いリソースの優先順位付けと組み合わせることで、FCPとLCPを目に見えて向上させることができる。これが、私がブラウザ最適化DNSを効果的に使用し、持続的にFCPとLCPを向上させる方法です。 ウェブサイト速度.
