基礎知識
多くのサイト管理者が、ウェブサイトのアクセス速度が十分でないという問題に直面しています。今日はこの問題を理解し、解決してみましょう。まず、ブラウザを使ってウェブページにアクセスしてから、そのページが表示されるまでに、一体どのようなプロセスを経ているのでしょうか？
まず、HTTPリクエストの前に以下の処理が行われます：
- IPアドレスの取得。ブラウザのアドレスバーにURLを入力して送信すると、まずローカルDNSキャッシュテーブルで検索されます。見つかった場合は直接IPアドレスが返されます。見つからない場合はゲートウェイDNSに検索を要求し、これを繰り返して対応するIPが見つかったらブラウザに返します。
- TCP接続の確立。IPアドレスを取得した後、リクエスト先のサーバーと3ウェイハンドシェイクを行ってTCP接続を確立します。
- 接続が確立された後、サーバーにHTTPリクエストを送信します。
HTTPリクエストでは、まずページファイルを取得し、次にページファイル内のCSS、JS、画像などのリソースファイルを解析して、それらのリソースファイルを取得するためのリクエストを送信します。HTTP 1.1のリクエストでは、複数のリクエストを並行して行うことができますが、どのリソースファイルをリクエストすべきかを知るためには、まずページファイルが先に到着している必要があります。
したがって、全体のプロセスにはいくつかの段階があります。第1段階はTime to First Byte（TTFB）です。これはURLリクエストからサーバーがHTTPリクエストを受信してレスポンスを返すまでの時間のことです。実際にはDNS解決や接続確立の時間だけでなく、動的ページの場合はサーバーが動的コードの実行を完了してページコードを返す必要があるため、計算処理やデータベース操作などがTTFBを直接増加させます。一方、静的ファイルの場合はTTFBは通常高速です。しかし、サーバーとの間のネットワークが不安定な場合、例えばサーバーが海外にある場合などは、非常に長い遅延が発生します。
Alibaba CloudのCloud Monitorでは、HTTPモニタリングポイントを任意に設定してサーバーの応答時間を監視できます。例えば、同じサーバー上に配置した2つのウェブサイトを設定しました：
ここから明らかなのは、データベース呼び出しが必要なWordpressの場合、下にある単純なXML読み取りのみを使用しているeitdesignよりも応答時間が著しく長いことです。eitdesignに関しては、基本的に応答時間は瞬時ですが、ここでサーバーの物理的な距離による影響が見て取れます。サーバーは杭州にあるため、杭州からのアクセスはわずか2msですが、青島からのアクセスは23msかかります。データがサーバーに到達して戻ってくるまでの応答時間はpingコマンドで取得できます。
ところで、多くの人が使ったことのあるpingコマンドですが、どうやら多くの人はサーバーが通じているかどうかを確認するためだけに使っているようです。。。まずpingの原理について説明します：宛先にICMPエコーリクエストメッセージを送信し、期待したICMPエコーリプライを受信したかどうかを報告します。
理論的には、pingで送信したデータサイズと同じサイズのデータを相手が返信するはずなので、サーバーとの通信状態を簡単に確認できます。
したがって、pingの応答時間が常に安定していたのに突然変動した場合、帯域幅が突然飽和したことが原因である可能性があります。この時、サーバーリソースの監視と組み合わせることで、問題の原因を簡単に特定できます。
pingを実行しながらページを継続的に更新すると、ある瞬間に明らかに時間が長くなる現象が見られます。これはその瞬間に帯域幅が飽和していることを示しています。
第2段階はページファイルを取得する時間です。ページファイルを取得する前は、ページ上にどのリソースファイルがあるかまだ分からないため、リソースファイルのリクエストは行われません。したがって、この時間も非常に重要です。
第3段階はhead内の各種リソースファイルを取得する時間です。リソースファイルはHTMLページ内に記述されている順序で読み込まれるため、head内のリソースが優先的に読み込まれます。head内には主にCSSとJSファイルがあり、これらが読み込まれて初めてページがレンダリングされます。そのため、head内で必要なリソースの読み込み時間に特に注意する必要があります。結局のところ、ページがレンダリングされるまで、ユーザーに見えるのは空白の画面だけです。
第4段階は残りのリソースファイルを取得する時間です。この部分は主に画像、アニメーション、動画などのファイルであり、重要性はそれほど高くありません。すでにページが表示されているため、ほとんどのユーザーは数秒かけてこれらが読み込まれるのを待つことは許容範囲だと考えています。
実はページのレンダリング時間もありますが、読み込みと同期して行われ、通常読み込みより遅くなることはないため、無視できます。
テストツール
これらのデータを直感的に取得したい場合は、ページのタイムライン、つまりウォーターフォールチャートを直接見ることができます。現在、主要なブラウザに内蔵されているデバッグツールでこの機能を実現できます。当サイトとSafariを例に、下の図をご覧ください：
初回アクセス（SafariではShift+更新ボタンでキャッシュを無視できます）：
再アクセス時：
図から明確に分かるのは、合計47個のリソースファイルが参照されており、データ量は合計2MB、初回アクセスの総所要時間は1.07秒、再アクセス時は825msでした。まず初回アクセスについて説明します：
1行目の青いものがページファイルで、総サイズ50.89KB、圧縮後の実際の転送サイズは10.58KB、応答時間342ms、読み込み時間66.1msです。そしてこのファイルが解析された後、各リソースファイルのリクエストが開始されます。
ここに2本の点線が見えます。青い線はDOMContentイベントのトリガー時間で、ここでは635msです。これはブラウザがドキュメントの解析を完了した時点（ただし画像などの他のリソースはまだダウンロード完了していない可能性があります）を示しています。赤い線はLoadイベントのトリガー時間で、ここでは1.07秒です。これはすべてのリソースの読み込みが完了したことを示しています。
初回アクセス時はすべてのリソースをリクエストする必要がありますが、再アクセス時はローカルキャッシュデータを利用してリソースの読み込み速度を上げることができます。したがって、あまり変更されない静的リソースに有効期限を設定し、一定期間内はそのリソースを再読み込みする必要がないことをブラウザに通知することで、ユーザーの再アクセス速度を向上させ、第4段階の時間を大幅に短縮できます。
このタイムラインはローカルブラウザだけでなく、関連するテストサイトでも確認できます。例えばAlibabaのAliCeや、Google Page Speed、Yahoo YSlowなどです。Google Page SpeedとYahoo YSlowを組み合わせたツールもあり、GTMetrixと呼ばれ、これも優れたツールです。同時に、これらのサイトはサイトに対する最適化の提案も提供します。
もう一つのツールとして17CEがあり、異なる地域のテストサーバーから同時に応答時間とPING時間をテストでき、異なる地域のユーザーのアクセス速度を把握するのに役立ちます。
最適化手法
さて、関連する基礎知識とツールが揃ったので、的を絞った最適化を行うことができます。以下に各部分をどのように最適化するかをそれぞれ説明します：
第1段階、サーバー応答時間については、これといった特効薬はありません。動的ウェブサイトの場合は、主にアルゴリズムとデータベースの最適化、およびAJAXを使用した非同期データ読み取りなどが中心となりますが、これらはバックエンドの領域なのでここでは詳しく議論しません。ただし、サーバーの応答時間が2秒を超える場合、基本的にサーバーがダウンしているとみなせます。通常は500ms以内に抑えるべきで、体感上の違いは不明显かもしれませんが、250ms以内に抑えられればなお良いでしょう。
第2段階、ページファイルの取得について。まずページファイルは通常大きくなく、すべてプレーンテキストです。そこで最適化の方法としてはGzip圧縮を有効にすることです。有効化方法として、Apacheの場合はまずhttpd.conf内のLoadModule deflate_module modules/mod_deflate.soの前の#を削除し、Apacheを再起動してから、.htaccessに以下を追加します：
<IfModule mod_deflate.c> AddOutputFilter DEFLATE html xml php js css text/html text/plain </IfModule>
Gzip圧縮は、このような比較的疎なプレーンテキストに対してはかなり効果的です。例えば、私のこのトップページは50Kから10Kに圧縮されました。
また、外部リンクのCSSファイルを使用し、スタイルシートをHTMLページ内に直接記述しないようにしてください。こうすることでCSSファイルにキャッシュを設定できます。
第3段階、head内のリソースファイル、主にCSSとJSファイルについては、以下の方法があります：
- GZip圧縮を使用する。
- minify済みのJSとCSSを使用する。オリジナル版は修正用に保持し、出力用のmin版を使用します。可読性は低下しますが、サイズは明らかに小さくなります。
- 複数のCSSおよびJSファイルを結合し、HTTPリクエスト数を削減する。
- 不要なJSファイルをページの後方で読み込むように移動する。レンダリングに影響しないJSファイルについては、第4段階で読み込むように移動することで、ページの表示時間を短縮できます。
- 更新頻度の低いファイルにはキャッシュ時間を設定し、OSSまたはCDNを使用する
第4段階、ここが真に大量のデータを扱う部分です。現在、ユーザー側の帯域幅は通常問題になりませんが、ボトルネックは主にサーバー側に現れます。考えてみてください。もしページの完全な読み込みに2MBのデータが必要で、サーバーの出口帯域幅が1Mbpsしかない場合、各種遅延を無視しても、単一ユーザーのアクセスであっても、この2MBのデータを転送完了するには最速でも16秒かかります。これはユーザーにとって耐え難いものです。
そこでAlibaba CloudのECSについて、月額制で帯域幅がそれほど高くない場合は、ECSから直接アクセスされるリソースを極力減らす必要があります。主な方法はOSSストレージの使用、CDNアクセラレーション、GZip圧縮です。具体的な最適化は非常に細かくなりますが、ECSから直接アクセスされるデータ量を最小限に抑えるよう努めます。ただしWordpressは厄介で、システム標準やプラグイン内で参照されているJSやCSSファイルの中には、結合や位置の変更が不便なものもあります。。。できるだけ最適化するしかありません。私のこのサイトを例に挙げると、以前はすべての画像をCDNに入れた後でも、トップページの読み込みにはまだ約220KBのデータがECS経由で必要でした。これでは1Mbpsの帯域幅の場合、少なくとも2秒かかります。その後、テーマ内のすべての画像とbootstrap、jqueryをCDNに移行し、さらにGZip圧縮を加えて最適化した結果、現在は80KBのデータのみとなり、1秒以内での読み込み完了を保証できるようになりました。
その他に注意すべき点としては：
- 画質を維持した上で、可能な限り画像サイズを圧縮する。
- 小さな画像を表示する場合、ページ内で大きな画像をリサイズせず、直接小さいサイズの画像を使用する。
- 静的ファイルに対しては、可能な限りCookieを使用しないドメインを別途使用する
トラフィックが膨大なウェブサイトにとっては、1バイトでも節約することが重要であり、さらに多くの最適化手法が存在します。具体的にはGoogle Page SpeedやYahoo YSlowのページ評価結果を参考にできますが、これらのサーバーは海外にあるため応答時間が長くなります。このデータは無視して構いません。
最後にキャッシュ時間の設定方法について説明します。Apacheの場合は、まずhttpd.conf内のLoadModule expires_module modules/mod_expires.soの前の#を削除し、Apacheを再起動してから、.htaccessに対応するコードを追加することで、異なるファイルタイプのキャッシュ時間を設定できます。以下の設定では、画像ファイルとJSファイルを1ヶ月、アイコンファイルを1年に設定しています：
<IfModule mod_expires.c> ExpiresActive On ExpiresByType image/jpg "access plus 1 month" ExpiresByType image/jpeg "access plus 1 month" ExpiresByType image/gif "access plus 1 month" ExpiresByType image/png "access plus 1 month" ExpiresByType text/x-javascript "access plus 1 month" ExpiresByType application/x-shockwave-flash "access plus 1 month" ExpiresByType image/x-icon "access plus 1 year" </IfModule>
余談
実はこの記事が生まれたきっかけは、Alibaba Cloudサーバーのちょっとした障害でした。ある日から応答時間が非常に長くなり、Cloud Monitorのアラームが鳴りました。当時確認したところ、一時的に応答時間が15秒以上に達していました。。。
そこで何が起きたのかと考え。。。あらゆる手段を尽くして自分のサイトの最適化を始めました。この障害はすぐに修復されましたが、ページ高速化に関する様々な知識を改めて研究する機会を得ました。1Mbpsの帯域幅がいかに小さいかを痛感させられました。。。
皆さんがこの記事の中から求めているものを見つけ、ご自身のサイトを少しでも高速化できることを願っています~~~
サポート
