Moz - SEOとインバウンドマーケティングの実践情報

あなたのWebページ表示を爆速にするための、HTTPリクエスト状況分析ガイド(後編)

後編では、「ウォーターフォールの高さを縮める」「レンダリングの開始時間を早くする」「サーバーの速度」「CDN」などを解説。

Webページの表示を高速化するために無料ツールWebPagetestを使って表示パフォーマンスを確認する方法を解説しているこの記事は、前後編の2回に分けてお届けしている。後編となる今回は、「ウォーターフォールの高さを縮める」「レンダリングの開始時間を早くする」方法や、「サーバーの速度」「CDN」などについて解説する。
ウォーターフォール図やWebPagetestについては、前編を参照

高速化ポイント2 ウォーターフォールの高さを縮める

ウォーターフォール図が縦に長い場合は、ブラウザがページを読み込むのに大量のリクエストを行わなければならないことを示している。リクエストの数を減らす最善の方法は、ページに含まれているすべてのコンテンツを見直して、そのすべてが本当に必要かどうかを判断することだ。例を挙げてみよう。

  • CSSファルやJavaScriptファイルがたくさんある場合。

    以下はAOLサイトのウォーターフォール図の一部だが、冗談ではなく、1ページの表示になんと48ものCSSファイルが必要で、ブラウザは48ファイルをすべてダウンロードしているのだ!

    大量のCSSファイルやJavaScriptファイルを読み込んでいるサイトでは、CMSプラグインとして、あるいはビルドプロセスの一部として、それらのファイルをまとめるべきだ。ファイルをまとめると、出されるリクエストの数が減り、ページ全体が高速化する。

  • 「小さな」(2KB未満の)CSSファイルやJavaScriptファイルがたくさんある場合。

    その場合は、<script>、<code>、<style>などのインライン要素を使って、HTMLに直接ファイルの内容を埋め込むことを検討しよう

  • 302リダイレクトがたくさんある場合。

    黄色でハイライトされた行ではリダイレクトが実行されており、通常は、そのページにあるリンクが古いか、誤って作成されたことを示す。これによって不要なリダイレクトが作成され、ウォーターフォールの高さが無駄に伸びてしまう。これらのリンクは、新しいURLへの直接リンクと置き換えよう(ただし、アクセス解析や広告配信のシステムなど、自社でコントロールできない場合もある)。

高速化ポイント3 レンダリングの開始時間を早くする

レンダリングの開始時間(Start Render)とは、ユーザーがページ上で初めて空白ページ以外の何かを目にするまでの時間であることを思い出そう(WebPagetestでは緑色の縦線で示されている)。

あなたのレンダリング開始時間はどのくらいだろうか。1.5秒より長ければ、改善を試みるべきだ。それにはまず、レンダリング開始線の左側にあるすべてのリソースを見てほしい。レンダリング時間を短縮する最適化のために検討するべき対象は、すべてここにある。

以下に、いくつかヒントを挙げる。

  • JavaScriptライブラリを呼び出すコードがある場合。

    JavaScriptを含めるとページのレンダリングがブロックされることがある。可能ならば、そのJavaScriptを読み込むコードを、ページの下のほうに移動しよう。

  • CSS要素ごとのリクエストがたくさんある場合。

    ブラウザはすべてのCSSがダウンロードされるのを待ってから、ページのレンダリングを開始する。これらのCSSファイルのいずれかを、1つのファイルにまとめたり、HTML内に記述したりできないだろうか。

  • 外部フォントがある場合。

    外部フォントを利用すると、ブラウザはそのフォントをダウンロードするまで何も描画しない。可能なら、外部から読み込むフォントを使うのは避けよう。

    どうしても必要な場合は、そのフォントを読み込むための無用な302リダイレクトをすべて削除するよう徹底するか、あるいは、(こちらのほうがより望ましいが)そのフォントのコピーを自分が使っているウェブサーバー上にホスティングすることを検討しよう。

たとえば、以下はウォーターフォール図の先頭部分だ。

緑色のレンダリング開始線は1秒を少し過ぎただけのところにあり、これなら上出来だ。ただし、線の左側を見ると、いくつか最適化するべき点があるのがわかる。まず、複数のjs(JavaScript)ファイルがある。jQuery以外のファイルは、読み込むのを後回しにできるだろう。さらに、CSSファイルも複数ある。これらのファイルはまとめられる。こうした最適化によってレンダリング開始時間を短縮できるだろう。

