読者の皆様は、「Extensible Web」というキーワードについてご存知でしょうか。

Extensible Webは、現在のWebが抱える大きな問題点を解決しようとする考え方であり、ムーブメントです。 その問題点とは、誤解を恐れず言うなら、「HTML5の流れで生み出された様々なAPIが実際にはあまり使われておらず、役に立っていない」という点に尽きると思います。

Extensible Webはそうした問題を解決するために、「開発者によって拡張可能なWebを目指そう」と呼びかけます。そのために必要なのは、特定のユースケースを想定した粒度の粗いAPIではなく、粒度が細かく、より基本的な機能を提供する低レベルなAPIを提供することで、開発者が様々なライブラリを作りやすくすることです。詳しくはこちらの記事も参考にしてください。

Extensible Webは、「Extensible Web Manifesto」というマニフェストが公開されてから広く世に知られるようになりました。Extensible Web Manifestoの文書がGitHub上で公開されたのが2013年6月9日ですので、既に2年以上が経過していることになります。本対談では、Extensible Webが誕生してから2年で何が変わったのか、そしてこれからWebはどうなっていくのかを、有識者の方々にそれぞれの立場から語っていただこうという発想で企画しました。

標準化団体のスタッフがどんな目線でWebを見ているのか、ブラウザベンダが開発者に求めているものは何か、Web標準にも詳しいエキスパートが現在のWebをどう捉えているかなど、普段聞けない話がいっぱいです！前後編でお届けしますので、どうかお楽しみくださいませ。

ちなみに、前編は全体的に、HTML5や関連（あまり知られていないかもしれない）APIを広範にdisる批評するという流れになってしまったので、ちょっとマニアックかもしれません…あしからず。

自己紹介

白石 皆さん、本日はお集まりいただき、ありがとうございます。非常に豪華なメンバーにお集まりいただき、誠に光栄です。今日は脱線大歓迎というノリで、自由闊達にExtensible Web、そしてWeb全体について語っていただきたいと思います。ではまずは、自己紹介からお願いできますでしょうか。

小松 小松と申します。通信会社（NTTコミュニケーションズ）でWebに関する研究開発をしておりまして、最近ではWebRTCやIoT/WoTに関する開発、標準化活動をやっています。

浅井 Mozilla Japanの浅井です。最近はエヴァンジェリストとしてWeb技術に関して開発者の皆さんの前でお話したり、モバイル＆エコシステムマネージャーとして、パートナーさんとの協業を促進しています。Fx0というスマートフォンの開発や、FirefoxOSを搭載したビエラの開発をお手伝いしたりなど、パートナーさんと「Webを使ったものづくり」を広げていく仕事をしています。

白石 ビエラって、FirefoxOS積んでるんですか。知らなかった…。

斉藤 株式会社リッチメディアで、主にメディア事業に携わりながら、対外的にはUXエンジニアとして活動しています。ここにいる皆さんは、標準化に近いところで働いていらっしゃる方が多いと思いますが、僕は一番現場に近いところで実装寄りの仕事をしているんじゃないかな。

ダニエル W3Cのダニエル・デイビスと申します。半分はTV・ビデオ関係の仕事を、もう半分はマーケティングやコミュニケーション、特に開発者向けに標準をどう伝えていくかといったことを担当しています。特に最近注目しているのはセキュリティです。今セキュリティに関する仕様書がたくさん増えているので、そうした情報を開発者に伝えるにはどうしたらいいかを考えています。

Extensible Web以前 – Application Cacheの失敗

白石 では、Extensible Webが出てもう2年が過ぎたわけですが、そもそもExtensible Web以前は何が問題だったのでしょうか？例えば、標準化の失敗例としては Application Cache (※) がよく引き合いに出されますね。AppCacheの何がいけなかったのでしょう？

小松 使えるシーンが限られていたのが一番の問題じゃないかと思います。数ページ程度の静的なWebサイトならいいんだけど、ページ数が増えたり、ちょっと複雑になるととたんに使えなくなっちゃう。あと、キャッシュのバージョン管理が面倒臭かったですね。

斉藤 アプリケーションキャッシュのファイルのバージョンを書き換えるGruntタスク、なんてのもあったりしますが、「勘弁してくれよ」って感じですね(笑) キャッシュが更新されるタイミングもブラウザによってまちまちですし。

