このページは Cloud Translation API によって翻訳されました。

ウェブアプリの速度を監査する

Seth Ladd

はじめに

高速なウェブアプリは成功するウェブアプリです。デベロッパーとしての作業は、アプリの実際のパフォーマンスとユーザーが感じるパフォーマンスの両方を最適化するまで完了しません。これは、ユーザーに優れたエクスペリエンスを提供するために必要なことであるだけでなく、最適化には実用的で重要なビジネス上の理由もあります。Amazon では、サイトのレイテンシが 100 ミリ秒長くなるごとに売り上げが 1% 減少し、Google では 0.5 秒の遅延ごとにトラフィックが 20% 減少することが測定されています（引用）。これらは実際の数値であり、ビジネスとウェブアプリに実際の影響を与えます。

ウェブの速度は非常に重要であるため、Google はウェブの高速化に専念するチームを結成しています。アプリのパフォーマンスを最適化する理由が他にもあるとしたら、Google がランキングアルゴリズムにページ速度を追加したことを発表したことです。

ウェブアプリのパフォーマンスを最適化するためのベストプラクティスは、多くの書籍で紹介されています。そのうちの 2 冊（High Performance Web Sites と Even Faster Web Sites）は特におすすめです。サーバー側（正しいキャッシュ制御ヘッダーを実装）とクライアント側（画像の幅と高さの属性を指定する）のテクニックを組み合わせて、エンドツーエンドの戦略を策定し、パフォーマンスを最適化します。さまざまなヒントやコツがあるため、それらが実際のウェブアプリにどのように適用されるかを判断するのが難しい場合があります。

幸い、Chrome DevTools（すべての Chrome インスタンスに含まれています）には、ウェブアプリを検査し、パフォーマンスを向上させてレイテンシを短縮するためのカスタマイズされた推奨事項を提示する優れたツールが用意されています。この記事では、非常に人気のある YSlow ツールとスコープが類似している監査パネルと、このパネルを使用してウェブサイトの速度を上げ、レイテンシを短縮し、ユーザー満足度を高める方法について説明します。

なお、監査パネルツールは現在 Chrome でのみご利用いただけますが、他の WebKit ブラウザにも統合される予定です。

スタートガイド

監査パネルでウェブアプリのパフォーマンス改善案を検討する方法について説明するため、Google の www.html5rocks.com を例にとり、監査パネルを使ってサイトの速度をさらに高めてみましょう。

DevTools を起動するには、Chrome アイコン（Chrome ウィンドウの右上）を使用して、[ツール] > [デベロッパーツール] を選択するだけです。

DevTools の使用方法について詳しくは、公式ドキュメントをご覧ください。

監査パネルは、メインツールボタンパネルにあります。選択しても、監査パネルでウェブアプリの分析は実行されません。すべてのヒューリスティクスを実行すると、特に GMail などの大規模なウェブアプリでは時間がかかるため、このツールはデフォルトで無効になっています。

では、[Run] ボタンをクリックして、パフォーマンスのヒューリスティクスがオンになった状態でウェブアプリを再読み込みしましょう。ページが再読み込みされると、以下のスクリーンショットのようなおすすめコンテンツのリストが表示されます。

監査パネルでは、提案が重大度別に分類され、最も重大な提案は赤いドットで、中程度の重大度の提案は黄色のドットで示されます。この色分けは、最も重要な（および最も効果が大きい）提案に最初に取り組むよう、提案の優先順位付けに役立ちます。

提案の後に続くかっこ内の数字は、監査ツールが検出したインスタンスの数です。たとえば、「ブラウザのキャッシュを利用」が 12 回検出されました。これにより、その推奨事項を適用できる頻度を把握できます。

スピード戦略

前述のとおり、ウェブアプリのパフォーマンスを最適化するための、よく知られ、十分にテストされた戦略は数多くあります。この記事では、これらの機能について詳しく説明することはありませんが、詳細については簡単に確認できます。ウェブアプリの最適化の詳細については、ウェブの高速化に関するチュートリアルと高スケーラビリティのレイテンシはどこにでも存在し、売り上げに影響するをご覧ください。

[監査] パネルでは、最適化案が [ネットワーク使用率] と [ウェブページのパフォーマンス] の 2 つのカテゴリに分類されます。

監査パネルによると、ネットワーク使用率を改善するには、次の対応が必要です。

ブラウザキャッシュを利用する
プロキシキャッシュを利用する
Cookie サイズを最小化する
Cookie を使わないドメインから静的コンテンツを提供する
画像のサイズを指定する

ウェブページのパフォーマンスを改善するには、次のことを行います。

スタイルとスクリプトの順序を最適化する
未使用の CSS ルールを削除する

htmlrocks.com のパフォーマンスを改善するために重点的に取り組むべき戦略の一つを見てみましょう。

ブラウザのキャッシュを活用する

たとえば、まずブラウザのキャッシュを活用することをおすすめします。具体的にはどういう意味ですか？UI でこのオプションを開くと、次の詳細が表示されます。

監査パネルには、パフォーマンスを改善するための推奨事項が表示されます。 — [監査] パネルには、パフォーマンスを改善するための推奨事項が表示されます。