これらの最適化を行うには、デザイナーや開発者と調整する必要があるかもしれない。ただし、それだけの価値は十分にある。空白画面など見つめていたい人などいないのだから!

その他のページ表示速度に関係する要因

サーバーの速度は十分か?

サーバーから最初の1バイトが到着するまでの時間(TTFB)が、検索エンジンの順位決定要因であることはよく知られている。

幸い、ウォーターフォールを見ると、この時間指標がわかる。図の1行目を見ればいいだけだ。ベースとなるHTMLページをブラウザがダウンロードするのにかかる時間情報が表示されているはずだ。

TTFBの測定値を見てほしい。これが約500ミリ秒より長い場合、サーバーはパワー不足か、最適化されていない可能性がある。サーバーの管理者に相談して、サーバーの能力を上げてもらおう。下図は、サーバーが応答に10秒近くもかかっていたウォーターフォール図の例だ。これは遅すぎる!

CDNは必要か?

レイテンシ(リクエストごとの応答の遅延)は、ウェブサイトの表示が遅い大きな要因になることもあり、サーバーとウェブサイト訪問者の地理的距離と関係がある。以前にも取り上げたように、レイテンシは距離と光の速さで決まるもので、高速インターネット接続だけでは問題を解決できない。

コンテンツ配信ネットワーク(CDN)を利用すると、世界中に散らばっている静的アセット(画像、CSS、JavaScriptファイルなど)のコピーを保存してウェブサイトを高速化でき、訪問者の待ち時間を減らせる。

ウォーターフォール図を見れば、レイテンシがサイトの速度に及ぼしている影響や、CDNを利用すべきかどうかがわかる。ブラウザがサーバーに静的アセットを要求しているリクエストのTTFB値を見ればいい。TTFBは、リクエストがサーバーに送られる時間、サーバーがそれを処理する時間、レスポンスの最初の1バイトが戻ってくるまで時間からなる。

静的アセットの場合、サーバーはリクエストを処理する必要が一切ないため、TTFBの測定値は、実際にはリクエストが送られてからレスポンスが戻ってくるまでの往復時間になる。往復時間の数字が大きい場合は、コンテンツが訪問者から遠く離れすぎていることを意味する。

CDNが必要かどうかを判断するには、まずサーバーの場所を知る必要がある。次に、WebPagetestを使って、サーバーから遠く離れた場所でテストを実行する(URLを指定する画面で、どの場所からテストするかを指定できる)。サイトが米国でホストされている場合は、アジアかヨーロッパでテストを実行しよう。

そのウォーターフォール図で、サーバー上の画像またはCSSファイルへのリクエスト行をいくつか探して、TTFB測定値を見てほしい。静的コンテンツのTTFBが150ミリ秒を超える場合は、CDNの利用を検討するべきだ。

商用サイトの場合は、Akamaiのエンタープライズ向け機能に目を向けるのもいいだろう。もっと安価な選択肢を探すなら、無料のCDNサービスを提供しているCloudFlareをチェックしてみよう。

終わりに

実は、ウォーターフォール図から得られるパフォーマンスの知見という点で、今回はごく一部をかじった程度にすぎない。しかし、図を読み取って、サイトを遅くしている最も基本的で影響の大きいパフォーマンスの問題を検出する方法を理解するには、これで十分すぎるほどだ。

コンテンツを最適化して、各リソースを可能な限り速く受け取るようにすれば、ウォーターフォール図の幅を縮められる。不要なリクエストを削除すれば、図の高さを縮められる。最後に、レンダリング開始線より前にあるすべてのコンテンツを最適化すれば、ユーザーがページ上で初めてコンテンツを目にするまでの時間を短縮できる。

どこから始めればいいか、まだよくわからないという人は、ZoompfのFree Performance Reportをチェックしてほしい。自分のサイトを分析して、ページ速度とウォーターフォール図の指標を改善する上で、最も大きな影響を及ぼす修正点に優先順位を付けよう。

用語集
CSS / HTML / JavaScript / アクセス解析 / ダウンロード / リンク / 検索エンジン / 訪問者
この記事が役に立ったらシェア!
メルマガの登録はこちら Web担当者に役立つ情報をサクッとゲット!

人気記事トップ10(過去7日間)

今日の用語

インデックス
検索エンジンがWebページをデータベースに保存しているデータベース。データベース ...→用語集へ

インフォメーション

RSSフィード


Web担を応援して支えてくださっている企業さま [各サービス/製品の紹介はこちらから]