白石 実務だと、キャッシュの最大容量とかもよく問題になりましたね。巨大な動画ファイルとかはキャッシュされなかったり、キャッシュの最大容量を知ろうと思っても知る手段すらない、とか。

ダニエル 「オフラインの場合はキャッシュを、オンラインの場合はWeb上にある最新のリソースを使う」といったユースケースにも対応できていませんでしたね。

斉藤 仕様としても、結構珍しいかなと思いますね。長くWeb屋をやっていますが、1ファイル（マニフェストファイル）だけ用意すれば、あとはブラウザがうまくやってくれる…という仕様は他に見たことがありません。

JavaScriptのAPIは、だいたいにおいてPolyfill (※)を用意できるように作られていて、レガシーなブラウザの上でも動作をエミュレートできるようにしてあるものが多い。でもアプリケーションキャッシュの場合は、使うか使わないかの「ゼロイチ」を要求される。APIではなく、いきなりプラットフォームを作りにいったという感じがありますね。

白石 僕、Google Gears（※）っていう技術の本を書いたことがあって、そういうのだけよく知ってるんですが、Gearsの仕様を参考に作られたからこんなことになったんだと思ってます…どうでもいい話ですが。。

※ Application Cache…Webサイトをオフラインでも利用できるようにする仕組み。マニフェストファイルというファイルを一枚用意するだけで、キャッシュの管理はすべてブラウザが行ってくれるというのがウリの一つ。

※ Google Gears…Googleが昔開発していた、オフラインWebアプリを実現するブラウザプラグイン技術。Application CacheやWebSQL Database、Web Workersなど、HTML5関連APIの仕様策定に参照され、HTML5がメジャーになると開発が終了された。

Webはアプリケーションプラットフォームになった

白石 他に、問題だったAPIとかありますか？

小松 よく言われるのは contentEditable (※)ですね。

浅井 ああ…死んでましたね。実装する側が(笑) 。「誰だ、こんな、実際には誰も使わないAPI作ったの」って開発者が文句言ってました(笑)。

白石 確かそれって、IEかなんかで実装されていたのを仕様に起こしたって感じじゃありませんでしたっけ。

浅井 そうかもしれませんね。「Webはみんなで作るもの」ってなる前の時代に作られた仕様という気がします。

斉藤 ちょっと全般的な話になってしまうのですが、かつて単なる「ドキュメントレンダラー」だったWebブラウザが、HTML5のブームの中で、アプリケーションのランタイムへと変化していったという流れがあると思うんですよね。

白石 かつてはHTML5の仕様書の先頭の方にも、「アプリケーションプラットフォームを目指します」と書いてありましたしね。

ダニエル それは今も変わっていませんね。W3CとしてはWebのことをオープン・ウェブ・プラットフォームと呼び表しつつ、プラットフォームがあまりに広くなりすぎているので、Application Foundation（アプリケーション基盤）として8つのカテゴリに集中するという動きをしています。

浅井 ブラウザベンダ側からすると、JavaScriptを生み出した時点で「僕らはアプリケーションプラットフォームです」と言い続けていたんですよ。機能不足で、そうは見えなかったんでしょうが…ただ、それを目指していたというのはNetscapeの時代からありました（若い人向けの注: Netscape NavigatorというブラウザがFirefoxの前身）。

NetscapeがJavaScriptを動的な、拡張可能な言語として設計した時点から、Webはずっと拡張可能なプラットフォームです。なので、Extensible Webというキーワードには、（Webは拡張可能であるという）ブラウザベンダの思いを、Web開発者に伝わりやすいように言い直したという一面があるんじゃないかな、と思っています。

※ contentEditable…任意の要素を、ユーザが編集可能な領域にすることのできる属性。<div contentEditable>とするだけで、簡単なWYSIWYGエディタを作成可能

disってない。disってないですよ

白石 イマイチという評価のAPIとしては、他にもそういえばWeb Storage（※）もありますね。同期型のAPIなので、ループの中とかで使っちゃうとUIスレッドがビジーになっちゃって、UIがもたついちゃったりフリーズしちゃったり、という。

小松 僕は割と好きなんですけどね。

斉藤 ハードに使っちゃダメなんですよ。ちょっとした優しさのために使うべき(笑) 。例えばフォームの入力内容を入れておいて、ネットワークが切れた時でも失われないようにするとか、その程度。

