目次


Web 2.0 アプリケーションのパフォーマンスを改善する

ブラウザー・サイドのさまざまなキャッシュ・メカニズムを探る

Comments

はじめに

Web 2.0 アプリケーションの出現と人気によって、インターネットの使い方が変わってきたことから、コンテンツ管理、情報の共有、通信、チームワークなどの手法が、よりユーザーを中心としたものになりつつあります。技術的観点からみると、Web 2.0 アプリケーションがもたらした新しい技術の飛躍的進歩はそれほど多くありませんが、Web 2.0 アプリケーションがインターネットの使い方に新たなパターンをもたらしたことは事実です。現在、Web 2.0 アプリケーションには数多くの共通する特徴があります。例えば、リッチ・クライアントがある、ページ・サイズが大きい、ページ上に数多くの小さな項目がある、JavaScript コーディングで溢れているなどの特徴です。しかしブラウザー・サイドでは、これらの特徴がパフォーマンス上の問題を引き起こす可能性があります。それは、長距離ネットワークの場合には特に言えることです。パフォーマンス上の問題はユーザーのエクスペリエンスに悪影響を及ぼすものの、その問題が存在していることに開発者が気付かないことさえあります。開発者は優れたネットワーク環境で作業をしているため、パフォーマンス上の問題を完全に明らかにするのは難しい場合があります。

この記事ではまず始めに典型的な Web 2.0 アプリケーションの重要な側面を分析し、それがブラウザー・サイドのパフォーマンスにどのような影響を与えるのかを説明します。続いてブラウザー・サイドのパフォーマンスにとって極めて重要な、ブラウザーのキャッシュについて説明します。ユーザーが快適にアプリケーションを使用できるようにするには、適切なキャッシュ設定が必要になります。全体を考慮したキャッシュ・ポリシーを設計しなければ、望ましいパフォーマンスを達成できないだけでなく、機能的欠陥が生じることにもなりかねません。

ブラウザーのキャッシュに影響を及ぼす設定は数多くあります。簡単に言うと、それは Cache-Control、Etag、Expires、Last-Modified、そして Vary などです。これらの設定にはそれぞれに異なる意味と、最適な使用方法があります。難しい点は、同じ設定をしても、よく使われているブラウザーのすべてがすべて、同じ振る舞いを見せるわけではないことです。したがって、これらの設定を使用すると決める前に、それぞれのブラウザーの動作を正確に把握しなければなりません。この記事では、現在市場でとりわけ人気のあるブラウザーとして、Internet Explorer、Firefox、Chrome、および Safari についての振る舞いを見て行きます。

また記事では IBM® Mashups とオープンソースの「Roller Weblogger」を使用して、ブラウザーのキャッシュを最適に使用するために異なるディレクティブを適用する例を紹介します。

背景

最近のインターネット環境では、Web 2.0 アプリケーションの人気が高まりつつあり、Facebook や Youtube をはじめとする多くの Web サイトが Web 2.0 技術をベースとしています。また、IBM でも Lotus Connections、Lotus Mashups などの Web 2.0 アプリケーションを用意しています。

ブラウザーの応答時間を測る基本的な方法では、以下の式を使います。

  • ブラウザーの応答時間 = サーバー・サイドでの処理時間 + ページのロード時間 + ブラウザーのレンダリング時間
  • ページのロード時間 = (リクエスト数 / 並行性) * 待ち時間 + ページの合計サイズ / 帯域幅