次のリソースにはキャッシュの有効期限がありません。有効期限が指定されていないリソースは、ブラウザによってキャッシュに保存されない場合があります。
次のキャッシュに保存可能なリソースは、鮮度が短いリソースです。
次のリソースは明示的にキャッシュに保存できません。可能であれば、キャッシュに保存できるようにすることを検討してください。

リソースをキャッシュに保存することは、ネットワークの使用率を改善するための優れた方法です。これにより、デベロッパーの帯域幅の請求額が削減され、ユーザーのレスポンス時間が短縮されます。残念ながら、このツールでは具体的な対処方法は示されません。そのため、最適化案を詳しく確認し、ウェブアプリのパフォーマンス最適化に関する知識を活用して、これらの最適化案を適用する必要があります。

キャッシュ

HTTP キャッシュに深く立ち入ることなく、基本的な部分を説明します。HTTP プロトコルにはキャッシュインストラクションが含まれています。これにより、サーバー側とクライアント側で、ワイヤーを介して転送する必要があるデータ量を削減できます。たとえば、サーバーはリソースをローカルに一定期間保存するようにクライアントに指示できます。これにより、リソースを再度リクエストする必要がなくなります。クライアントは、サーバーのリソースがローカルに保存されているリソースよりも新しいかどうかを問い合わせることもできます。リソースが静的である場合は、サーバーがリソースをローカルに保存し、今後リソースをサーバーにリクエストしないようにクライアントに指示するのが理想的です。HTTP キャッシュには膨大な詳細がありますが、一般的なテーマは「リソースをクライアントにローカルに保存することで、ワイヤーを介して送信されるデータの量を削減する」ことです。

キャッシュに保存できないリソースの修正

1 つの推奨事項を詳しく見て、Audit の推奨事項を DevTools 内の他のツールに接続する方法を確認しましょう。具体的には、「次のリソースは明示的にキャッシュに保存できない」という問題を解決する方法について説明します。

キャッシュは HTTP プロトコル経由で取得されるため、http://www.html5rocks.com/ リソースの HTTP リクエストとレスポンスを確認する必要があります。リソースをクリックするだけで、元のリクエストとレスポンスのヘッダーと詳細を確認できます。

クリックしたリソースの種類に応じて、[ネットワーク]、[リソース]、または [ソース] パネルに移動し、詳細情報が表示されます。この場合、[ネットワーク] パネルが表示されます。

サーバーがクライアントに「html5rocks.com のホームページをキャッシュに保存しないでください」と指示したことを確認しようとしています。そのためには、リソースをクリックしてレスポンスヘッダーを確認します。これは、サーバーから送信されるヘッダーと指示です。

例: Cache-Control ヘッダー。 — 例: `Cache-Control` ヘッダー。

確かに、サーバーは「Cache-Control: no-cache」ヘッダーをクライアントに送信しています。ご想像のとおり、これはクライアントに、リソースを常にリクエストし、ローカルにキャッシュに保存しないように指示します。具体的には、「no-cache」の HTTP 仕様には次のように記載されています。

「no-cache ディレクティブでフィールド名が指定されていない場合、キャッシュは、送信元サーバーで正常に再検証せずに、レスポンスを使用して後続のリクエストを処理してはなりません。これにより、配信元サーバーは、クライアントリクエストに古いレスポンスを返すように構成されたキャッシュであっても、キャッシュを防止できます。」

そのため、監査パネルではキャッシュを有効にすることをおすすめしています。キャッシュを有効にしないと、サーバーやクライアントが冗長な情報を送信する可能性があるためです。

監査の提案の根本原因を確認したので、次に修正方法を説明します。この場合、ソリューションはサーバーサイドの構成またはコードに関連しています。設定に応じて、ウェブサーバーの構成またはウェブアプリフレームワークの構成でキャッシュを有効にできます。具体的には、キャッシュに保存するリソースには、Expires ヘッダーと、max-age パラメータを含む Cache-Control: private を追加する必要があります。

候補はあくまで候補です

なお、監査パネルでは、一般的なヒューリスティックに基づいて改善案が提案されます。長年にわたって学んできたベストプラクティスを、特定のウェブアプリに適用するものです。ほとんどの場合、これらの推奨事項は的確であり、参考にする必要があります。

ただし、推奨事項が正しいにもかかわらず、実際には改善につながらない場合があります。たとえば、ページに大きな画像が 1 つしかない場合は、<img> タグに width 属性と height 属性を追加することを監査パネルが推奨します（レンダリングエンジンが画像をダウンロードして検査しなくても画像のサイズを把握できるようにするためです）。これは一般的に良いアドバイスですが、ページ上の要素が画像のみの場合はあまり効果がありません。

これらの推奨事項を理解したら、必ず適用してください。変更前後のパフォーマンスを測定して、実際に改善されていることを確認してください。

概要

監査パネルは、ウェブアプリのパフォーマンスを最適化する方法を簡単に確認できる優れたツールです。多くの企業がパフォーマンスと収益やアクティビティに直接的な相関関係があることを発見しているため、ウェブアプリにとって速度は重要な要素です。アプリのパフォーマンスを最適化することは、ユーザーにとってだけでなく、ビジネスの収益にとっても正しい選択です。