最初のバイトまでの時間とその改善方法

おそらく最初のバイトまでの時間というフレーズを聞いたことがあるかもしれませんが、どういうわけか一部の人々はこの概念を逃れているようです。それは、信じられないほどテクノロジー指向であるように見えるため、または日常使用にはそれほど重要ではない抽象的な概念のように見えるためです。真実と違うことがあってはならない。

最初のバイトまでの時間は、実際のところ、技術者だけが理解すべき概念やアイデアではありません。誰もがその意味を理解し、実践できるはずです。

この記事では、最初のバイトまでの時間とは何なのか、これがサイトにどのような影響を与えるのか、そして、このテーマに十分な注意を払う必要がある理由について、短い言葉で説明します。読者にサイトを閲覧する際に可能な限り最高のエクスペリエンスを提供します。

最初のバイトまでの時間とは何ですか?

最初のバイトまでの時間 (TTFB) は、ウェブサーバーまたはその他のネットワークリソースの応答性の指標として使用される測定値です。

TTFB は、ユーザーまたはクライアントが HTTP リクエストを行ってから、クライアントのブラウザがページの最初のバイトを受信するまでの時間を測定します。この時間は、ソケットの接続時間、HTTP リクエストの送信にかかる時間、ページの最初のバイトを取得するのにかかる時間で構成されます。 DNS 後の計算と誤解されることもありますが、ネットワークにおける TTFB の元の計算には、リソースの読み込みが開始されるまでにかかる時間を測定する際のネットワーク遅延が常に含まれます。

これは、ウィキペディアから直接引用した「技術者」の説明です。では、これをすべての人に役立つ、よりシンプルなものに翻訳してみましょう。

最初のバイトまでの時間とは、Web サイトを読み込むためにボタンを押してからレンダリングが開始されるまでにかかる時間です。 これをゲーム用語で言うと、最初のバイトまでの時間は、ゲーム中に発生する「遅延」または「ラグ」に似ています。レイテンシは、サイトの応答性がどの程度であるかを直接表します。

最初のバイトまでの時間に影響を与える要因は何ですか?

最初のバイトまでの時間はいくつかの要因で表すことができますが、これは WordPress の記事であるため、WordPress が導入されている場合に影響を受ける内容にすべてを絞り込みます。

DNS応答時間
サーバーの構成とパフォーマンス (PHP および Web サーバー)
WordPress プラグイン/テーマ
HTMLキャッシュの有効化/無効化

これらの要因のそれぞれにより、サイトのレンダリングが開始されるまでに遅延が追加されます。つまりすべてが合計されるということです。これらの要因の一部がレイテンシに影響を与える可能性があるというわけではなく、それらの要因すべてがレイテンシの増加に寄与します。したがって、理想的なシナリオでは、非常に良好な最初のバイトまでの時間を得るためにすべてが高速である必要があり、そのチェーン内の何かの処理に時間がかかると、最後の最初のバイトまでの時間が低下することが推測できます。

これは重要です。最初のバイトまでの時間は、あなたまたは読者がサイト上で行うすべてのことに影響するためです。読者がリンク、写真、ブログ投稿、またはページをクリックするたびに、最初のバイトまでの時間がかかります。考慮に入れます。最初のバイトまでの時間が悪いということは、リーダーが貧弱なサーバーに接続しているゲーマーと同様の状況に陥ることを意味していることがわかります。クリックごとにかなりの遅延が発生し、エクスペリエンスに影響を与えます。

注: ここからは、処理を少しスピードアップするために、最初のバイトまでの時間を表す頭字語 TTFB を使用することにします。

1.DNS応答時間

DNS 解決は方程式の最初の要素です。可能な限り最高の解決策を得るために、常に適切な DNS サーバーを使用し、ノードが全世界に分散していることを確認してください。このステップで TTFB を削減する良い方法は、CloudFlare のような優れたグローバルサービスを使用することです。この種のサービスはグローバル DNS キャッシュを実装しているためです。この方法は、さらなる解像度をキャッシュすることで TTFB を削減するのに非常に適しています。

2. サーバー構成

TTFB レイテンシーの 2 番目のステップは、実際のサーバーです。ここでホスティングが登場します。採用されているウェブサーバー構成の種類とキャッシュ技術により、TTFB が大幅に削減されます。たとえば、サーバーが古い PHP 5.4 インタープリタを実装している場合、TTFB が非常に高くなりますが、最新の PHP 7.1 構成を使用すると、その時間が 2 倍以上短縮されます。