ダニエル 問題のあるAPIというと、<input type="date">とかもそう。昔私はOperaにいたんですが、そこらへん（inputの様々なtype）をいち早く実装したのが自慢でした。でも開発者からのフィードバックとしては褒められるどころか、「（<input type="date">使った時に）自動的に表示されるカレンダーのデザイン変えさせろ」でした(笑)。

斉藤 Operaかわいそう(笑)。

浅井 HTML5の発端（の一つ）だったのにね(笑) 。※

斉藤 僕は結局使ったことないですね(笑) 。デザインが合わないと、結局使いものにならないので。フォーム関係の仕様で言えば、required属性とか、<input type="email">とか<input type="number">とかはすごく助かりますよね。

小松 モバイルで、タイプに合わせた最適なキーボードが出てきてくれるのが嬉しいですよね。

白石 ほかには、存在はするけどあんまり使われてない、ってAPIも多そうですよね。例えばWeb Workers（※）とか。Shared Worker（※)なんてのもあったなあ…。

浅井 いや、（Mozillaは）使ってますよ！

白石 いやまあ、一般のWeb技術者が使っているかというと、あんまり…という気がしますよね。他には…えーと…名前が出てこない。EventSourceとかいうAPI使うやつ。

小松 Server Sent Events（※）だ。

一同: ああーー

小松 テキストしか扱えないし、サーバプッシュの用途だったら、他にWebSocketがあるから。HTTPサーバで事足りるっていうのはいいんですけどね。

ダニエル WebSocketを使えないホスティングサービスの上で、「しょうがないから」Server Sent Events使ったということはありましたね(笑)。

白石 まあ、こういう風に、「あるけど使われてない」とか「あるけどイケてない」という仕様がいっぱいあって。

ダニエル 他にももう一つ思い出しました。Network Service Discovery API（※）。W3Cスタッフとして言っていいかどうかわからないけど、あれはセキュリティの問題もあって、ちょっと残念な感じでした(笑)。

白石 でもこの対談、HTML5のAPIをdisる流れになってて、こんなの初めてで面白いなあ(笑)。

浅井 disるように誘導してません？(笑)。

白石 いや、そんなつもりは…(汗) 。

※ Web Storage…シンプルなローカルストレージAPI。localStorage.setItem('key', 'value')とするだけで、ローカルのストレージに値を保存できる。

※ Network Service Discovery API…ネットワーク上のサービスを動的に発見するためのAPI。ホームネットワーク上で、デバイスを発見する用途に利用できるとされていた。

プレフィックスの反省を活かす

白石 あと、Extensible Webの情報漁ってた時に「Indexed Database API（※）は、開発者のフィードバックを受けながら作った素晴らしいAPI」と書いてあったんですが、正直同意できない(笑) 。かなり使いにくいAPIだと思うんだけど…。

浅井 えーと、いや、それは、申し訳ない。だいぶうちら（Mozilla）が推進しちゃって(笑)。

小松 一番最初に実装してなかったけ？

浅井 してました(笑)。 （それ以前に提案されていた）WebSQL Database（※）なんて、標準化されていないSQLiteの仕様に依存してて全然ダメだ、と。

白石 いや、その主張は同意できたんですけど、できあがってみたIndexed Database APIの仕様がこれかーー、と(笑)。

浅井 いやでもまあ、Extensibleではあるじゃないですか。プリミティブで、パフォーマンスも上げられるAPIは一応揃っていて。APIの使い勝手については、申し訳ない、ライブラリ使ってくださいと。MDN (Mozilla Developer Network) に掲載されているIndexed Database APIの解説でも、「localForageかdexie.jsを使ってください。そっちのほうが『More user friendlyだから』と」と書いてあります(笑)。

ダニエル 素で使うのが厳しいという意味では、WebGL（※）とかもそうですよね。ラッパーライブラリがないとコーディングは厳しいけど、プリミティブでパフォーマンスの高いAPIを提供している。

浅井 そういう点から言うと、Extensible Webの考え方があと数年早かったら、Web Audio API（※）じゃなくて、Mozillaが作っていたAudio Data APIだったんじゃないかな、と思いますね。プリミティブなAPIを提供して、ライブラリはJavaScriptで作ればいいじゃん、と、そういう発想で作られていたAPIだったんです。

小松 さっき話に上がってたWebSQL Databaseは、実はまだ結構使われてたりする。