上記の式の内容は以下のとおりです。

  • 「サーバー・サイドの処理時間」は、サーバー・サイドでのプロセスにかかる時間です。これらのプロセスには、LDAP による認証や、データベースからの情報取得などがあります。
  • 「ブラウザーのレンダリング時間」は、ブラウザーがページをレダリングするために必要な時間です。JavaScript の実行や DOM ツリーの解析などのアクティビティーも、この時間に含まれます。
  • 「リクエスト数」は、HTTP リクエストの数です。
  • 「並行性」は、ブラウザーからサーバーへの並列接続の数です。
  • 「ページの合計サイズ」は、1 つのページの合計サイズです。
  • 「待ち時間」と「帯域幅」は、ネットワークの状態を測る手段です。一般的な長距離ネットワーク環境では、帯域幅は約 1M、待ち時間は約 100 ミリ秒となります。したがって、サイズを 100 キロバイトに縮小するか、リクエスト数を 1 に減らすと、レスポンス時間を 0.1 秒短縮することができます。

現実の状況は複雑であるため、この式が適用できない場合もあることに注意してください。

典型的な Web 2.0 リッチ・インターネット・アプリケーション (例えば、Lotus Mashup Maker) では、ブラウザーはまずフォーマット定義リクエストをサーバーに送信します。定義のレスポンス・データを受信すると、ブラウザーはサーバーにデータ・リクエストを送信し、続いてユーザーに対してページをレンダリングします。このパターンでは、JavaScript ファイルや CSS ファイルなどの数多くの小さな項目がリクエストされます。長距離ネットワーク環境の場合、このことがクライアントのパフォーマンス上の問題を引き起こし、ユーザー・エクスペリエンスに深刻な影響を及ぼす可能性があります。しかし、やり取りされるファイルのほとんどは静的ファイルで、キャッシュに入れることが可能です。したがって、正しいキャッシュ制御と有効期限のヘッダー、そしてブラウザーのキャッシュに影響するその他のヘッダー・メタデータを追加すれば、ユーザー・エクスペリエンスを改善できることは明らかです。

ブラウザーのキャッシュ・メカニズム

ブラウザーのキャッシュには複数の設定が影響を及ぼします。このセクションでは、設定のそれぞれについて説明します。

Cache-Control

Cache-Control は最も重要な設定です。このフィールドは、すべてのキャッシュ・メカニズムが一連のリクエスト/レスポンスで従わなければならないディレクティブを指定するために使用します。ディレクティブが指定するのは、キャッシュがリクエストやレスポンスに悪影響を与えることを防ぐための振る舞いです。通常、指定されたディレクティブは、デフォルトのキャッシュ・アルゴリズムに優先して使用されます。キャッシュ・ディレクティブが作用するのは一方向のみです。つまり、リクエストにディレクティブが含まれていても、同じディレクティブがそのレスポンスに組み込まれるというわけではありません。

Cache-Control を定義するには、「Cache-Control」の後にコロン (:)、そしてキャッシュ・ディレクティブを続けます。表 1 に、適用可能な値を記載します。

表 1. 一般的なキャッシュ・ディレクティブの値
キャッシュ・ディレクティブ説明
publicすべてのコンテンツがキャッシュされます。
privateコンテンツは専用キャッシュにのみキャッシュされます。
no-cacheコンテンツはキャッシュされません。
no-storeコンテンツはキャッシュにも、インターネット一時ファイルにも保存されません。
must-revalidation/proxy-revalidationキャッシュされたコンテンツが古くなっている場合、そのコンテンツの有効性を再確認するためのリクエストをサーバー/プロキシーに送信する必要があります。
max-age=xxx (xxx は数値)キャッシュされたコンテンツは xxx 秒後に有効期限が切れます。

表 2 では、キャッシュ・ディレクティブの設定に応じて、ブラウザーがサーバーにリクエストを再送信するのか、またはキャッシュされたコンテンツを使用するのかを示しています。

