はじめに
高速なウェブアプリは成功するウェブアプリです。アプリの実際のパフォーマンスと認識されているパフォーマンスの両方を最適化するまで、デベロッパーとしての仕事は終わりません。優れたユーザー エクスペリエンスを実現するためには、単に正しいだけでなく、最適化すべき実用的で重要なビジネス上の理由もあります。Amazon はサイト レイテンシ 100 ミリ秒ごとに 1% の売上減少を測定し、Google は 0.5 秒の遅延ごとにトラフィックの 20% 減少を測定しました（出典）。これらは実際の数値であり、ビジネスやウェブアプリに実際に影響します。
ウェブの速度は非常に重要であり、Google はウェブの高速化に全力を尽くしています。アプリのパフォーマンスを最適化する別の理由が必要な場合は、Google のランキング アルゴリズムにページ速度が追加されたことが発表されました。
ウェブアプリのパフォーマンスを最適化するためのベスト プラクティスが数多く公開されています。その 2 冊の著書（High Performance Web Sites と Even Higher Web Sites）もその 1 つです。サーバー上（正しいキャッシュ制御ヘッダーを実装）とクライアント上（画像の幅と高さの属性を指定）の手法を組み合わせ、エンドツーエンドの戦略のパフォーマンスを最適化します。ヒントやコツがたくさんあると、すべて実生活や実際のウェブアプリにどのようにマッピングされるかを判断するのが難しい場合があります。
Chrome DevTools（Chrome のすべてのインスタンスに搭載）は、ウェブアプリを検査して、パフォーマンスの向上と遅延の短縮に役立つカスタマイズされた推奨事項を提供する優れたツールです。この記事では、非常に広く利用されている YSlow ツールと同様の機能である [Audits Panel] について説明します。また、これを使用してウェブサイトの処理速度を上げ、レイテンシを短縮し、ユーザー満足度を高める方法についても解説します。
Audits Panel ツールは現在 Chrome でのみご利用いただけますが、今後他の WebKit ブラウザにも統合される予定です。
はじめに
Audits Panel がウェブアプリのパフォーマンス改善をどのように推奨できるかを示すために、このツールを Google 独自の www.html5rocks.com に転換します。Audits Panel を使用して、サイトをさらに高速化します。
DevTools の起動は、Chrome アイコン（Chrome ウィンドウの右上）を使用して、[ツール] > [デベロッパー ツール] を選択するだけで簡単に行えます。
DevTools の使用方法について詳しくは、公式ドキュメントをご覧ください。
監査パネルは、メインのツールボタンのパネルにあります。選択すると、Audits Panel でウェブアプリの分析がまだ実行されていないことがわかります。特に Gmail などの大規模なウェブアプリの場合は、すべてのヒューリスティックの実行が遅くなるため、ツールはデフォルトで無効になっています。
[Run] ボタンをクリックすると、パフォーマンス ヒューリスティックを有効にしてウェブアプリが再読み込みされます。ページを再読み込みすると、以下のスクリーンショットのような最適化案のリストが表示されます。
監査パネルでは、重要度によって提案が分類されています。重要度の高いものには赤い丸、重要度が中程度の候補には黄色の丸が示されます。この色分けにより、最も重要（かつ最大のメリット）を優先して提案に優先順位を付けることができます。
提案の後にあるかっこ内の数字は、監査ツールが検出したインスタンス数です。たとえば、「ブラウザ キャッシュを活用する」の事例は 12 件でした。これにより、提案が適用される頻度が大まかにわかります。
スピード戦略
前述のように、ウェブアプリのパフォーマンスを最適化するには、よく知られ、十分にテストされた戦略が多数あります。この記事ではそのすべてについて詳しく説明しませんが、詳細情報を簡単に確認できます。ウェブアプリの最適化について詳しく知るための有用なリソースには、ウェブを高速化するチュートリアルや、高スケーラビリティのレイテンシはあらゆる場所にあり、売上にコストがかかるなどがあります。
監査パネルでは、その提案が [ネットワーク使用率] と [ウェブページ パフォーマンス] の 2 つのカテゴリに分類されます。
Audits Panel によると、ネットワーク使用率を改善するには:
- ブラウザ キャッシュの活用
- プロキシ キャッシュの活用
- Cookie サイズを最小化
- Cookie を使わないドメインから静的コンテンツを配信する
- 画像サイズを指定する
ウェブページのパフォーマンスを改善するには、どうすればよいですか。
- スタイルとスクリプトの順序を最適化する
- 未使用の CSS ルールを削除する
htmlrocks.com のパフォーマンスを向上させるために重視できる戦略の 1 つを見てみましょう。
ブラウザのキャッシュを活用する
例として、まずブラウザ キャッシュの活用に関する推奨事項から見ていきましょう。具体的にはどういうことでしょうか。UI でオプションを開くと、次の詳細が表示されます。
- 次のリソースにキャッシュの有効期限がありません。有効期限が指定されていないリソースは、ブラウザでキャッシュできません。
- 次のキャッシュ可能なリソースの更新期限は短いです。
- 次のリソースは明示的にキャッシュに保存できません。可能であれば、キャッシュ可能にすることを検討してください。
リソースのキャッシュ保存は、ネットワーク使用率を向上させる優れた方法です。これにより、開発者は帯域幅課金を削減し、ユーザーの応答時間を短縮できます。残念ながら、このツールでは必要な作業が正確に示されないため、推奨事項を少し掘り下げ、ウェブアプリのパフォーマンス最適化に関する知識を活かして、これらの推奨事項を適用する必要があります。
キャッシュ
HTTP キャッシュについて詳しく説明しなくても、基本の一部は確実に説明できます。HTTP プロトコルにはキャッシュ保存の手順が含まれるため、サーバーとクライアントはネットワーク経由で転送する必要のあるデータの量を削減できます。たとえば、サーバーはリソースを一定期間ローカルに保存するようクライアントに伝えることで、リソースを再度リクエストする必要がなくなります。クライアントは、サーバーのリソースがローカルに保存されているリソースよりも新しいかどうかを尋ねることもできます。リソースが静的である場合、サーバーはリソースをローカルに保存するようクライアントに伝えることで、今後サーバーにリソースを要求しないようにするのが理想的です。ご想像のとおり、HTTP キャッシュについては非常に多くの詳細情報がありますが、一般的なテーマは「リソースをローカルのクライアントに保存することで、有線で送信されるデータの量を減らす」ことです。
キャッシュに保存できないリソースの修正
1 つの推奨事項を詳しく見て、監査の推奨事項を DevTools 内の他のツールに接続する方法を学びます。具体的には、「次のリソースは明示的にキャッシュ不可です」という場合の解決方法を見てみましょう。
キャッシュ保存は HTTP プロトコルを介して行われるため、http://www.html5rocks.com/ リソースの HTTP リクエストとレスポンスを確認する必要があります。リソースをクリックするだけで、元のリクエストとレスポンスのヘッダーと詳細が表示されます。
クリックしたリソースの種類に応じて、[Network]、[Resources]、または [Sources] パネルが開き、詳細情報が表示されます。この場合、[Network] パネルが表示されます。
サーバーがクライアントに「html5rocks.com のホームページをキャッシュしない」と通知したことを確認しようとしています。そのために、リソースをクリックしてレスポンス ヘッダーを確認します。これらはサーバーから送信されたヘッダーと指示です。
Cache-Control ヘッダー。無事に、サーバーは「Cache-Control: no-cache」ヘッダーをクライアントに送信しました。これは、ご想像のとおり、クライアントは常にリソースを要求し、それをローカルにキャッシュしないように指示します。具体的には、「no-cache」の HTTP 仕様は以下のようになります。
「no-cache ディレクティブがフィールド名を指定していない場合、キャッシュは、送信元サーバーとの再検証に成功しない限り、レスポンスを使用して後続のリクエストを処理してはなりません。これにより、送信元サーバーは、クライアント リクエストに対して古いレスポンスを返すよう設定されたキャッシュでもキャッシュ保存を回避できます。」
これが、監査パネルがキャッシュの有効化を推奨している理由そのものです。キャッシュを有効にしないと、サーバーとクライアントから冗長な情報が送信される可能性があるためです。
監査の提案の根本原因を確認できたので、修正方法を確認してみましょう。この場合、ソリューションにはサーバーサイドの構成またはコードが含まれます。設定によっては、ウェブサーバーの構成またはウェブアプリ フレームワークの構成を介してキャッシュを有効にできます。具体的には、キャッシュするリソースについて、有効期限ヘッダーと Cache-Control: private と max-age パラメータを含める必要があります。
候補はただのツールです。候補
監査パネルでは、一般的なヒューリスティックに基づく改善が推奨されています。長年にわたって学んできたベスト プラクティスを特定のウェブアプリに応用しています。ほとんどの場合、これらの推奨事項はぴったりであり、念頭に置く必要があります。
ただし、その推奨案が正しいとしても、実際には改善につながらないケースもあります。たとえば、ページに大きい画像が 1 つしかない場合、監査パネルは、幅と高さの属性を <img> タグに追加することを推奨します（これにより、画像をダウンロードして検査しなくてもレンダリング エンジンが画像のサイズを認識できるようになります）。これは一般的に優れたアドバイスですが、ページ上の唯一の要素である場合はあまり役に立ちません。
これらの提案を理解したら、忘れずに適用してください。また、変更の前後でパフォーマンスを測定し、実際に改善が見られるようにしてください。
概要
[Audits] パネルは、ウェブアプリのパフォーマンスを最適化する方法をすばやく確認できる、使いやすい優れたツールです。多くの企業では、パフォーマンスと収益やアクティビティの間に直接的な相関関係があることがわかっています。そのため、速度はウェブアプリの重要な属性です。アプリのパフォーマンスを最適化することは、ユーザーにとって正しいことであるだけでなく、ビジネスの最終利益のためにも正しいことです。