浅井 ああ、結構ありますね。たまにユーザから「動きません」ってフィードバックもらって、見てみるとWebSQL Databaseのせいだったりする。WebKitがWebSQLを実装したあたりで、急にみんなが新しいWebの機能を使い出して、そのままになってるサイトが多いんですよね。

白石 それは、-webkit-プレフィックスに依存したサイトが未だに大量にある、って問題とも繋がってますよね。

浅井 そうなんですよ… プレフィックス付けてる間に開発者からの意見を取り入れていこう、というシナリオをブラウザベンダは考えていたのですが、開発者たちは便利なものがあれば使ってしまう。我々（ブラウザベンダ）が考えていたようには、うまくいきませんでした。かと言って、ブラウザベンダ自らがライブラリを作って提案したりしても、使われるのは最初だけで、すぐ使われなくなったりしてしまう。だから、ライブラリを作りやすくして開発者の意見を取り込みやすくしていこうというのがExtensible Webの目標の一つです。プレフィックスの失敗も、反省の一つだと思うんですよね。

※ Indexed Database API…ブラウザ上で利用できるキー・バリュー・ストレージ。Web Storageに比べると複雑だが高機能。

Extensible Webの起源はjQueryにあり？

小松 あと、Extensible Web以前という話で言うと、4年前にサンタクララで行われたTPAC（※）のブレークアウトセッションの中で、「開発者とW3Cがうまく関わっていくにはどうしたらいいか」という議論をしたのを覚えています。そこで、開発者が中心になってWebを伸ばしていくという話で、jQueryの例が取り上げられていました。

で、（DOM操作に）セレクタを使用するというのがWeb開発者に受け入れられるというのが判明したので、パフォーマンスの問題を解決するために、ネイティブでquerySelector API（※）が実装されたと。ここではフィードバックループがうまく働いたので、こういう例をどんどん増やしていこうという話がありまして、こういう流れがExtensible Webに繋がったのかなあ、と思います。

ダニエル jQueryの話が出たところで、一ついいですか？Extensible Webとは全然関係ないんだけど。

白石 なんですか？

ダニエル …小松さん、John Resig（※）に似てない？

斉藤 ああー、ググって出てきた写真で見ると、ちょうど黄色のやつに似てる。黄色いJohn Resig。

一同: (爆笑)

ダニエル すいません、脱線しまして…。

白石 いえいえ、最初にお伝えしたように、脱線大歓迎です。この、「黄色いJohn Resig」の話も、記事に含めさせていただきます(笑)。

ではここらで一旦まとめますと、まずjQueryをきっかけとしてquerySelector APIが出てきたといった流れがあり、これは実際に役立つAPIとして世界中で利用されているし、jQuery、もしくは類似ライブラリのパフォーマンス向上にも一役買っている。

一方で、Webプラットフォームには今やたくさんAPIがあるけど、使われていないものや、イケてないものもたくさんあると。こうした問題を解決する一つの糸口として、querySelector APIが生み出された経緯をヒントにしつつ、現在のExtensible Webというムーブメントに繋がっている…という流れでしょうか。

（以後、後編に続く）

※ TPAC…W3Cが主催する、Web標準技術に関するカンファレンス。

※ John Resig…jQueryを作った人。

ここでは、「オフラインファースト」をはじめとする、モバイルなどの回線が不安定な状況を想定したWebアプリケーション設計に関して、キャッシュ方法やよく使われるAPIなどを紹介したいと思います。

「オフラインファースト」とは2012年ごろから提唱されていた、「回線がオフラインになることを前提にアプリケーションの設計を行う思想」のことで、オフライン前提に設計することにより回線状況によらないサービス提供や、効率的な通信をベースにした高速な動作を目指すものです。

それではここからはキャッシュ方法とそれぞれ向いているコンテンツの紹介を行います。

読み込みデータのキャッシュ

ApplicationCacheやlocalStorage、オンメモリキャッシュなどを使って、「サーバから取得したデータをローカルに保持する」ものです。

これは一般に「クライアントサイドキャッシュ」と呼ばれるもので、ネットワークがオンラインの時に読み込んだデータをオフライン時に使用します。

サーバと連動しないコンテンツに向いており、実際のコンテンツ以外でもテンプレートファイルなどの「動的なコンテンツの静的な部分」にも使用されます。

読み込みデータのマージ

