改善ニュース・最新動向feedRSSこの広告は、90日以上更新していないブログに表示しています。Web(次世代のモバイルWeb)」がそこそこに激アツな気がしたのですが、予想に反し、あまり注目を集めていません。Photosのようなわかりやすいキーワードの方が注目されるでしょう。エンジニア向けメディアであっても、昨今のモバイル技術の状況を鑑みて、ネイティブアプリの方を扱いたいと感じるのが当然です。先日、某懇親会で「え、モバイルをWebでやっているのですか?それ、完全に負け組じゃないですか」と言われ、そこまで印象が悪いものかと心を痛めました。負け組とか、Webがかわいそうじゃないか。そんな状況というのもありまして、先日の「第58回HTML5とか勉強会」では、あえてGoogleらが考える「次世代モバイルWeb」のトークをさせて頂きました。驚くほどの反響をいただけました。その中身について、本エントリーで簡単にご紹介します。モバイル上のWebは、何がダメなのか?現状のモバイルWebの問題点は何か?ネイティブにはできて、Webにはできないユースケース、ユーザビリティの阻害要因は何でしょうか?技術的な面だけで見ると、以下3つのポイントが考えられるでしょう。ブックマークが役に立たないPCとモバイルとでは、アプリが担う役割の大きさが異なります。モバイルでは、一つのアプリに多くの機能やユースケースを与えてはいけません。UIの数は限定し、ユースケースを跨ぐ場合はディープリンクを活用して別のアプリへ移動する。Facebookがメッセーンジャー機能を独立したアプリにしていることからも、その状況が伺えるでしょう。PCの時代のブックマークに相当していた役割が、モバイルではホームスクリーンへと移った。ブラウザを起動し、ブックマークを使ってWebサイトへ行くというのは、ユーザにとっては不便でしかありません。モバイルWebにおいて、ブックマークはその役割を果たせないのです。閉じられたら何もできないブラウザとネイティブとでは、その上で動いているアプリのライフタイムに決定的な違いがあります。ネイティブアプリは閉じられてもバックグラウンドで処理が行えますが、ブラウザは閉じられると、少なくともクライアント上では何もできなくなります。PCの時代、コンピューターは必要な時だけ起動され、不要になれば電源を落としました。ブラウザも同様に、必要に応じて起動され、不要になれば閉じられました。モバイルの場合、コンピューターもアプリも、常時起動が当たり前です。使わない時に電源を切る、という活用方法はあまりしません。なると、バックグラウンド処理があり、必要に応じてユーザへ通知が行えるネイティブの方が、ユーザに対して優しくなれます。ブラウザという仕組みが、モバイルのユースケースと合わないのです。ネイティブ」を論じる時、非常によく耳にするのがパフォーマンスの悪さ。大きさや重さに制約があり、また使える電力にも制限がある以上、モバイルはPCを超えることなんてできません。電力消費を抑えようと、ネットワークインタフェースは通常時にはスリープされ、CPUリソースも制限されます。そんな状況下で、出来る限り高いパフォーマンスを求めようとなると、やはり柔軟性の高いネイティブを選ぶことになるでしょう。次世代モバイルWebでのアプローチここまでに挙げた3つの問題点。Web」にて、その改善方法を提案しています。WebにモバイルらしいUIを与えようブックマークやブラウザのUIが問題だというのなら、それを根本的に変えてしまおうという案があります。Webサイトをブックマークするでなく、ホームスクリーンへランチャーアイコンとして登録する。そこから起動された際は、モバイルらしいUIを被せてWebページを表示させることで、ブラウザが抱えていてユーザビリティの問題を解消しようというものです。Manifest」を使います。この機能により、モバイルらしいランチャーアイコンを登録させたり、モバイルだと嫌がられがちなLandscapeを使えないようにしたり、邪魔なアドレスバーを無くしたりと、Webに足りていないものを埋めていきます。Webにモバイルらしいライフタイムを与えようモバイルは、ネイティブアプリにあるようなバックグラウンド処理を必要としています。ブラウザはタブの有無に依存せず、独立して処理を行える仕組みを持てば、ネイティブと同じ時間をユーザと共にすることができるでしょう。Workerは、ブラウザ内で独立したローカルプロキシとして動くことで、ネットワークに依存せずにWebページを扱えるようにすると共に、Pushサービスからメッセージを受け取りユーザに通知するといった活用方法が期待されています。Workerはライフタイムの問題というレベルで着眼し、解決を試みています。ユーザにストレスの無いパフォーマンスを目指そう最後にパフォーマンスについて。これはどのようにして解決すべきかという具体的な方法は説明されませんでしたが、目指すべき指標のようなものが説明されました。速いを目指すというよりも、ユーザがパフォーマンスの劣化を意識しないという基準のようなものがあり、そこを満足するように努力していこう、というものでしょう。それが「RAIL」です。RAILは、Reaction(応答の速さ)、Animation(アニメーションの速さ)、Idle(処理無し状態を作る時間)、Load(読み込みの速さ)の略称です。これらが一定の基準を満たせば、ユーザは「パフォーマンスの劣化を気にしない、遅さを感じない、ということです。速さの基準を満たせれば、ネイティブであることにこだわる必要はない。詳しくは過去の私のブログでも紹介しているので、気になる方は確認してみるといいでしょう。furoshiki.hatenadiary.jp最後にまとめると、モバイルWebはこう作るといい感じ!ということでしょう。このセッションで語られた内容は、モバイルWebがアーキテクチャの転換期であることを予感させられます。実態としてはアプリストアの影響が強かったり、Androidのバージョンのフラグメント問題が解決されていないため、すぐにそうなれるとは思えません。長くても2年後には、何かしらの変化が期待できそうですね。時期が来ても、ネイティブアプリが全て失われるということでもなく、互いの良さを活かす形で共存していくのだろうと私は考えています。なんでもかんでもネイティブにするのではなく、Webに向いている所はWebでやるという、今のPCみたいな状況に戻るのではないかと思うのですが、さて、どうなるんでしょう。どちらにせよ、Webが複雑化するのは避けられ無さそうですね。こちらが発表スライドです。細かく、説明していますので、併せてご確認ください。HTML5はネタが出尽くした。寛)2009年よりNTT系SIerにてエンタープライズOSSやWebの技術を推進。2015年よりピクシブ株式会社にWeb系エンジニアとしてジョイン。2016年からは、同社のマネージャー職として活動しています。html5jパフォーマンス部とか、日本Cordovaユーザー会を立ち上げたり。エキスパートだったり。2015年1月号「特集:HTML5」他、執筆。「2014年4月」はIEの歴史を動かした。-はてなブログをはじめよう!furoshiki0223さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。