表 2. キャッシュ・ディレクティブの値に応じたブラウザーのレスポンス
キャッシュ・ディレクティブ新規ブラウザー・ウィンドウを開いた場合元のウィンドウで Enter を押した場合更新が行われた場合「戻る」ボタンを押した場合
publicブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはサーバーにリクエストを再送信します。ブラウザーはキャッシュに保存されているページをレンダリングします。
privateブラウザーはサーバーにリクエストを再送信します。最初のオカレンスでは、ブラウザーはサーバーにリクエストを送信します。それ以降のオカレンスでは、キャッシュに保存されているページをレンダリングします。ブラウザーはサーバーにリクエストを再送信します。ブラウザーはキャッシュに保存されているページをレンダリングします。
no-cache/no-storeブラウザーはサーバーにリクエストを再送信します。ブラウザーはサーバーにリクエストを再送信します。ブラウザーはサーバーにリクエストを再送信します。ブラウザーはサーバーにリクエストを再送信します。
must-revalidation/proxy-revalidationブラウザーはサーバーにリクエストを再送信します。最初のオカレンスでは、ブラウザーはサーバーにリクエストを送信します。それ以降のオカレンスでは、キャッシュに保存されているページをレンダリングします。ブラウザーはサーバーにリクエストを再送信します。ブラウザーはキャッシュに保存されているページをレンダリングします。
max-age=xxx (xxx は数値)xxx 秒を経過している場合、ブラウザーはサーバーにリクエストを再送信します。xxx 秒を経過している場合、ブラウザーはサーバーにリクエストを再送信します。ブラウザーはサーバーにリクエストを再送信します。xxx 秒を経過している場合、ブラウザーはサーバーにリクエストを再送信します。

Cache-Control は、Expires や Last-Modified などの他の設定に優先して適用されるため、ブラウザーのキャッシュにとって最も重要な設定です。さらに、それぞれのブラウザーの振る舞いは基本的に共通することから、特定のブラウザーに依存しないキャッシュ設定を行うには、このプロパティーが最も効率的な手段となります。

Expires

Expires エンティティー・ヘッダー・フィールドに指定した日時を過ぎると、レスポンスは古いものであるとみなされます。通常、古くなったキャッシュ・エントリーは、まず送信元のサーバーで (または、エンティティーの新しいコピーを持つ中間キャッシュで) 有効性を確認されない限り、キャッシュ (プロキシー・キャッシュまたはユーザー・エージェント・キャッシュ) から返されることはありません。(注: Cache-Control の max-age および s-maxage は Expires ヘッダーに優先して使用されます。)

Expires は、「Expires: Sun, 08 Nov 2009 03:37:26 GMT」というフォーマットで値を取ります。コンテンツを表示する日付がこのヘッダーに指定された日付の前であれば、キャッシュ内のコンテンツの有効期限は切れていないとみなされて、キャッシュからコンテンツが描画されます。日付が過ぎている場合、コンテンツは失効しているとみなされ、キャッシュが何らかのアクションを行います。表 3 から表 6 に、さまざまなユーザー操作に対して、各ブラウザーがどのように振る舞うかを説明します。

表 3. ユーザーが新規ブラウザー・ウィンドウを開いた場合の Expires アクション
Firefox 3.5IE 8Chrome 3Safari 4
コンテンツが古くなっていない場合ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはキャッシュに保存されているページをレンダリングします。
コンテンツが古くなっている場合ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。
表 4. ユーザーが元のブラウザー・ウィンドウで Enter を押した場合の Expires アクション
Firefox 3.5IE 8Chrome 3Safari 4
コンテンツが古くなっていない場合ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 304 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 304 です。
コンテンツが古くなっている場合ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはキャッシュに保存されているページをレンダリングしますブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。
表 5. ユーザーが F5 を押してページを更新した場合の Expires アクション
Firefox 3.5IE 8Chrome 3Safari 4
コンテンツが古くなっていない場合ブラウザーはサーバーにリクエストを再送信します。戻りコードは 304 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 304 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 304 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 304 です。
コンテンツが古くなっている場合ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。
表 6. ユーザーが「戻る」ボタンまたは「進む」ボタンを押した場合の Expires アクション
Firefox 3.5IE 8Chrome 3Safari 4
コンテンツが古くなっていない場合ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはキャッシュに保存されているページをレンダリングします。
コンテンツが古くなっている場合ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。