これは「読み込みデータのキャッシュ」と大きくは変わりませんが、「読み込みデータのキャッシュ」がオンラインになった際に毎回キャッシュを読みなおすのに比べて、「読み込みデータのマージ」はオンラインになった際にサーバ上で更新があった内容のみダウンロードを行います。

更新があった内容のみダウンロードを行うため、帯域の使用量が少なくなる利点がありますが、サーバとクライアントでデータの更新タイミングを管理する必要があるため、「読み込みキャッシュ」に比べて実装が複雑になります。

「多数の画像ファイルの内、更新があったもののみを再取得する」など、やりとりするデータ量が多いコンテンツに使用されます。

書き込みデータのキャッシュ

書き込み時に回線状況を確認して、オフラインの場合オンラインになるまでデータの送信を遅延させる方法です。

また、オフラインだった時だけではなく、サーバへの通信に失敗した場合、常にデータを再送する形で実装されることもあります。

実装方法としては独自に定義した通信用のコードを使用するほかに、XMLHttpRequestを乗っ取る方法や、使用しているライブラリ（jQuery）などのajaxメソッドをラッピングする方法などがあります。

「投稿」や「保存」などのサーバへの更新処理に使われますが、ゲーム等のタイミングが重要な通信や、「購入」等のサーバ側との連動が、重要な通信では使用されません。

書き込みデータのマージ

これは「読み込みデータのマージ」に書き込みが行われることを想定されたものですが、「書き込みの時系列を保持するか」、「同じデータを同時に編集していた場合にどう整合性を保つか」等によって実装難易度は大きく変わります。
（時系列を保持せず、同時編集時は常に最後の修正が反映されれば良い場合、書き込みデータのキャッシュ実装と大きな差はありません）

これに関してはサーバ側の実装も大きく関わってくるためクライアント側だけで設計するのは難しいですが、もしクライアント側だけで実装したい場合にはGoogle Drive Realtime APIなどの外部サービスの使用も検討してみてください。

オフライン動作

これは単純なデータのキャッシュではなく「ブラウザがオフラインの状態でも動作させる」方法になります。

現状、ブラウザ上でオフライン時にコンテンツを提供するには、基本的にApplicationCacheを使用します。

サーバ側の処理が重要な場合オフライン動作の必要性は高くありませんが、クライアントサイドで完結する要素が多いモバイル向けのツールやアプリケーションなどでは必要性が高くなります。

ここからは実際にキャッシュを実装する際によく使用される機能について紹介します。

Web Storage（localStorage、sessionStorage）

IE8以降の主要なブラウザで使用できる同期型の保存領域です。

多くのブラウザは5MB程度のデータを保持することが可能です。

実装も容易なためよく使われますが、同期型で実装されているためパフォーマンス的な問題も指摘されています。

ローカルストレージに簡単な解決策はない | Mozilla Developer Street (modest)では具体的な問題点や代替案が書かれています。

Cookie

古くから実装されており、サポートブラウザも広いことから、長い間クライアントキャッシュの保存領域としても使用されてきました。

ただ、Cookieに保存した内容はサーバへも送信されてしまうことから、Cookieをキャッシュとして使用する場合、以後の通信すべてで不要なデータをサーバに送ることになるため、大きなデータをキャッシュすることには向いていません。

location.hash

URLの # 以降に文字列を設定し、クライアントキャッシュとして使用する方法です。

サーバサイドへも送信されず、古いブラウザでも動作可能ですが、「ブラウザの履歴に残る」、「URLを共有した際にキャッシュも共有される」、「ブックマーク等にキャッシュも保存される」、「#を使った画面遷移時にキャッシュが破棄される」といった問題があるため、キャッシュとして使用する場合は注意が必要です。

ブラウザキャッシュ

JavaScriptから直接操作するAPIは提供されていませんが、ブラウザキャッシュもクライアントサイドでは重要なキャッシュになります。

具体的には「非表示のimg要素を作成し、img.srcへ画像のURLを設定して先読みさせる」、「見えないiframeで次に読み込むページを先読みする」といった方法で使用されます。

Web SQL Database

ブラウザ内に内蔵されたSQLiteに対して、JavaScriptからAPI経由でSQLを発行することでデータの保存、取得を行うのがWeb SQL Database APIです。

