Share via

IIS7 以降の静的コンテンツの圧縮について

  • Article

こんにちは。
日本マイクロソフト、CSS デベロッパー ツールズ AppPlat の月尾です。

今回は、静的コンテンツの圧縮が行われる条件の一つとして、コンテンツへのアクセス頻度が関連していることについてお知らせいたします。

静的コンテンツの圧縮の設定について

静的コンテンツの圧縮を有効にするためには、以下の設定が必要となります。

1. Web サーバーの役割サービスから、[パフォーマンス] - [静的コンテンツの圧縮] を有効にします。

HTTP 圧縮 <httpCompression> - セットアップ
https://technet.microsoft.com/ja-jp/library/ee431600.aspx#ghi

2. IIS マネージャーで、サーバーを選択した状態で、機能ビューにある [圧縮] から以下の設定を行います。

   [静的なコンテンツの圧縮を有効にする] : チェックを入れます
   [次の値より大きいファイルのみ圧縮する (バイト)] : 圧縮を行いたいファイルの最小のサイズを設定します
   [キャッシュ ディレクトリ : 圧縮を行ったファイルの保存先のディレクトリを設定します

圧縮を構成する (IIS 7)
https://technet.microsoft.com/ja-jp/library/cc730629(v=ws.10).aspx

3. 圧縮を行う対象のコンテンツ タイプを追加します。

IIS 7.0 で HTTP 圧縮対象のコンテンツ タイプを追加する方法
https://support.microsoft.com/ja-jp/kb/969062

静的な種類 <staticTypes>
https://technet.microsoft.com/ja-jp/library/ee431653.aspx

静的コンテンツの圧縮の確認方法について

上記を設定した状態で実際に静的コンテンツにアクセスしてみます。この際、IE の F12 開発者ツールや、Fiddler 等のパケットキャプチャーツールを利用して、リクエスト ヘッダーに Accept-Encoding ヘッダーがあり、また、静的コンテンツの応答ヘッダーに Content-Encoding: gzip が含まれているかどうかを確認して、圧縮の有無を判断してみます。

以下は IE11 の F12 ツールのネットワークキャプチャを利用した例ですが、リクエストのヘッダーには Accept-Encoding:gzip, deflate, peerdist が指定されています。

 

しかしながら、応答ヘッダーには Content-Encoding: gzip が含まれていません。サーバーからレスポンスされたコンテンツは圧縮されていない状態です。

 

その要因としては、冒頭でお伝えしたコンテンツへのアクセス頻度が関係しています。

コンテンツへのアクセス頻度について

IIS では、すべての要求で圧縮コストが生じるのを避けるため、圧縮が行われるのは頻繁に要求されるコンテンツに限られます。

頻繁に要求されるコンテンツの定義は、<system.webServer> - <serverRuntime> セクションの frequentHitThreshold 要素と frequentHitTimePeriod 要素によって決定されます。具体的には、frequentHitTimePeriod 要素で指定される時間内に、IIS が受け取った同じ静的コンテンツに対するリクエスト数が frequentHitThreshold 要素のしきい値を超えると、IIS はファイルを圧縮し、しきい値を超えた時点以降のリクエストに対して圧縮されたコンテンツを返します。

サーバー ランタイム <serverRuntime>
https://technet.microsoft.com/ja-jp/library/ee431646.aspx
----------
frequentHitThreshold 要素
URL の要求回数を指定します。frequentHitTimePeriod 属性で指定した期間内にこの回数の要求が発生すると、頻繁にヒットしていると見なされます。
既定値は 2 です。

frequentHitTimePeriod 要素
この期間内に、frequentHitThreshold 属性で指定した回数分の URL 要求が発生すると、頻繁にヒットしていると見なされます。
既定値は 00:00:10 (10 秒) です。
----------

つまり、既定の設定の場合、10 秒間に 2 回同じ静的コンテンツに対するリクエストが届くことで、静的コンテンツが圧縮されて、応答が返ることになります。

そこで、クライアントのキャッシュによってサーバーに実際にリクエストされないことがある点に注意しながら、10 秒間に 2 回同じ静的コンテンツに対してリクエストを送ってみてください。成功すれば、以下のように Content-Encoding: gzip ヘッダーが返り、圧縮に成功していることが確認できます。また、今回の例では Content-Length の値からも、圧縮前の 11880 byte が 121 byte に圧縮されたことが分かります。

 

失敗した要求トレースでの確認方法について

今回のように圧縮が行われたのか、行われなかったのかは、IIS の失敗した要求トレースという機能を使うことで、その理由も含めて判断ができるようになっています。失敗した要求トレースの構成方法や、トレースの見方は以下の資料をご参照いただければと思います。

IIS 7 で失敗した要求トレースを構成する
https://technet.microsoft.com/ja-jp/library/cc731798(v=ws.10).aspx

インターネット Web サーバー構築ガイドライン - 第 9 章 ログやトレースを活用しよう
https://download.microsoft.com/download/8/F/3/8F3E42CB-5E5A-4BC5-8549-5F408389469F/InternetWebServerGuideline_chapter10_draft.pdf

例えば、1 回目のリクエストを行った際 (まだ圧縮が行われない場合)、リクエストのトレースを CompactView から確認しますと、静的なコンテンツの圧縮が成功しなかった (STATIC_COMPRESSION_NOT_SUCCESS) こと、また、その理由 (Reason) として頻繁にコンテンツがアクセスされていないこと (NOT_FREQUENT_HIT) が分かります。

10 秒間に 2 回のリクエストを行い、2 回目のリクエストのトレースを同様に CompactView から確認しますと、静的なコンテンツの圧縮が成功した (STATIC_COMPRESSION_SUCCESS) したことが確認できます。

 

上述の内容を満たしているにも関わらず、静的コンテンツの圧縮が失敗するような状況に遭遇した場合は、失敗した要求トレースを取得し、静的なコンテンツの圧縮が成功しなかった理由 (Reason) を確認することで、有効な情報が得られる可能性がありますので、ぜひご活用ください。

それでは、またの機会に。