: 上記のすべてのブラウザーはデフォルト設定で動作していることを前提とします。

Last-Modified/ETag

Last-Modified エンティティー・ヘッダー・フィールドの値は、キャッシュ・バリデーターとして使われることがよくあります。簡単に言うと、Last-Modified の値より後にエンティティーが変更されていない場合には、キャッシュ・エントリーは有効であるとみなされます。ETag はエンティティー・タグの 1 つで、ETag レスポンス・ヘッダー・フィールドの値は、「柔軟な」キャッシュ・バリデーターとなります。変更日付を保管すると都合が悪い場合や、HTTP の日付の値としては 1 秒の解像度では不十分な場合、あるいは送信元のサーバーが、変更日付を使用することによって生じる特定の矛盾を避けたいという場合には、ETag を使用すると、より確実に有効性を確認することができます。

この構成に応じた振る舞いは、それぞれのブラウザーによって異なります。表 7 から表 10 に、さまざまなユーザー操作に対する各ブラウザーの振る舞いを示します。

表 7. ユーザーが新規ブラウザー・ウィンドウを開いた場合の Last-Modified/ETag アクション
Firefox 3.5IE 8Chrome 3Safari 4
最後のアクセス以降にコンテンツが変更されていない場合ブラウザーはサーバーにリクエストを再送信します。戻りコードは 304 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 304 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 304 です。
最後のアクセス以降にコンテンツが変更された場合ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。
表 8. ユーザーが元のブラウザー・ウィンドウで Enter を押した場合の Last-Modified/ETag アクション
Firefox 3.5IE 8Chrome 3Safari 4
最後のアクセス以降にコンテンツが変更されていない場合ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 304 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 304 です。
最後のアクセス以降にコンテンツが変更された場合ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。
表 9. ユーザーが F5 を押してページを更新した場合の Last-Modified/ETag アクション
Firefox 3.5IE 8Chrome 3Safari 4
最後のアクセス以降にコンテンツが変更されていない場合ブラウザーはサーバーにリクエストを再送信します。戻りコードは 304 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 304 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 304 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 304 です。
最後のアクセス以降にコンテンツが変更された場合ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。
表 10. キャッシュ設定が使用されていない状態でユーザーが「戻る」ボタンまたは「進む」ボタンを押した場合
Firefox 3.5IE 8Chrome 3Safari 4
最後のアクセス以降にコンテンツが変更されていない場合ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはキャッシュに保存されているページをレンダリングします。
最後のアクセス以降にコンテンツが変更された場合ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。

注: 上記のすべてのブラウザーはデフォルト設定で動作していることを前提とします。

キャッシュ関連の設定を使用しない場合

キャッシュ関連の設定を定義しない場合、ブラウザーによって振る舞いが異なってきます。さらに、同じブラウザーであっても、同じ操作に対して異なる振る舞いを見せることもあるため、複雑になってきます。また、キャッシュに入れるべきでないコンテンツがキャッシュされて、セキュリティーの問題が生じることさえあります。

ブラウザーが異なれば、その振る舞いも異なります。表 11 に、キャッシュ設定が使用されていない場合の各ブラウザーの振る舞いを説明します。

表 11. キャッシュ設定が使用されていないブラウザーでユーザーが新規ウィンドウを開いている状態
Firefox 3.5IE 8Chrome 3Safari 4
新しいページを開いた場合ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。
元のウィンドウで Enter を押した場合ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。
F5 を押して更新した場合ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。
「戻る」ボタンまたは「進む」ボタンを押した場合ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはキャッシュに保存されているページをレンダリングします。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。ブラウザーはサーバーにリクエストを再送信します。戻りコードは 200 です。

注: 上記のすべてのブラウザーはデフォルト設定で動作していることを前提とします。

サンプル・アプリケーション