もともとWebKit系のブラウザで実装されており、W3Cでも標準仕様として提案されていましたが、SQLiteへの依存などの問題によりW3C上では廃案になりました。
（ブラウザ上のデータベースに関して – JavaScriptで遊ぶよ – g:javascriptでは廃案になった経緯等がまとめられています）

ただ、モバイル環境では使える環境が多いため、モバイル環境に限ったウェブアプリケーションなどでは使用されることもあります。

Indexed Database（Indexed DB）

標準仕様としての策定が中止されたWeb SQL Databaseに代わり登場したクライアントサイドDBです。

Web SQL DatabaseがあくまでもSQLiteの仕様に準拠しているのに比べて、Indexed DatabaseはJavaScriptからの使用に特化しておりシンプルなObjectやFile objectなどをそのまま格納できます。

Chrome、Firefox、IE10でサポートされるなど、デスクトップブラウザではサポートが広まっていますが、Mobile Safari、Android標準ブラウザでのサポートが行われていないためモバイル環境での使用は広まっていません。

Filesystem API

ブラウザ上にディレクトリなどのFilesystemを操作するAPIを提供するのが、Filesystem APIです。

DOMFileSystem objectやDirectoryEntry objectなどを使って、File objectを階層構造で管理することができます。

このAPIはinput[type=”file”]やD&Dで渡されたファイルを処理する際に使用する「File API」とは違うAPIであることに注意してください。
（Filesystem APIでも単一のファイルを操作する際はFile APIで提供される機能を使用しますが、File APIはあくまでもFilesystem APIから独立した仕様です）

主にChromeで実装されていますが、Chrome以外のブラウザでは実装が進んでいないため、一般的なウェブ環境ではあまり使用されていません。

Firefox に FileSystem API が無いのはなぜか？ | Mozilla Developer Street (modest)ではMozillaのFileSystem APIに対するスタンスが書かれています。

ApplicationCache

ApplicationCacheはcache manifestと呼ばれるキャッシュ対象のURLを記述したテキストファイルをhtmlから参照することで、記述されているURLの内容をローカルキャッシュとして使用する仕様です。

ApplicationCacheには以下の様な機能が含まれます。

• ブラウザがオフラインでも、事前にキャッシュした内容を表示する
• ネットワーク通信なしに、cache manifestに書かれたURLのファイルにアクセスする
• ブラウザがオフライン時のみ、代替内容を表示する
• JavaScriptからキャッシュの取得、更新イベントを受け取る

現在、ブラウザがオフライン時でもコンテンツを提供する場合ApplicationCacheが主に使用されますが、ApplicationCacheは「設計に失敗したAPI」と呼ばれるほど使い勝手が悪く、さまざまな問題を抱えています。

ApplicationCacheの問題点

ApplicationCacheに関しての紹介で「さまざまな問題を抱えています」と書きましたが、ここではそのうちの主なものについていくつか紹介したいと思います。

読み込み元htmlがキャッシュされる

ApplicationCacheを使用する場合、仕様上ApplicationCacheを使用しているhtmlもキャッシュされてしまうため、動的なコンテンツを出力してもすぐに反映されません。

そのため、ApplicationCacheを使用する場合は基本的に1枚の静的なhtmlを用意し、動的な部分はすべてJavaScriptを使用して構築することになります。

これはWebサイト構築の当初から想定している場合は問題ありませんが、サーバサイドで動的にコンテンツを生成している既存のWebサイトに対して、あとからApplicationCacheを導入する場合には大きな障害になります。

キャッシュのクリアが困難

ブラウザによってはApplicationCacheをクリアするUIを提供していないものもあり、開発中も含めて一度キャッシュされたApplicationCacheをクリアするのが困難な場合があります。

特にiOSの場合、アプリが独自に使用しているUIWebViewのApplicationCacheをクリアするには、アプリを削除して入れなおす以外の方法がありません。
（アプリが独自のUIを提供している場合を除く）

JavaScriptからキャッシュを操作することができない

JavaScriptからApplicationCacheに関しては「キャッシュ状態の確認」、「サーバ上のデータ確認」、「キャッシュの破棄」を行うことができます。

ただし、キャッシュ操作は全キャッシュに対しての操作のみで、個別のファイルに対しての操作は提供されていません。

そのため、「高速化のために出来るだけキャッシュするファイルを多くしたいが、キャッシュするファイルが多いとキャッシュの更新に時間がかかる」という状況になります。

