携帯画像：ブラウザーキャッシュ容量問題：これまでの対策

ブラウザーキャッシュ問題は昔から携帯開発者を悩ませていた最大の問題です。ブラウザーキャッシュが10Kバイトのような時代には、テキストだけでも制限を越えてしまう場合もあり、１ページあたりの情報を少なくするしかありませんでした。しかし、今日の１００Kバイト以上の端末がほとんどを占めるようになると、まずテキストでは超えない制限となったので、画像をいくつ載せるか、どのクオリティにするか、という問題に置き換わってきています。ですから、このBlogでもブラウザーキャッシュ容量問題は画像の話題としています。

容量オーバーの問題はとにかく深刻です。右のようなダイアログが画面に



でてきてアプリケーションが完全に止まり、制御不能になります。このような事態に比べたらレイアウト崩れやデザインの貧弱さは、許せる範囲だと言えます。

ブラウザーキャッシュ容量問題の対策が難しい点を挙げます。

1. 2G端末で６K～30K、3Gで48K～500Kと幅が広い
2. 動的コンテンツでは、どの画像が出力されるのか定義できない
3. １ページには複数の画像があるので、画像変換システムでは１つの画像のサイズだけを調整しても不完全である
4. HTMLと他の複数の画像は別HTTPであり、別サーバで処理されることを想定しなくてはならない

このように、あまりに変数が多い上に計算できる固定的なサーバも定義できないので、対応しにくいわけです。そこで、何かを固定することで対応することになります。よくあるのが...

1. 対応端末は3G（auはWIN以降...100K以上）とする
2. １つのページに大きな画像は2つまで
3. 1ページを（安全の為）50K以内に設計する
4. 大きな画像は１つ15K以内で作成する
5. テキストは20K以内とする
6. VGA端末については、別の画像を用意し、1画像の制限を50K以内とする

このような開発ガイドに従って、アプリケーションと画像を生成しますが、開発時はともかく運用時に、大量の商品画像をこの規約に沿って用意することはコストも増大し、ミスも起きやすいものです。

一般の変換ソリューションはこの問題に対して無力なので、ページ分割のような機能を考えがちですが、ページ分割機能は非常に問題が多い機能なので、問題がかえって悪化してしまいます。この理由は、別に書きます。

そしてVGA画面の登場によって、この問題に対する従来のアプローチの限界が見えてきました。それは先ほどの例として挙げたガイド６．に見られます。これまでは概ねQVGA/100Kという枠をはみ出さなければ良かったですし、実際QVGAでコンテンツを作れば100Kまで位が丁度よく、ユーザビリティから100K以上のコンテンツを作る必要性もあまりありませんでした。キャリアの想定した仕様は非常によいバランスを保っていたと思います。

ところが、VGA/300KとかVGA/500KというスペックはQVGA/100kに比べてあまりに差が大きいために、画像変換を行っても結果を想定することができず、個別に制作して切り替えざるを得なくなっています。もちろん、QVGAをVGAに引き伸ばしても判別不能の画像になるだけです。

今後はVGA時代とは誰もが考えるけど、現在主流のQVGAと共存させるのは難しい（コストアップ）、というジレンマがあります。そこでドコモではディスプレイモード切り替えるmetaタグを用意しています。しかもデフォルトはqvgaです。

<meta name="disparea" content="vga">
<meta name="disparea" content="qvga">

ラウンドアバウトは、このややこしくてどうしようもない問題を綺麗に解決します。もちろんコンテンツはVGAで作ることが可能で、作るべきだと考えています。