このセクションでは、IBM 製の市販ツールとオープンソース・ツールのそれぞれを使用して Web サイトを分析し、正しいキャッシュの振る舞いを判断する例を紹介します。

Apache Roller Weblogger

Apache Roller Weblogger はオープンソースの Web 2.0 アプリケーションです。このオープンソースの Java™ ブログ・サーバーは、blogs.sun.com、blog.usa.gov、IBM Lotus Connections、IBM DeveloperWorks Blogs など、さまざまなブログで使用されています。

この記事では IBM My developerWorks Blogs を例に、キャッシュ設定の詳細を説明します。図 1 に、My developerWorks Blogs ページのスクリーン・ショットを示します。

図 1. My developerWorks Blogs ページ
ページの左側にはタグ付きのコントロール・パネル、中央には表示可能なブログのリスト、右側には主なブログのリストと著者の写真が示されています。
ページの左側にはタグ付きのコントロール・パネル、中央には表示可能なブログのリスト、右側には主なブログのリストと著者の写真が示されています。

このページに対するリクエスト数は 62 で、そのほとんどは png、gif、js、またはその他の静的ファイルのタイプです。ユーザーが初めてこのページにアクセスすると、ブラウザーにページ全体が表示されるまでに約 16 秒かかります。正しいキャッシュ設定を定義すれば、リソースの大部分はブラウザー・サイドでキャッシュに入れられることになります。そのためユーザーがページに再びアクセスしたときのページに対するリクエスト数が 22 に減り、ロード時間が約 6 秒に短縮されます。これは、ユーザー・エクスペリエンスの大幅な改善となります。

これから、リクエストのキャッシュに関する重要な設定を分析します。この分析に関係のある Weblogger 出力は図 2 に示すとおりです。

図 2. My developerWorks Blogs ホームのレスポンス・ヘッダー 1
2 つの行が赤枠で囲まれています。1 行目は「Last-Modified Tue, 13 Oct 2009 05:48:08 GMT」、2 行目は「Cache-Control public, must-revalidate, max-age=5」となっています。
2 つの行が赤枠で囲まれています。1 行目は「Last-Modified Tue, 13 Oct 2009 05:48:08 GMT」、2 行目は「Cache-Control public, must-revalidate, max-age=5」となっています。

まず、Cache-Control が Last-Modified 設定よりも優先されるため、ページをローカル・キャッシュに 5 秒間キャッシュしておくことができます。ただし、コンテンツの有効期限が切れているかどうかの再確認は必要です。ユーザーがこのページにアクセスすると、ブラウザーは最初にローカル・キャッシュをチェックし、ローカル・ファイルが失効しているかどうかを判断します。コンテンツが古くなっている場合、ブラウザーは Last-Modified タイムスタンプと比較するためにサーバーにリクエストを送信します。レスポンス・ファイルの Last-Modified タイムスタンプが同じであれば、サーバーはブラウザーにコード 304 を返し、レスポンス・ファイルとローカル・ファイルが同じであることを通知します。

図 3. My developerWorks Blogs ホームのレスポンス・ヘッダー 2
My developerWorks Blogs ページからの詳細です。「Cache-Control no-cache, max-age=0」の行が赤枠で囲まれて強調されています。
My developerWorks Blogs ページからの詳細です。「Cache-Control no-cache, max-age=0」の行が赤枠で囲まれて強調されています。

上記に示されている Cache-Control 設定は、このレスポンスはキャッシュできないことを示しています。ビジネスの観点からは、このリクエストを使用して、キャッシュに入れるべきでないユーザー認証および権限付与を確認することができます。

図 4. My developerWorks Blogs ホームのレスポンス・ヘッダー 3
「Cache-Control public, max-age=86400」および「Last-Modified Sun, 15 Feb 2009 21:48:46 GMT」の 2 行が赤枠で囲まれて強調されています。
「Cache-Control public, max-age=86400」および「Last-Modified Sun, 15 Feb 2009 21:48:46 GMT」の 2 行が赤枠で囲まれて強調されています。

