Time to First ByteのDNS Durationサブパートを最小化する

DNS durationはブラウザのDNSルックアップを測定します。高速なDNSプロバイダの選択、TTL設定の最適化、dns-prefetchの使用、そしてTTFBを削減するためのDNS over HTTPSの理解について学びましょう。

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-05
  1. Ja
  2. Core Web Vitals
  3. Time to first byte
  4. Dnsduration

Time to First ByteのDNS Durationサブパートを最小化する

この記事は私たちのTime to First Byte (TTFB)ガイドの一部です。DNS durationはTTFBの3番目のサブパートであり、ブラウザがドメイン名をIPアドレスに解決するために費やす時間を表します。キャッシュされたDNSレコードを持たない初回訪問者の場合、DNSプロバイダ、ユーザーの地理的位置、およびDNSレコードのTTL設定に応じて、DNSルックアップはTTFBに20から200ミリ秒を追加する可能性があります。

Time to First Byte (TTFB)は以下のサブパートに分解できます：

Time to First Byteの最適化をお考えですか？この記事では、Time to First ByteのDNS duration部分について説明します。Time to First Byteを理解または修正しようとしていて、DNS durationの意味がわからない場合は、この記事を読み始める前にTime to First Byteとは何かとTime to First Byteの問題の特定と修正をお読みください。

DNSのクイックフィックス: Time to First ByteでDNSの遅延が発生している場合は、プレミアムDNSプロバイダに切り替えてTTL設定を更新してください！

Time to First ByteのDNS Duration部分は、ブラウザがサイトのインターネット(IP)アドレスを検索している時間で構成されます。私たち人間は「www.example.com」のようなドメイン名を覚える方が簡単ですが、コンピュータ同士が接続するには数値のIPアドレスが必要なため、DNSルックアップが必要です。

DNSはどのように機能するか？

DNSリクエストはTTFB測定に含まれます。これは、DNSリクエストが完了するまでにかかる時間が全体のTTFBスコアに考慮されることを意味します。

ページがリクエストされたとき、ブラウザがドメイン名をIPアドレスに変換するために行う手順は次のとおりです：

  • ブラウザのDNSキャッシュの確認: DNSクエリを実行する前に、ブラウザはまず自身のDNSキャッシュをチェックし、リクエストされたドメインのIPアドレスをすでに持っているかを確認します。最新のブラウザは、繰り返しのDNSルックアップの必要性を減らしてパフォーマンスを向上させるために、設定された期間DNSレコードをキャッシュします。レコードがブラウザのキャッシュに見つかった場合、ブラウザはそれ以上のクエリなしにそれを即座に使用できます。
  • OSシステムキャッシュの確認: ブラウザのキャッシュに必要なDNSレコードが含まれていない場合、リクエストはしばしば「スタブリゾルバ」と呼ばれるオペレーティングシステムのDNSリゾルバに渡されます。OSもDNSキャッシュを保持しており、ネットワークリクエストを送信する前にそれをチェックします。
  • DNSクエリ: DNSレコードがブラウザまたはOSのキャッシュのいずれにも見つからない場合、通常はユーザーのインターネットサービスプロバイダ(ISP)によって提供されるDNSリゾルバに再帰的DNSクエリが送信されます。このリゾルバは仲介者として機能し、他のDNSサーバーにクエリを送信してIPアドレスを見つけるプロセスを処理します。
    • ルートネームサーバー: リゾルバはまずルートネームサーバーに接続し、ドメイン拡張子（例：".com"、".org"）に基づいて適切なトップレベルドメイン(TLD)サーバーにリダイレクトされます。
    • TLDネームサーバー: TLDサーバーは次に、特定のドメインの権威ネームサーバーにリゾルバをリダイレクトします。
    • 権威ネームサーバー: このサーバーはドメインのDNSレコードを保持しており、リゾルバにIPアドレスを提供します。
  • IPアドレスの返却: DNSリゾルバが権威サーバーからIPアドレスを取得すると、この情報をブラウザに返します。その後、ブラウザはIPアドレスを使用してサーバーへの接続を開始し、リクエストされたウェブページを読み込むことができます。

DNSはTime to First Byteにどのように影響するか？

DNSルックアップは、ネットワークの遅延（この場合はネームサーバーへの接続にかかる時間）、権威ネームサーバーの品質と速度、またはDNSキャッシュ時間（キャッシュされたDNSクエリはキャッシュされていないDNSクエリよりもはるかに高速であるため）のいずれかによって、Time to First Byteを遅くする可能性があります。

リピーターの訪問者の場合、DNSルックアップは通常ブラウザまたはOSにキャッシュされており、DNS durationはほぼゼロに短縮されます。しかし、初回訪問者の場合、ブラウザがTCP接続のステップに進む前に、完全な再帰的DNSルックアップを完了する必要があります。これが、TTFBが再訪問者に比べて新規訪問者の方が測定可能に悪くなることが多い理由です。

