TTFBはユーザーにとっての最初の待ち時間

Webページを開くとき、ブラウザはまずHTMLドキュメントをダウンロードしますが、裏側では多くの処理が行われます。

• DNSでドメイン名をIPアドレスに変換する
• IPアドレスがWebサーバにTCPで接続する
• ブラウザからWebサーバにHTTPリクエストを送信する
• Webサーバがリクエストを受信し、それに応じたHTMLドキュメントを用意する
• HTMLドキュメントの受信を開始する

場合によってはリダイレクトが発生することもあります。

Webページを開こうとしてからダウンロードが始まるまで(最初の1バイトを受信するまで)の時間をTTFB(Time To First Byte)と呼びます。

Webサーバのログではサーバー側の応答時間が記録されますが、これにネットワーク通信にかかる時間を加えた「ユーザーにとっての最初の待ち時間がTTFB」ということもできるでしょう。

ちなみにHTMLドキュメントだけではなく画像など他のリソースのリクエストについても、最初の1バイトの受信までの時間をTTFB(Time To First Byte)と呼びます。

Resource Timing について

3G回線で0.6秒以内を推奨

Googleが提供する監査ツールのLighthouseでは、モバイル端末向けのTTFBは600ms(0.6秒)未満にすることを推奨しています。

Keep Server Response Times Low

Lighthouseは内部で3G回線相当の通信速度をシミュレートするので、Lighthouseを実行すると自分のサイトが推奨値を達成しているかすぐに調べることができます。

3G相当の回線スピードでの時間なのでなかなか大変な目標にも見えますが、実際のところ国内のサイトはどうでしょうか。

7,688サイトにLighthouseを実行して、計測されたTTFBのサイト数(count)、最大値(max)、平均値(mean)、四分位(25%/50%/75%)、600msを超えるサイト数とその割合(over 600)が以下の通りです。時間の単位はms(0.1秒)です。

TTFBの平均は212.61ms(約0.21秒)と、推奨値600msを大幅に下回る結果となりました。

また、TTFBが推奨上限600ms以上となったサイトはわずか8.12%、75%のサイトはTTFBが245.2ms以内となっています。

このように相対的にも、TTFBが600ms以上のサイトは他のサイトに比べてかなり遅い・重いと感じられることでしょう。

なお、サイトのジャンル別ではやはり要件が複雑で扱うデータも多いECサイトがコーポレートサイトやブログ・ニュースサイトよりTTFBが長めになっています。

600ms未満のヒストグラムを見ると以下のように分布しています。

長めと言ってもわずかな差で、ECサイトも約90%がTTFB600ms未満を達成しています。長いTTFBはユーザー離脱の一因になるので、重たいサイトには工夫が求められます。

TTFB短縮のためのアクション

先ほど紹介したLighthouseのヘルプページでは、TTFB短縮のために以下のような方法を紹介しています。

• サーバ側のプログラムロジックの見直し。フレームワークを使っている場合はそのオススメ方法があるはず！
• データベースクエリーの見直しをするか、より高速なデータベースに変更すること。
• よりメモリやCPUの性能が高いサーバのハードウェアにアップグレードすること。

(予算的に)それができれば苦労しないよ...！とツッコミたくなるアドバイスですが、現実的にはキャッシュをうまく使うことが多くの場面での解決策になるでしょう。

特にデータベースアクセスに時間のかかる部分だけをキャッシュする方法は、低コストで安全(ログインによるパーソナライズを提供するWebサイトでも事故が起きない)、表示の仕様変更にも柔軟に対応できるのでオススメです。

また、処理によってはRDBMSよりNoSQLが得意とする場面も増えています。NoSQLをメインストレージにするに多くのノウハウが必要になりますが、検索やランキング計算といった一部の用途でRDBMSと併用することでパフォーマンスを改善するアプローチもあります。

アイデアマンズではTTFB改善のためのご相談をお待ちしています。