これは、PHP インタープリターがプロセスで重要な役割を果たすためです。 キャッシュされていない Web サイトのページやブログ投稿をリクエストするたびに、サーバーは問題の PHP ファイルを処理して、HTML 形式に変換してブラウザに戻す必要があります。。 PHP ファイルが複雑になるほど、前処理してブラウザに送り返すのに時間がかかります。

サーバーのパフォーマンスもプロセス全体に重要な役割を果たしていることがわかります。 CPU が高速になり、ホスティングが割り当てるリソースが増えるほど、ファイルの処理も速くなり、TTFB は小さくなります。

また、ホスティングが PHP キャッシュを実装している場合、PHP ファイルを最初から処理する必要がなく、そのファイルのキャッシュされたバージョンが提供されるため、2 回目のリクエストではさらに削減されます。

これで、ホスティングビジネスには 2 種類あり、一般的な (キャッシュされていない) サービスと WordPress 専用ホスティングサービスがあり、通常は PHP のキャッシュメカニズム を実装し、その過程で TTFB を削減することがわかります。

3. WordPress プラグインとテーマ

TTFB の方程式の 3 番目のステップは、実際のサイトです。これが最も重要な要素なので、その理由を説明します。

通常、WordPress ではホスティング側にいくつかの PHP ファイルを処理させる必要があり、ファイルが複雑になればなるほど、処理にかかる時間が長くなります。 WordPress はプラグインによって提供されており、それらのプラグインは最終的なPHP 処理に追加のコードを追加します。このことを念頭に置くと、より多くのプラグインをインストールすると明らかにわかります。ホスティングがそれらを処理するのに時間がかかるほどそのため、TTFB は増加します。

少ないほど良い

経験則として、通常はプラグインが少ないほど良いです。もちろん、コーディングが不十分な 1 つのプラグインは、専門的にコーディングされた 10 個のプラグインよりもはるかに悪い可能性があります。また、偶然競合する 2 つのプラグインをインストールすることも可能です。ただし、一般的にプラグインの数を減らすと、更新の管理が容易になり、サイトの速度が向上します。インストールに必要な適切な量のプラグインの例を次に示します。

次の例は問題がある可能性があります (繰り返しますが、インストールした内容に部分的に依存します)。

そしてもちろん、30 プラグインの壁を超えるものはレイテンシーにとって良くない可能性があります。 40 を超えるプラグインを含む Web サイトは、たとえそれが優れたホスティングサービスでホストされていたとしても、TTFB が非常に高いことは間違いありません。その理由を説明します。

4. HTML キャッシュ

最後の要素が最も重要で、WordPress インストールに実装することを決定したキャッシュメカニズムに関連します。 WordPress にはいくつかの種類のキャッシュメカニズムがありますが、その中で最も効果的なのはHTML キャッシュです。

KeyCDN Cache Enabler のような優れたプラグインを使用すると、ホスティング自体以上に TTFB に多大な影響を与えます。これらのファイルはすべて HTML に変換されるため、キャッシュがアクティブになると、リーダーはホスティング上の PHP プリプロセッサを通過する必要がなく、コンテンツの提供はウェブサーバー自体のみで行われます。。この記事で説明したように、メイン Web サーバーとして Apache の代わりにnginx を含むホスティングを使用することに決めた場合、プロセスをさらに高速化することもできます。

最初のバイトまでの時間のケーススタディ: なぜそれが重要なのか

では、私たちが何について話しているのかを説明しましょう。次のケーススタディは、さまざまなサーバー上の Web サイト構成の実例であり、最後に便利なベンチマークの概要が示されています。

遅いサーバー上の遅い Web サイト

サイトが遅いことは TTFB にとって苦痛になる可能性があり、優れたホスティングサービスを気にしないのであれば、最悪の結果に直面することを覚悟しなければなりません。

このサイトを詳しく分析してみましょう。この目的のために、TTFB を表示できる優れたツールである Pingdom Tools を使用します。秘訣は、サイトに対して行われた最初のリクエストの詳細を開くことです。