サードパーティドメインにdns-prefetchとpreconnectを使用する

ページがサードパーティドメイン（分析、フォント、またはCDNサブドメインなど）からリソースを読み込む場合、ブラウザは各ドメインのDNSを個別に解決する必要があります。dns-prefetchリソースヒントを使用することで、ブラウザにDNS解決を早期に開始するように指示できます：

<!-- DNS prefetch for third-party domains -->
<link rel="dns-prefetch" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://cdn.example.com">
<link rel="dns-prefetch" href="https://analytics.example.com">

TCPおよびTLS接続の確立も必要になることがわかっている重要なサードパーティオリジンの場合は、代わりにpreconnectを使用します。これにはDNS解決と接続ハンドシェイクの両方が含まれます：

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

preconnectをサポートしていないブラウザのフォールバックとしてdns-prefetchを使用します：

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://fonts.googleapis.com">

これらのヒントは、HTMLの<head>内にできるだけ早く配置してください。ページが実際に使用するドメインのヒントのみを追加してください。使用されていないドメインにヒントを追加すると、ブラウザのリソースが無駄になります。リソースの読み込みに関連する最適化テクニックの詳細については、103 Early Hintsのガイドを参照してください。

TTFBへのDNSの影響を最小限に抑える方法


高速なDNSプロバイダを使用する

一部のDNSプロバイダは他のプロバイダよりも高速です。高速で信頼性の高いDNSプロバイダを選択することは、DNSの遅延を減らす最も簡単な方法の1つです。Cloudflare、Amazon Route 53、Google Cloud DNSなどのプレミアムDNSプロバイダは、世界中の何百もの場所でサーバーを稼働させています。DNSサーバーがユーザーに近いほど、ルックアップは速くなります。

以下は、一般的なDNSプロバイダとそれらの典型的な応答時間の比較です：

DNSプロバイダ 典型的な応答時間 グローバルPoP 主な機能
Cloudflare DNS 約11ms 300以上 無料枠あり、DNSSEC、CNAME flattening
Amazon Route 53 約20ms 100以上 ヘルスチェック、レイテンシベースルーティング、ジオロケーション
Google Cloud DNS 約15ms エニーキャストグローバル 100%のアップタイムSLA、DNSSEC
NS1 約15ms 25以上 フィルターチェーン、インテリジェントなDNSルーティング
一般的なISP/レジストラDNS 約50〜100ms 限定的 基本機能のみ

プレミアムDNSプロバイダと基本的なレジストラのDNSの違いは、ルックアップごとに40〜90ミリ秒になる可能性があります（出典：DNSPerfベンチマーク）。初回訪問者の場合、これは直接より速いTTFBにつながります。CloudflareをDNSおよびCDNプロバイダとしてセットアップする方法については、Cloudflareの設定ガイドをお読みください。

DNSキャッシュのTime to Liveを最適化する

DNSキャッシュはDNSクエリの結果をローカルに保存し、繰り返しのルックアップの必要性を減らします。DNSレコードに「最適な」Time-To-Live (TTL)値を設定することで、これらのレコードがキャッシュされる期間を制御できます。

TTL値が低いとレコードの有効期限が早く切れ、DNSルックアップがより頻繁に発生します。TTL値が高いとレコードはより長くキャッシュされ、DNSルックアップは減りますが、DNSの変更が伝播する速度は遅くなります。適切なTTLは、DNSレコードをどの程度の頻度で変更するか、そしてDNSルックアップの速度と柔軟性のどちらを重視するかによって異なります。

最適なDNS TTL設定とは？

AおよびAAAAレコード（IPアドレスレコード）: ほとんどのウェブサイトの場合：5分から1時間。頻繁に変更されない静的なウェブサイトの場合：1から24時間。
CNAMEレコード: 通常は24時間。
TXTおよびMXレコード: 約12時間。
NSレコード: これらは重要であり一般的に静的であるため、1から2日などのより長いTTL。
SOAおよびその他の静的レコード: 最大数日間の、より長いTTL。

DNSの移行やサーバーの変更を計画している場合は、変更を行う少なくとも24時間前に一時的にTTLを5分（300秒）に下げます。これにより、変更後、ユーザーが新しいIPアドレスを迅速に取得できるようになります。移行が完了して検証されたら、TTLをより高い値に戻してDNSルックアップの頻度を減らします。

ヒント: CNAMEレコードを使用している場合は、CNAME flatteningの実装を検討してください。CNAME flatteningは、ルート（Apex）ドメインレベルでCNAMEレコードを使用できるようにする技術であり、DNS標準に違反することなく効果的にIPアドレスに解決します。これにより、CNAMEをそのターゲットに、次にそのターゲットをそのIPアドレスに解決するために通常必要となる追加のDNSルックアップが不要になります。

