ZiproxyでモバイルデバイスにおけるWebページの読み込みを高速化する：Leverage OSS（2/2 ページ）

[Ben Martin，SourceForge.JP Magazine]

　ziproxy.confファイル内のオプションの多くは、再圧縮の対象とする画像フォーマットやその圧縮先フォーマット、圧縮レベルに関するパラメータを指定するものだ。冒頭で述べたように、最小限のシステムRAMと比較的低速なCPUしか持たないデバイス（インターネット端末など）が対象になる場合は、画像をJPEG 2000形式に圧縮する必要はないだろう。一方、よりCPUパワーの高いノートPCから低速なリンク経由でこのWebプロキシにアクセスする場合は、すべての画像をJPEG 2000形式に圧縮し直してもよい。

　画像圧縮レベルの設定は、画像の大きさ（ピクセル数）ごとに変えることができる。Webページでは、大きな画像ほど高画質で表示させたいものだ。また、レベルを負の値で指定すると、画像はグレースケールに変換された上で指定の画質で圧縮される。画質の指定には4つの値を使い、それぞれは5000ピクセル以下、5001〜50000ピクセル、50001〜250000ピクセル、250001ピクセル以上の画像に対する画質レベルを表す（例：「ImageQuality={17,20,23,25}」）。ただし、JPEG 2000への圧縮を行う場合は「ImageQuality」の代わりに「JP2ImageQuality」というキーワードを用いる。

　デフォルトでは、Ziproxyによる再圧縮の対象がPNG、JPEG、GIF画像になっている。これら各画像の再圧縮を無効にするには、「ProcessJPG」（JPEG画像の場合）のようなブール型オプションを使う。可能であれば通常のJPEGではなくJPEG 2000への再圧縮を行うには「ProcessToJP2=true」とする。逆に、JPEG 2000画像を通常のJPEGに再圧縮するには「ForceOutputNoJP2=true」とする。JPEG 2000画像の圧縮方法に関するオプションはほかにもあるが、詳細についてはサンプルのziproxy.confファイルを参照してほしい。

　テキスト圧縮のオン／オフは「Gzip=true/false」で指定する（デフォルト値はtrue）。クライアントがgzip圧縮されたコンテンツを扱えない場合や、SSHのプロキシにアクセスしてSSH圧縮を利用する場合は、オフにするとよい。「Compressible={"shockwave","foo"}」オプションを使えば、Ziproxyにほかのデータタイプを圧縮させることも可能だ。

　また「Process」というプレフィックスで始まるオプション群では、HTML、CSS、JavaScriptの各ファイルに途中で手を加えるかどうかを指定できる。これらのオプションによって各コンテンツは幾らか縮小されるが、表示内容が実際のコンテンツとは異なることを示すマーキングが行われる。

　MaxSizeオプションを使えば、Ziproxyで（再）圧縮を行うファイルの上限サイズ（バイト数）を指定できる。

　ImageQualityにすべて負の値を指定して、Ziproxyにすべての画像をグレースケール変換させれば、Webページのどの画像がZiproxyで処理されたかがひと目で分かる。Ziproxyの最初の動作確認をlinux.comとslashdot.orgのページで行い、ログファイルを調べたところ、画像があまり圧縮されていないようだったので、この方法を試すと、グレースケール表示になっていたのはFlash形式でない広告だけだった。同じ設定でarstechnica.comのようなほかのサイトを開くと、ページ上のほとんどの画像がグレースケールになり、ZiproxyからWebブラウザへの転送バイト数が大幅に削減された。

　「Project Gutenberg」サイトの閲覧時には、転送されるCSSファイルの多くが元のサイズの25％に圧縮されていた。いずれも元ファイルは5〜20Kバイトほどだが、接続速度が遅い場合には転送量の削減が大きく効いてくる。同サイトのホームページにあるモバイル機器用リーダの30Kバイトのイメージも5Kバイトに圧縮された。『Dead Souls』（邦題：死せる魂）のテキストなど、もっと大きなHTMLファイルのダウンロードでは、Ziproxyを使うことで転送サイズを60％ほど削減できた。書籍検索結果のページも、Ziproxyを経由することで8Kバイトから3Kバイトに抑えられた。Gutenbergサイトにおける最後のテストとして、『The Gambler』（ドストエフスキー著、邦題：賭博者）の343Kバイトの非圧縮バージョンをダウンロードしたところ、ZiproxyからWebブラウザへの転送サイズは89Kバイトとなった。これに対し、同じサイトにあるzip圧縮バージョンのサイズは126Kバイトだった。もちろん、非圧縮バージョンをダウンロードする場合はZiproxyとGutenbergサイトの間の転送サイズが大きくなるが、それでもZiproxyとクライアント側Webブラウザの間の転送バイト数は確実に減る。

　flickr.comのように画像の多いサイトでは、再圧縮によってもっと大きな効果が得られる。JPEGの圧縮レベルを-20ないし-15とすれば、多くの画像が元のサイズの10分の1未満になる。もちろん、こうした極端な圧縮を行うとJPEG圧縮画像はグレースケール表示になる。

さらなるチューニング

　ローカルホスト以外からは接続できないように設定してZiproxyを使うという手もある。この場合、クライアントはSSHポート転送を使ってZiproxyにアクセスし、クライアントマシン側のポートをZiproxyの実行マシンに接続することになる。SSHには通信を圧縮する「-C」オプションがあるが、SSHによる圧縮をオフにしてZiproxyを使った方が圧縮効率は向上する（特に画像ファイルの場合）。汎用の圧縮（「ssh -C」の場合はgzipが使われる）は、画像用のJPEG圧縮にはかなわない。

　Webサイトの閲覧では、広告やセーフブラウジングのチェックがバイト転送の最大のネックになり得る。とはいえ、Adblock Plusのようなソフトウェアで広告を除去している場合でも、Ziproxyを使えばクライアントへのバイト転送量をかなり減らせる。ZiproxyによるCSSおよびHTMLコンテンツの圧縮効果は、クライアント側がサポートしている暗黙的な圧縮がすでにそのWebサイトで利用されているかどうかで変わってくる。gzip圧縮はHTMLおよびCSSデータをエンドユーザーに分からない形で圧縮してくれるが、少しでもバイト数を減らすためには、設定オプションを使って画像の圧縮方法をチューニングするとよい。

Ben Martinは10年以上前からファイルシステムに携わっている。博士号を持ち、現在はlibferris、各種ファイルシステム、検索ソリューションを中心としたコンサルティング業務に従事。

あなたのシステムをさらに高度なものするアイデアが詰まった「Leverage OSS」コーナーにどうぞ

原文へのリンク