Time to First Byteのcache durationサブパートを削減する

Time to First Byteのcache durationを削減する

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

• 待機 + リダイレクト（waiting duration）
  
• ワーカー + キャッシュ（cache duration）
• DNS（DNS duration）
• 接続（connection duration）
• リクエスト（request duration）

Time to First Byteを最適化したいですか？この記事ではTime to First Byteのwaiting durationパートについて詳細な分析を提供します。Time to First Byteを理解または修正したいが、waiting durationの意味がわからない場合は、この記事を読む前にTime to First ByteとはとTime to First Byteの問題を修正・特定するをお読みください

注意：通常、Time to First ByteのCache Durationパートはボトルネックにはなりません。以下の場合のみ読み続けてください：a）サービスワーカーを使用している場合、b）私のようなページスピード愛好家の場合！

通常、Time to First Byteのcache durationサブパートはボトルネックにならず、10〜20ミリ秒以内に完了します。サービスワーカーを使用している場合、60ミリ秒以下が許容範囲です。

サービスワーカーはTime to First Byteにどのような影響を与えるか？

サービスワーカーはTime to First Byte（TTFB）にプラスとマイナスの両方の影響を与える可能性がありますが、サービスワーカーを使用しているウェブサイトにのみ影響します。

サービスワーカーがTTFBに影響を与える可能性のある方法を以下に示します：

サービスワーカーの起動時間によるTTFBの低下：workerStart値は、要求されたリソースに対してサービスワーカーが存在する場合、その起動にかかる時間を表します。この起動時間はTTFBの計算に含まれます。サービスワーカーが終了状態から起動または再開する必要がある場合、初期応答時間に遅延が追加され、TTFBが増加する可能性があります。

キャッシュによるTTFBの高速化：stale-while-revalidateのようなキャッシュ戦略を使用することで、サービスワーカーは利用可能な場合にキャッシュから直接コンテンツを提供できます。これにより、ブラウザがサーバー応答を待つ必要がないため、頻繁にアクセスされるリソースのTTFBがほぼ即時になります。この戦略は、最新の情報が必要な動的に生成されるコンテンツではなく、更新頻度の低いコンテンツにのみ有効です。

アプリシェルによるTTFBの高速化：クライアントレンダリングアプリケーションの場合、アプリシェルモデルでは、サービスワーカーがキャッシュから基本的なページ構造を配信し、後でコンテンツを動的に読み込むため、そのベースのTTFBはほぼゼロに削減されます。

最適化されていないコードによるTTFBの低下：複雑で非効率なサービスワーカーは、キャッシュ検索プロセスを遅くし、それによってTTFBも遅くなる可能性があります。

サービスワーカーはページスピードに悪影響を与えますか？いいえ（通常は）まったく悪くありません！サービスワーカーは起動時間によって最初はTTFBを増加させる可能性がありますが、ネットワークリクエストのインターセプト、キャッシュ管理、オフラインサポートの提供により、特にサイトへのリピーターにとって、長期的には大幅なパフォーマンス向上につながる可能性があります。

Time to First Byteのcache Durationサブパートを測定する方法

以下の短いスニペットを使用して、Time to First Byteのcache durationサブパートを測定できます：

new PerformanceObserver((entryList) => {
  const [navigationEntry] = entryList.getEntriesByType('navigation');

  // get the relevant timestamps
  const activationStart = navigationEntry.activationStart || 0;
  const waitEnd = Math.max(
    (navigationEntry.workerStart || navigationEntry.fetchStart) -
    activationStart,
    0,
  );
  const dnsStart = Math.max(
    navigationEntry.domainLookupStart - activationStart,
    0,
  );

  // calculate the cache duration
  const cacheDuration = dnsStart - waitEnd;

  // log the results
  console.log('%cTTFB cacheDuration', 'color: blue; font-weight: bold;');
  console.log(cacheDuration);

}).observe({
  type: 'navigation',
  buffered: true
});

高いcache Durationによって引き起こされるTTFBの問題を見つける方法

cache durationによって実際のユーザーが経験する影響を見つけるには、CoreDashのようなRUMツールを使用する必要があります。Real User Monitoringにより、Core Web Vitalsを詳細に追跡できます。

CoreDashで「Time to First Byte」に移動し、ブレークダウンの詳細を表示するだけです。これにより、TTFBのすべてのサブパートへのブレークダウンが表示され、75パーセンタイルでcacheDurationがどのくらいかかるかが正確にわかります。

/p>

サービスワーカーのキャッシュ時間の影響を最小化する方法

サービスワーカーを使用する場合にTTFBを最適化するには：

• サービスワーカースクリプトの複雑さを最小限に抑え、起動時間を短縮します。
• サービスワーカー内で効率的なキャッシュ戦略を実装します。
• サービスワーカーのインストール時に重要なリソースのプリキャッシュを検討します。
• サービスワーカーがサイトのTTFBに与える影響を定期的にモニタリングおよび分析します。

サービスワーカーの実装を慎重に管理し、TTFBへの影響を理解することで、開発者はサービスワーカーが提供する長期的なパフォーマンス上のメリットと初期のオーバーヘッドのバランスを取ることができます。