DNS over HTTPS (DoH)とDNS over TLS (DoT)

従来のDNSクエリはUDPを介してプレーンテキストで送信されるため、仲介者（ISPやネットワークオペレーターなど）によって傍受、変更、またはブロックされる可能性があります。DNS over HTTPS (DoH)とDNS over TLS (DoT)はDNSクエリを暗号化し、プライバシーとセキュリティの両方を向上させます。

DoHとDoTは主にセキュリティとプライバシーの懸念に対処するものですが、DNS解決のパフォーマンスにも影響を与える可能性があります：

  • レイテンシへの影響: 暗号化のオーバーヘッドにより、初期のDNS接続（TLSハンドシェイク）に少量のレイテンシが追加されます。しかし、DoH/DoT接続は持続的で再利用されるため、同じ接続での後続のクエリは従来のDNSよりも高速になることがよくあります。
  • ISPによる干渉: 一部のISPは独自のDNS応答を挿入したり、顧客以外のDNSクエリを遅くしたりします。DoHはこの干渉を完全に回避するため、影響を受けるユーザーのDNS解決時間を実際に短縮する可能性があります。
  • ブラウザのサポート: 最新のブラウザ（Chrome、Firefox、Edge、Safari）はすべてDoHをサポートしています。ほとんどの場合、ブラウザのデフォルトDNSプロバイダは、利用可能な場合はすでにDoHを使用しています。

ウェブサイトの所有者として、訪問者がDoHやDoTを使用するかどうかを制御することはできません（これはブラウザおよびOSレベルの設定です）。しかし、権威DNSプロバイダがDNSSECをサポートしていることを確認することはできます。これにより、トランスポートの暗号化に関係なく、DNS応答に対する補完的な検証レイヤーが提供されます。

JavaScriptによるDNS Durationの測定

Navigation Timing APIを使用して、ブラウザ内で直接TTFBのDNS durationサブパートを測定できます：

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  const dnsDuration = nav.domainLookupEnd - nav.domainLookupStart;

  console.log('DNS Duration:', dnsDuration.toFixed(0), 'ms');

  if (dnsDuration > 50) {
    console.warn('High DNS duration detected. Consider:');
    console.warn('1. Switching to a premium DNS provider');
    console.warn('2. Increasing DNS TTL values');
    console.warn('3. Using dns-prefetch for third-party domains');
  }
}).observe({
  type: 'navigation',
  buffered: true
});

RUMデータにおける0msのDNS durationは、通常、DNSルックアップがブラウザまたはOSのキャッシュから提供されたことを示します（リピーター訪問者のシナリオ）。50msを超える値は、ユーザーが完全な再帰的DNSルックアップを実行する必要があったことを示唆しており、これは初回訪問者に一般的です。

遅いDNSルックアップによって引き起こされるTTFBの問題を測定する方法

DNSの遅延が実際のユーザーに与える影響を把握するには、CoreDashのようなRUMツールを使用する必要があります。Real User Monitoringを使用すると、28日間のGoogleの遅延なしに、Core Web Vitalsをより詳細に追跡できます。

CoreDashでは、「Time to First Byte breakdown」をクリックして、Time to First ByteのDNS部分を視覚化します。

さらに詳しく：最適化ガイド

関連ガイド：

  • 103 Early Hints: 完全な応答の準備ができる前にリソースヒントを送信し、ブラウザが重要なリソースのDNS解決と接続をさらに早く開始できるようにします。
  • Configure Cloudflare for Performance: CloudflareをDNSプロバイダとCDNの両方として使用し、高速なDNS解決とエッジキャッシングおよびHTTP/3サポートを組み合わせます。

TTFBサブパート：完全なガイド

DNS durationはTTFBの5つのサブパートの1つです。全体像を理解するために、他のサブパートも確認してください：

  • Fix and Identify TTFB Issues: すべてのTTFB最適化の診断の出発点。
  • Waiting Duration: リダイレクト、ブラウザのキューイング、およびHSTSの最適化。
  • Cache Duration: サービスワーカーのパフォーマンス、ブラウザキャッシュのルックアップ、およびbfcache。
  • Connection Duration: TCPハンドシェイク、TLSの最適化、HTTP/3、およびpreconnect。
  • Request Duration: サーバーの処理時間、データベースクエリ、およびバックエンドの最適化。

リアルタイムのデータを。28日平均ではなく。

CoreDashはすべてのメトリクスをルート、端末、ブラウザ、回線で分解できます。

CoreDashを見る
Time to First ByteのDNS Durationサブパートを最小化するCore Web Vitals Time to First ByteのDNS Durationサブパートを最小化する