キャッシュの更新は自動的に行われるため基本的にブラウザ側で操作を行う必要はありませんが、逆に「一部のキャッシュのみ更新したい」、「更新順に優先度を付けたい」、「指定したキャッシュが更新されたらJavaScriptからアクセスしたい」と言った内容は実現できません。

それでも使われるApplicationCache

問題点の多いApplicationCacheですが、現状ブラウザがオフライン時にコンテンツを提供するためにはもっとも現実的な方法であるため、問題点があることを前提で使用されている状況です。

もしApplicationCacheを導入する場合、以下の点に注意してください。

最初に導入するか決断する

ApplicationCacheは仕様的にシングルページアプリケーション（1枚のhtmlをベースにJavaScriptでコンテンツを構築する形式）を想定しており、サーバサイドで毎回htmlを組み立てて出力する形式は想定されていません。

サーバサイドで毎回htmlを組み立てて出力するコンテンツの場合でもiframeを経由するなどして活用することは可能です。しかし、iframe内のApplicationCacheに対する状態管理とiframeと、本体間のキャッシュデータをやりとりするコードが必要になるため、実装は複雑になります。

最悪の事態を想定する

ApplicationCacheは使い方によっては完全にサーバから独立して動く事が可能ですが、場合によってはサーバからの変更を一切受け付けなくなってしまう状態に陥る場合があります。

もしサイト上でApplicationCacheを使用する場合、常にネットワーク上からダウンロードするJavaScriptを読み込ませておき、最悪の場合でもJavaScriptからリダイレクトの指示を出せるようにしておくことをおすすめします。

ここまでキャッシュの設計やAPIに関して紹介してきましたが、ユーザから見た場合キャッシュとは「最良の通信やパフォーマンスが提供されない場合の代替手段」であり、本来存在しないことが求められる技術でもあります。

そのため、もしキャッシュを使用する場合、「ユーザの意図に反した動作にならないか」、「最良の状態でないことをユーザが理解できるか」といったことを意識して使用してください。

エキスパートが手がけたプロダクトを題材に技術的な解説を行っていくシリーズ連載、今回は wri.peです。 難しい機能の実装や、先進的なAPIの利用を通じて、執筆者が得たノウハウを余すところなく紹介していきます。

HTML5を活用したメモ帳アプリ [wri.pe]

最近、仕事で作っているミイルが忙しかったり、趣味で作っているMobiRubyがなかなか進まなかったりして、個人でWebサービス的なモノを作っていない事が自分としてちょっと気になっていました。

そこで息抜きとして、ゴールデンウイークに集中してWebサービスを一つ作ろう！と思い立ち、wri.peというWebサービスの開発に着手しました。

wri.peは自分が使いたいと思えるメモ帳を作ったので、下記の様な特徴を持っています。

• Markdownフォーマットをサポート
• Gmailの様なアーカイブ機能
• 全文検索
• カレンダーへのマッピング
• iPhone / iPadをサポート
• キーボードで操作ができる

ゴールデンウイーク期間中に一通り作った後、一カ月ほど自分で使いながらブラッシュアップし、6月3日に正式にリリースしました。

初めて個人でプレスリリースを打ってみたところ、個人でリリースしたWebサービスとしては多くの国内外のメディアやブログに取り上げていただきました。

wri.pe

wri.pe（モバイル）

wri.peが目指すモノ

wri.peは息抜きで作ったモノですが、せっかく作るのだからといくつかの目標を立てました。詳しくはブログをご覧頂きたいのですが、その中の一つに、新しい技術で製品レベルのサイトを作った場合に起こる問題点などを把握したいという目標がありました。

HTML5の機能やBackboneJSなど耳にすることはあっても、実際に製品レベルのサイトで使って大丈夫なのか自分の肌感覚として把握できていないと仕事などで使うことができません。

HTML5というと、CSS3を用いたアニメーションや3D表現、ビデオやオーディオの標準化など、ブラウザ上の表現力向上が多く取り上げられます。 またHTML5の仕様には入りませんでしたが、WebSocketを用いたリアルタイム通信やGeolocation APIを使った位置情報の取得なども、広義のHTML5として話題になっています。

そこでwri.peでは、HTML5の中でも速度の向上にターゲットを絞って、新しい機能を使ってみることにしました。

サイトの高速化のためにHTML5を使用する