ご覧のとおり、このサイトの TTFB は 4.2 秒以上です。これは、Web サイトが実際に利用可能であるという兆候が表示されるまでに 4 秒かかることを意味します。

この時間を、サイト上で行う予定のすべてのクリック数で乗算すると、それが読者にとってどれほどの苦痛であるかがわかります。もちろん、サイトのレンダリングにかかる合計時間に TTFB を追加する必要があります。サイトが適切に表示されるまでに最大 7 秒もかかる場合があるため、結果はパフォーマンスに壊滅的な影響を及ぼします。

いくつかの要因の組み合わせがこれにつながります。キャッシュメカニズムのない最適化が不十分な Web サイト、非常に遅いホスティングサービス、およびまだ PHP 5.4 を実行している完全に時代遅れの PHP インタープリター。サイトが外部キャッシュメカニズムとして Cloudflare を使用している場合でも、サイトとホスティングが連携していなければ、状況を改善するためにできることは何もありません。

平均的なサーバー上の高速 Web サイト

Apache と PHP 7.1 を使用する平均的なサーバーに非常に高速なサイトを配置すると何が起こるかを見てみましょう

キャッシュなしでプラグインが 10 個未満のサイトでは、結果は以前のサイトより少なくとも 5 倍優れています。 TTFB が 521ms に設定されていることがわかります。つまり、サイトがサーバーからコンピューターに到達するまで、ブラウザー上でレンダリングが開始されるまでに 0.5 秒かかるということです。

その Web サイトのキャッシュを有効にするとどうなりますか?魔法が起こります。 Apache で実行されている一般的に平均的なサーバーは、わずか 152 ミリ秒の TTFB で優れた結果を得ることができます。いかに優れたWordPress キャッシュメカニズムが結果に影響を与えるかがわかります。

高速サーバー上の非常に遅い Web サイト

今度はその逆を見てみましょう。非常に遅いサイトを非常に高速なサーバーに配置するとどうなるでしょうか。

nginx および PHP 7.1.11 を備えた Plesk を実行する最適化されたサーバーは、プラグイン (27 個以上) で満たされたサイトをレンダリングするのに 1.29 秒かかります。

しかし、素晴らしい KeyCDN Cache Enabler を通じて WordPress でキャッシュを有効にすると、素晴らしい結果が得られます。非常に遅いサイトでは、TTFB がわずか 400 ミリ秒に短縮されています。

高速サーバー上の高速 Web サイト

では、最適な状況を見てみましょう。高速サーバー上で動作する高速 Web サイト。

遅いサイトで 1.29 秒の TTFB を与えていた同じサーバーは、キャッシュのない高速なサイトでは 500 ミリ秒未満で応答します。

キャッシュを有効にすると、驚くべき結果が得られます。高速サーバーとキャッシュを有効にした高速 Web サイトを組み合わせると、TTFB は 150 ミリ秒未満になります。

ベンチマーク結果

ベンチマーク愛好家のために、結果を 1 つの大きなグラフで見てみましょう。

ホスティングは TTFB を削減し、サイトのレイテンシーと体感的なパフォーマンスを向上させる上で重要な役割を果たしていますが、サイトで何を行うかがパフォーマンスに最も大きな影響を与えることがわかります。

まとめ

適切な TTFB 指標を取得すると、高速で応答性の高いサイトが保証され、一般的なレンダリング時間が短縮され、パフォーマンスを判断するための優れた指標として機能します。通常、TTFB が高くなるほど、サイトの速度は遅くなります。サイトのベンチマークを行う際には TTFB を念頭に置くことが最も重要です。このタイミングは、WordPress インストールのボトルネックを特定するためにも使用できるからです。すべてのプラグインを無効にして基本テーマに切り替えて、TTFB を再度測定するだけで簡単な演習を行うことができます。きっとその結果に驚かれるでしょう。

データベースのパフォーマンス、利用可能な帯域幅、ネットワーク速度など、考慮すべき要素は他にもあるため、これが決して「すべてを決定する 1 つの指標」ではないことを述べてこの記事を終えたいと思います。ただし、TTFB は通常、これらすべての要因の影響を受けるため、他の場所にボトルネックがあることを示しています。

ぜひこの機会に TTFB を試してみてください。以下にコメントを残してください。ご自身のテストについてお聞きしたり、ご質問がございましたらお気軽にお問い合わせください。