HTMLが読み込まれるまでの「待機」時間の原因は何ですか？

読み込みが非常に遅いようです。速度テストを実行すると、HTMLが読み込まれる前に6秒のギャップがあるようです。それ以降は、画像とJSスクリプトの読み込みが非常に速くなります。

黄色の「待機時間」バーの下の写真をご覧ください。

これは、ページのHTMLコンテンツが何であっても一貫しているようです。

このサイトはCMS（ModX Revo）を使用しているため、HTMLは実際にはSQLデータベースに格納され、PHPによって提供されますが、この問題はこれまで経験したことがありません。

誰がこれを引き起こしているのか、そしてどのように私がそれをスピードアップできるのか知っていますか？

待機の専門用語は、最初のバイトまでの時間と呼ばれ、Webサーバーまたはその他のネットワークリソースの応答性を決定します。

最初のバイトまでの時間が長くなる一般的な理由：

• 過負荷ネットワーク（通常は共有ホスティング）
• 誤設定サーバー
• あなたとサーバーからの距離（地理的な位置は小さな役割を果たす）
• サーバーエラー（ホップ）

一般にこの問題は、共有ホスティングでよく見られます。これは、ウェブサイトの数が非常に多く、訪問者も当然ネットワークバイト時間が増えるためです。もう1つの考えられる原因は、ホップなどのネットワークのどこかでエラーが発生したか、サーバーがターゲットユーザーの場所にないためです。たとえば、 'GOOD' UKサーバーのバイト時間は、英国、データの送受信が必要な距離のため（通常、約100〜200ミリ秒の増加）。

新しいホストを取得する時期かもしれません

以前は、最初のバイトまでの時間の遅れのためにサーバー間を移動する必要があり、新しいWebホストを選択するか、現在のパッケージをアップグレードしなければならない場合があります。

信頼できるテスト

自宅のブロードバンドからWebサイトの速度をテストすることは、ブロードバンドがWebサイトに応答しないことに問題がある可能性があるため、非常に偏っています。複数のサーバーからの複数の接続を使用してWebサイトをテストする必要があります... Webページのテストを行い、さまざまな場所から、および対象となる地域のオーディエンスの多くから一度に複数のテストを実行することをお勧めします。これにより、状況の概要がわかりやすくなります。最初のバイトの場合は、何よりもまずWebホストに連絡することをお勧めします。

サーバーへのpingとトレースルート

サーバーでpingを実行しようとすると、結果が表示される場合とそうでない場合があります。pingは、UDPまたはTCPではなくICMPを使用します。つまり、httpdが実行されるポート80でサーバーにクエリを実行するのとは異なります。trace routeを使用して、最初のバイトの増加を引き起こしている可能性のあるルート上のサーバーを特定できます。ここでも、ポート80でhttpdサーバーにクエリを実行せず、Windowsを使用するtracerouteの場合、ICMPとMac / Linuxを使用します。マシンはUDPを使用します。すばやく簡単に実行できるため、テストする価値はありますが、結果が正常に戻った場合でも、どこかに問題がないことを意味するわけではありません。

1）現在のコードと非同期で読み込まれていないAdobe TypeKitがあります。高度な非同期コードに置き換えてみてください：http : //help.typekit.com/customer/portal/articles/649336-embed-code

この標準の埋め込みコードは、タグがページのそれ以上のレンダリングをブロックするという事実を利用して、FOUT [スタイルのないテキストのフラッシュ]を防ぎます。Typekitスクリプトの読み込み中は、ページのレンダリングがブロックされるため、テキストはフォールバックフォントでレンダリングされなくなります。

2）新しいTypeKitでテストします。読み込み時間はどうですか？いい？手順3に進みます。

3）Googleアナリティクスを、最新の非同期構文を提供する更新されたJavaScriptに置き換えます：https : //developers.google.com/analytics/devguides/collection/gajs/

4）テスト。それでもページの読み込みは改善されていますか？

5）最後に、pattern.jpgなどの画像の最適化を検討します。私はそれをPNGに変換し、ファイルサイズを199kBから56kBに減らすことができました。これにより、ファイルを受信する時間が短縮されます：https : //www.dropbox.com/s/i06jx509bmprhhh/pattern.png?dl=0

これがお役に立てば幸いです。

PHPと非PHP要素

非PHPアセットのロード時間とPHPベースのロード時間を比較すると、PHPが関与していない場合、サーバーが迅速に応答することがわかります。

これは通常、PHPスクリプトの内部に問題があることを示しています。

問題は、PHPレイヤーまたはデータベース内にある可能性があります。XDebugやNewRelicなどの高度なデバッグツールを使用すると、ボトルネックをすばやく特定できます。

最初のバイトまでの時間の問題は、ハードウェアの制約、不適切な構成、または非効率的なコードによって引き起こされる可能性があります。共有ホスティングでは、ハードウェアの制約と不適切な構成が最も可能性が高いです。

いずれにせよ、問題を解決することは通常、以下の1つまたはすべてを意味します。

• その他のハードウェア
• より良いプログラミング
• キャッシングを追加

すでに専用リソースを使用している場合、より高速なハードウェアは明白ですが、多くの場合コストがかかるソリューションです。

問題が、管理していないコードの内部にある場合や、開発者のリソースが不足している場合は、プログラミングを改善できない可能性があります。

キャッシングは、基になるパフォーマンスの低いリソースにヒットする必要のあるリクエストの数を減らすことで役立ちます。

テスト中

テストツールを使用する場合は、必ず複数回実行してください。ネットワークと一時的なサーバーのスパイクは、間違った経路を簡単に導く可能性があるため、これらを平均化する必要があります。

ホスティング

共有ホスティングアカウントを使用している場合は、クラウドまたはVPSタイプのサービスに移行することを検討してください。これにより、パフォーマンスの問題をより詳しく把握できます。キャッシュ技術（CDNまたはCloudflareタイプのサービス）を使用しない限り、サーバーの十分な制御が不足しているため、大量共有ホスティングシステムのパフォーマンスの問題を修正することは非常に困難です。

サードパーティのCookieを訪問済みのみに設定してみてください。