ほとんどのブラウザでは、通信をキャッシュする機能を有していて、同じページや画像の表示を高速化しています。 このキャッシュの制御はWebサーバで設定を行い、HTTPヘッダに特別な値を設定する事で有効期限などを設定することができます。 HTML5では、そうした既存のキャッシュ機構に加えて、Application Cacheというキャッシュ機構を持っています。

Application Cacheで通信を減らそう

このApplication Cacheは本来、Webアプリをオフラインでも動かすために、通信状況に関係なくHTMLや画像を読み込むことのできるキャッシュとして設計されました。 しかし通常のWebサイトでもこのApplication Cacheを使うことで、画像などを読み込むためのネットワークアクセスを抑制し、ページの読み込み速度を上げることができます。

Application Cacheは、マニフェストファイルと呼ばれるファイルにキャッシュしたいファイル名を書くだけでキャッシュが行われます。そのため、HTMLやJavaScriptファイルに変更の必要がなく、手軽に導入できるというメリットがあります。

変更頻度の低いロゴなどの画像やCSSなどをこのマニフェストファイルに記述し、HTMLの中でマニフェストファイルのパスを指定するだけです。

なお、wri.peではrack-offlineというライブラリを使い、マニフェストファイルを生成しています。

例) http://wri.pe/application.appcache

CACHE MANIFEST
# 91ccff4f438451ad735c534b974c29e2ff1b08a9da4e71f928b5fc2f4ba6bd02
/assets/app-437607bb972a49c7922a504cfe02226a.css
/assets/app-7c794995cb685c8412ee2f1facea67e3.js
/fonts/fontawesome-webfont-311.ttf
/fonts/fontawesome-webfont-311.woff
/images/wripe114s.png
/images/dropbox_icon128.png
/images/wripe400s.png
/images/wripe-top880.png
/images/masuidrive64.jpg

NETWORK:
*

HTML部

:html:
<!DOCTYPE html>
<html lang="en" manifest="application.manifest" xmlns:og="http://ogp.me/ns#" xmlns:fb="http://www.facebook.com/2008/fbml">
<head>
....

Application Cacheでは、コメントも含めマニフェストファイルが１文字でも変更されるとキャッシュが破棄され、ネットワークから最新のデータが読み込まれます。 このキャッシュの制御はJavaScriptから行う事が可能なのですが、iOS 6ではバグがあるようでJavaScriptからキャッシュの更新などが正しく行えないようです。

またリソースの変更後にマニフェストファイルを更新しても、その変更が反映されるのは次回の読み込み時になります。そのため、更新頻度の高いファイルをキャッシュする用途にはあまり向きません。

wri.peでは、RailsのAssets Pipelineという機能を使い、JavaScriptとCSSをそれぞれ一つのファイルにまとめることで、ファイルの読み込み回数を減らし、表示を高速化しています。

実際に読み込み時間を比較してみます。赤い縦の線が、大体画面に表示される時間だと思ってください。

キャッシュのない状態では1,150ms、キャッシュありでは200msほどになります。

テストでは、回線が高速なため、思ったよりも差が出なくなっていますが、スマホなどでキャッシュなしの場合には、これより数倍遅くなる事が多いと思われます。キャッシュありの場合では回線速度に依存せず、安定して高速な読み込みが可能です。

また、Application Cacheにキャッシュされているファイルは、ネットに繋がっていない状態でも読み出すことができます。 試しにPCをネットから切り離すか、iPhone/Androidをフライトモードにして、https://wri.pe/app にアクセスしてみてください。全てのファイルがキャッシュから読み込まれるため、ネットに繋がっていない状態でも同じように表示されるでしょう。

ただしメモ帳のデータはApplication Cacheには入っていないので、本来であればオフライン時に読み込むことはできません。しかしそれらの情報はまた別の方法でキャッシュしているため、オフライン状態でもメモ一覧が表示されるのです。

次回予告

今回はApplication Cacheを使い、各種ファイルの読み込みを高速化する手法を取り上げました。

wri.peでは、メモ帳データのようにAjax通信で取り出すためキャッシュしにくいデータも、localStorageを使いキャッシュしています。

次回はlocalStorageを用いたデータのキャッシュや、PC向けブラウザ、iPhone/Android、iPadなどのタブレットを一つのHTMLで対応する手法について解説します。

「HTML5でサイトを高速化─wri.peで学ぶ、イマドキのWebアプリの作りかた（後編）」に続きます。