オフラインでも使えるwebサイトを作るために

現在取りかかっているプロジェクトと関連しますので、ローカル（オフライン）でも使えるWebサイトを作るためのポイントをまとめてみました。

データをため込むにはHTML5のアプリケーションキャッシュとストレージを使う

ローカルで使えるWebサイトを作るには、データをローカルに保管することが必須です。HTML5では保管方法がいくつか用意されていて、大別するとアプリケーションキャッシュとストレージになります。

静的なファイルはアプリケーションキャッシュで

完全にローカルで使えるWebサイトを作るためには、HTML5のアプリケーションキャッシュを使う必要があります。最初に問い合わせるURLはこのアプリケーションキャッシュに入れます。これをやらないと、URLを入力した時点でブラウザはサーバに問い合わせをし、ネットワークが繋がらなければエラーになります。

アプリケーションキャッシュは便利ですが、例えば1ページでも更新されるとキャッシュ全体をクリアしなければならないなど、頻繁に更新される内容には不向きです。あくまでも静的なファイルに使用します。

ただし、Webサイトのトップページはしばしば動的なページです。更新情報やお知らせなどを掲載することが一般的です。そうなると最初に問い合わせるURLは静的ではなくなります。

この問題を解決するためには、最初に問い合わせるURLではウェブページのフレームワークだけを返し、更新情報などはストレージから読み込むんで、Javascriptで埋め込むことになります。

HTML5 History APIは使わない

Javascriptを使ってページ内容を更新する場合、backボタンやブックマークを正常に動作させるためにURLを書き換える必要があります。その方法はURLのハッシュフラグメントを書き換える方法と、HTML5のHistory API (pushStateなど)を使う方法があります。

pushStateを使うとハッシュフラグメントではなく、URLの本体を変更します。この方が従来のWebと親和性が高いという理由などから、現在ではHistory APIを使った方法が推奨されています。

しかしこれはローカルWebアプリには使えません。最大の理由はアプリケーションキャッシュがうまく使えないからです。

例えばhttp://my_server.com/をアプリケーションキャッシュに保管しいても、http://my_server.com/path_to_page_1, http://my_server.com/path_to_page_2というURLにアクセスしようとするとアプリケーションキャッシュのページは使われません。通常通り、http://my_server.com/path_to_page_1, http://my_server.com/path_to_page_2をサーバに要求します。

それに対してhttp://my_server.com/#!path_to_page_1, http://my_server.com/#!path_to_page_2のようなURLになっていれば、まず最初にアプリケーションキャッシュのhttp://my_server.com/が呼び出されます。そのあとpath_to_page_1やpath_to_page_2のコンテンツはストレージから読み込むか、あるいはAJAXでサーバに問い合わせることができます。

その他、Androida 4.0のデフォルトブラウザがHistory APIをしっかりサポートしていないという問題もあります。

ストレージの選択

ストレージはいくつもAPIが用意されていますが、ブラウザのサポートを考慮すると実際に使えるものは限られています。

一番広くサポートされているのはwebStorageです。これは非常に単純なkey/value型のストレージです。IE8でさえサポートされています。しかしwebStorageの大きな問題は容量の少なさです。Safariだと5Mbyteが上限です。これでは日本分子生物学会の抄録などは収まりません。経験的に数百演題の学会であればwebStorageでも十分ですが、1000を超えたらwebStorageでは不十分です。

次にサポートされているのはWeb SQL Databaseです。50M byte以上のデータをため込むこともできます。またSQLでクエリが書けるので、いろいろな使い方ができます。ただしWeb SQLは今後は規格を更新しないことが決まっています。Web SQLの大きなポイントは、FirefoxやIEなどのデスクトップ用ブラウザではサポートされていないものの、スマートフォンのブラウザで広くサポートされている点です。

最も期待されるのはWeb SQLに変わるIndexed DBですが、こっちはまだサポートするブラウザが少なく、特にスマートフォン用ブラウザではサポートされていません。

上記を考えると、ストレージとしては第1にWeb SQL Databaseを優先させ、サポートしたいブラウザや保管したいデータ量を考慮してIndexedDBもしくはwebStorageをサポートするのが妥当な選択だと言えます。

まとめ

完全にローカルなWebサイトを作るために必要なコンポーネント、どのHTML5テクノロジーを使うかの話をしました。特に重要なのは、一般的に推奨されている History APIは使えないということだと思います。

もちろんコンポーネントを選定しただけではまだまだ話は始まったばかりです。解決しなければならない問題はたくさんあります。これについてはこれから少しずつ紹介していきます。

解決しなければならない問題のリスト

1. ハッシュフラグメントのフォーマット
2. out-of-dateになったページをどうやって更新するか
3. データの同期をどうやって行うか