このレスポンス・ファイルは変更されることがほとんどない JavaScript ライブラリーなので、max-age は 1 日に設定されています。

Mashup Center

簡単に使用できるビジネス・マッシュアップ・ソリューションを提供するように設計された Mashup Center は、IT に必要なセキュリティーおよびガバナンス機能によって、動的な状況依存型アプリケーションのビジネスごとのアセンブリーをサポートします。この製品には、Lotus Mashups および InfoSphere MashupHub が統合されています。図 5 は、動作中の Lotus Mashups のスナップショットです。

図 5. Mashup ホーム・ページ
Lotus Mashups によるページの分析です。上部のデータ・ビューアーには公園に関する情報が一覧表示され、その下に 3 つのサンプル・グラフが並んでいます。
Lotus Mashups によるページの分析です。上部のデータ・ビューアーには公園に関する情報が一覧表示され、その下に 3 つのサンプル・グラフが並んでいます。

図 6 と図 7 に、HTTP ヘッダーを表示する選択をしたときの表示内容を示します。

図 6. Mashup ホームのレスポンス・ヘッダー 1
Mashup ホームのレスポンス・ヘッダー 1 からのフィードバックです。「Expires Wed, 14 Oct 2009 07:56:36 GMT」と「Cache-Control public, max-age=86400」が赤枠で囲まれています。
Mashup ホームのレスポンス・ヘッダー 1 からのフィードバックです。「Expires Wed, 14 Oct 2009 07:56:36 GMT」と「Cache-Control public, max-age=86400」が赤枠で囲まれています。

このリクエストが取得するテーマ情報は、サーバーからキャッシュすることができます。

図 7. Mashup ホームのレスポンス・ヘッダー 2
「Set-Cookie JSESSIONID=0000Fqxf-SY3wIX3UbLOD-Mv0_7:~1; Path=/」、「Expires Thu, 01 Dec 1994 16:00:00 GMT」、「Cache-Control no-cache=set-cookie, set-cookie2」の 3 行が赤枠で囲まれています。
「Set-Cookie JSESSIONID=0000Fqxf-SY3wIX3UbLOD-Mv0_7:~1; Path=/」、「Expires Thu, 01 Dec 1994 16:00:00 GMT」、「Cache-Control no-cache=set-cookie, set-cookie2」の 3 行が赤枠で囲まれています。

これは個人用のメイン・ページなので、キャッシュに入れるべきではありません。このページが常に最新の状態に更新されるように、Expires の値が遠い過去の日付に設定されている点に注意してください。

まとめ

複数のブラウザーが存在することから生じる複雑さから、適切なキャッシュ設定は非常に重要となってきます。この記事で説明したベスト・プラクティスは以下のとおりです。

  • できるだけ多くのファイルをキャッシュしてロード時間を短縮し、パフォーマンスを改善すること。
  • Cache-Control を使用して、可能な限りキャッシュの振る舞いを定義すること (特に IE の場合)。これによりブラウザー間での不一致が減るため、パフォーマンスを改善するには最も効果的な方法となります。
  • 「キャッシュ関連の設定を使用しない」という状態は避けること。
  • デフォルト設定で新しくページを開くと、IE ブラウザーはほとんど常に、サーバー・サイドにリクエストを送信してデータを取得します。
  • キャッシュに入れるべきでないページがある場合は、「Cache-Control: no-cache, no-store」を使用して、ページが確実にキャッシュされないようにすること。これは、データがセキュリティーまたは機密情報に関わる場合には特に重要なことです。
  • POST リクエストはキャッシュできないため、必要でない限り使用しないこと。

ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Web development
ArticleID=461847
ArticleTitle=Web 2.0 アプリケーションのパフォーマンスを改善する
publish-date=12082009