Experts.jp日本に、もっとエキスパートを。Apps)をご紹介させていただきます。当時オフラインやプッシュ通知など、モバイルウェブを飛躍的に進化させる画期的な機能が次々と追加されていた状況において、このムーブメントを呼称するための言葉が求められていました。Russellが推したのが、この「プログレッシブウェブアプリ」でした。SummitではMicrosoft、Mozilla、Opera、Samsungの代表者も登壇するなど、各ブラウザベンダーとも足並みが揃いつつあります。これはもはやウェブ全体の動きと言うことができます。記事を読む以外に手早く情報を得るための方法として、下記を挙げておきます。講演動画プレゼン資料プログレッシブウェブアプリとはプログレッシブウェブアプリとは、最新の標準ウェブ技術を用いることで、オフラインやプッシュ通知といったこれまでよりも一次元上のユーザー体験をもたらすウェブアプリのことです。デスクトップのウェブアプリや、ページ遷移を使ったサーバーサイドでレンダリングされるアプリを除外するものではありません。理屈で説明するよりも、実際に体験した方が早いかと思います。いくつか具体例を挙げましょう。他にも様々なプログレッシブウェブアプリが既に存在していますが、pwa.rocksというサイトにいくつかまとまっていますので、ぜひご覧頂下さい。実際に使ってみるとわかりますが、これらのアプリケーションにおいてこれまでにない特徴的な点がいくつかあります。自動でログインプログレッシブとは何か「プログレッシブ」という言葉自体は直訳すると「進歩的な」といった意味がありますが、ピンとこない方は多いと思います。プログレッシブウェブアプリの「プログレッシブ」のひとつの意味は、ウェブページとして使い始めたサービスが、ホーム画面に追加し、オフラインで動作し、プッシュ通知を送り始めるといった流れの中で、「徐々にアプリへと変化していく」様を指しています。フロントエンドエンジニアであれば、プログレッシブ・エンハンスメントという言葉を聞いたことがあると思います。時代に続々と新しい機能が登場する中で、最新の標準技術をまだ盛り込んでいないブラウザでも、情報を届けるといった目的をゴールに、必要最低限の機能をベースとして、可能であれば最新技術を使うことでよりリッチな体験を提供する、という設計コンセプトのことを言いました。(逆に、リッチな体験を提供できるブラウザをベースに、最新の技術が使えないブラウザでも最低限の目的は達成できるように設計する手法をグレースフル・デグラデーションと呼びました)プログレッシブウェブアプリも同様に捉えることができます。機能として提供する、というものです。これは言い方を変えれば、対応していないブラウザがあるからといって対応を待つべきではなく、それを前提としてウェブを前に進めていこう、というメッセージでもあるのです。実際、プログレッシブウェブアプリ対応への副作用として、複数の機能に未対応のブラウザでもコンバージョンレートが改善したという事例も出ています。アプリとウェブのギャップWeb2.0の時代を経てコンピューターの世界はネイティブアプリケーションからウェブアプリケーションの時代へと変化を遂げました。地図アプリケーションを思い出して下さい。その昔CD-ROMからせっせとインストールする必要のあった地図が、URLひとつでブラウザから見られるようになったのです。他にも例を挙げればキリがありません。ウェブはその後もHTML5やその周辺技術の発展により大きく進化していきました。その恩恵を満足の行く形で受けられたのはデスクトップでの話。モバイル・スマートフォンの時代となり、ユースケースが変化していく中で、スマートフォン上で快適に目的を達成するためには、ウェブブラウザは力不足と言われるようになってしまいました。その象徴的な出来事の一つがFacebookのCEOマーク・ザッカーバーグによるこの発言でした。Japanこれはひとえに標準化を必要とするウェブという環境の特性ゆえと言わざるを得ません。標準化を進めつつ実装し、浸透を待たなければならなかったウェブと異なり、ネイティブアプリはモバイルに最適化した仕様や機能を次々と取り込み、技術革新を起こしていきました。ウェブには、ネイティブアプリでは実現できない特性も持ち合わせています。それがSLICEと呼ばれるものです。(一時的な利用)ウェブもネイティブも、お互いの短所を埋める進化を遂げていく中で、ウェブが着実に前進していることの現れが、プログレッシブウェブアプリと言えるでしょう。一度はHTML5化を断念したFacebookがプッシュ通知を採用したのはその最たる例です。2.0、HTML5と続いてきた大きな流れの、次の一歩と捉えて間違いありません。プログレッシブウェブアプリを構成する機能プログレッシブウェブアプリはそれ自体が機能を表しているわけではなく、様々な先進的機能をまとめたひとつのムーブメントです。具体的にどんな機能があるのか、ひとつひとつ見ていきましょう。APIHTTPSプログレッシブウェブアプリに対応する上で大前提になるのがサイトの完全なHTTPS対応です。ログイン画面や商品購入画面だけではなく、すべてのページをHTTPS化する必要があります。一般的に、HTTPSに対応することでウェブサイトはウェブサイトの一意性を守るアイデンティティ(Identity)サーバー・ブラウザ間の通信を秘匿するコンフィデンシャリティ(Confidentiality)送受信されるデータを改ざんさせないインテグリティ(Integrity)の3つを手に入れることができます。(セキュアコンテキスト)するという点です。呼ばれ、以前はHTTP上でも動作したgetUserMediaやgeolocationといったAPIもそこに加えられ、最近HTTPSのみで動作する変更が加えられました。HTTPSに対応することなしにプログレッシブウェブアプリを実現することは不可能ですので、対応を検討する方はここからスタートして下さい。Manifestネイティブアプリとウェブサイトを比較した時に、最も大きく異なるのがアクセスのしやすさです。アプリのようにインストールしなくても、リンクを踏むだけでアクセスできるという意味で、ウェブは手に届きやすい存在です。スマートフォンの場合、デスクトップのようにキーボードで手軽に検索ができるわけではありません。ホーム画面からタップひとつで起動できるだけで、ユーザーにとっての身近さは大きく改善します。Manifestです。Manifestを使うことで、該当ページに関する様々な情報を定義することができます。MDN最近はlangやscope、screenshotsといった項目も新しく追加されていますので、その辺りも注目して下さい。これらの情報を踏まえ、「ホーム画面に追加」をすると、ウェブアプリはホーム画面に鎮座することができるようになります。この機能がiOSでも古くからあるmetaタグを使ったものに近いと思われた方もいるかもしれません。Manifestといくつかの条件が加わることで、ブラウザが自動的にホーム画面に追加を促してくれる、という点が大きく異なります。詳しくは下記の記事を参照して下さい。Workerはプログレッシブウェブアプリを構成する機能の中でも、コンセプトを成立させた一番の立役者で、中核を成すものです。従来のウェブにおいて、ページはサーバーから送られたHTMLとそれに付随するリソースで構成される機能がすべてであり、ページが閉じられると同時に忘れ去られる存在でした。Workerは、ページとは独立して動作するスクリプトを、ページを閉じた後でもブラウザ上で動かし続けることができる機能です。Workerを活用することで、様々な可能性が開かれます。Workerはページが送信するあらゆるリクエストを横取りすることができます。実質的なローカルプロキシーとなるため、強力なキャッシュを活用すれば、ネットワークに接続していない状態でもレスポンスを返すことができるようになります。APIの項で説明します。Workerはページが閉じた状態でも、また、ブラウザによっては起動してない状態であっても、イベントを検知することができます。そのため、外部サーバーが送信したプッシュリクエストをイベントとして受け取り、何かしらのアクションを起こすことができるのです。Notificationsの項で説明します。Workerの使い方を雰囲気だけ見てみましょう。Workerは独立したJavaScriptとして動作するため、ファイルも分けて記述する必要があります。Workerを使いたいとします。Workerが登録されます。service-worker.jsの中身はイベント・ドリブンのスクリプトになります。World!”とレスポンスを返します。Workerは実際いつ動作を開始するのでしょう?影響範囲はどこまででしょう?こういった細かい話になるとセキュリティへの懸念も出てくるため、若干複雑な内容を理解する必要が出てきます。scopeとライフサイクルについては抑えておきましょう。Workerが登録されると、以後半永久的にスクリプトを動かし続けることになります。Workerがドメインの範囲内すべてに影響をおよぼすことができるとすると、ブログなどのユーザーの権限がパスで区切られたサービスでは、自分の預かり知らないスクリプトが埋め込まれてしまう可能性がでてきます。Workerでは、scopeという概念を使って影響範囲を制限します。詳しくはこちらの記事が参考になります。Workerが登録されたあと、スクリプトを手動で更新したい場合もあります。Workerのライフサイクルを正しく理解することはとても重要です。下記の記事をぜひご覧ください。Applicationパネルが追加されました。Manifestや各種ストレージなどを、ひとつのパネルからまとめて確認することができます。ネットワークリクエストの横取りを一時的に停止といったオプションが利用できます。Workerの単独のDevToolsを開いてデバッグを行ってください。Worker周辺の重要な機能についても少し触れておきましょう。linkタグやHTTPヘッダーで行えるようになりました。Workerを登録できるようになります。Workerがハンドリングできれば効率が向上します。Trialベースで提供が開始されています。2016で行われたChromeエンジニアの保呂さんのスライドが参考になります。Workerを使ってあらゆるリクエストを横取りすることで、オフラインの機能が実現可能になります。APIは取得されたリソースだけでなく、リクエストやレスポンスの内容も含めて保存されます。(キャッシュに保存はしません)。APIを使った実例について、詳しくはこちらの記事が参考になります。fetch()も避けては通れませんが、ググらビリティの低さから、まとまった資料が見つかりにくいという問題があります。こちらのページがよくまっていたのでリンクしておきます。APIですが、多くの人が似たようなコードを書くであろうことは容易に想像ができます。そこで便利なライブラリがいくつかあります。sw-toolboxリソースをキャッシュする際に必要になるのが、リソースの優先順位の判定です。共通で利用されるJavaScriptファイルは、更新がない限りネットワークにリクエストを送るまでもなく常にキャッシュから読み込むことでスピードを優先したいと思うはずです。逆に例えば、天気アプリであれば、開く度に最新の天気予報を見たいですが、オフラインだった場合はオフラインだと言われるよりは、キャッシュからでもその後の天気予報を見たいと思うはずです。このように、同じキャッシュを活用するでも、場面によってキャッシュを優先したいのか、ネットワークを優先したいのかが異なってきます。そこで便利なのがsw-toolboxです。toolbox.networkFirst);sw-toolboxではネットワークを優先するnetworkFirst、キャッシュを優先するcacheFirstの他にもfastest、networkOnly、cacheOnlyといった様々なオプションが利用可能です。Cacheは、ページを初めて開いた時点で、予め定義されたリソースをすべてキャッシュするものでした。APIにおいても同様のニーズはあるでしょう。Shellというアーキテクチャを利用する場合です。これを実現するのに便利なライブラリがsw-precacheです。コードを出力してくれます。Workerとしてロードすればよいだけです。リソースの更新もハッシュを使って自動的に管理してくれるので、どのファイルを書き換えたからリストを変更しなければならない、といったようなマニュアル作業が不要になります。便利な機能を宣言的に記述することもできます。Workerに移行を検討している場合は、sw-helpersライブラリの一部であるsw-appcache-behaviorが便利です。Workerによるオフラインを実現することができます。sw-offline-google-analyticsオフラインのウェブサイトがうまく作れたとしても、ユーザーがどのアクセスページにアクセスし、どのように利用しているかが分からなければ、本当に役に立っているのかどうかを知ることはできません。Analyticsでアクセス解析結果を閲覧することができるようになります。Notificationsプッシュ通知は、プログレッシブウェブアプリを語る際、これまでできなかったことの中で、技術者ではなくても効果が理解できるという意味では、最も分かりやすい機能です。実際に既に多くのサービスがこれを利用しています。モバイルウェブ版のFacebookにアクセスしてみると、すぐにそのことに気付くでしょう。ME'}]}});});具体的な実装方法は若干複雑ですので、サードパーティーのサービスを使うのも手かもしれません。自分で実装する場合は、こちらのドキュメントがよくまとまっています。Pushが利用できます。詳しくは下記をご覧下さい。向けのライブラリも提供されています。Sync妙なタイミングでネットワークがオフラインになってしまったために、リクエストが送れなかったという経験は誰しもあると思います。そんな時にリクエストをキューしておいて、オンラインになったタイミングで送ってくれるとありがたいですよね。Workerはプッシュを受信すると、通知を出さなければなりません。これはブラウザリソースの無駄遣いを防ぐためです。バックグラウンドで購読しているフィードを更新するといったユースケースは容易に思いつきます。APIという機能です。これを使うことで、ページは与えられたバジェットを適切に配分してバックグラウンドでの処理を行うことが可能になりますので、リソースの無駄遣いを防ぎつつ必要な機能を実現できるようになるはずです。制御するためのAPIです。passwordをブラウザに覚えさせるソーシャルログインの選択肢をブラウザに覚えさせるログイン時にアカウント選択ダイアログを提供するユーザーを自動的にログインさせるといったことが可能になります。典型的なユースケースとしては、ニュースサイトやコマースサイトといった、必ずしもログインしなくてもよい、しかし提供者側としてはログインしてもらいたいサービスにおいて役立ちます。実際に利用されている例としてはAliExpressの実装が非常によくできていますので、是非一度お試し下さい。実装は基本的にフロントエンド側だけですので、比較的気軽に導入することができます。APIは支払い時のチェックアウトに必要なフォームを置き換えるUIを提供します。53から利用できるようになる予定です。APIが提供するのは、ユーザーインターフェースです。ブラウザのAutofill機能を活用することで、クレジットカードの情報や住所などを、すばやく簡単に入力できるようになります。将来的には、さらに様々な支払い方法をオープンかつ柔軟に組み込めるようになっていく予定です。リファレンスその他の機能プログレッシブウェブアプリを語る上で数えるべき機能や考え方は他にもいくつかありますが、キリがありませんのでこの辺にしておきましょう。Animation興味のある方は、この辺りもぜひ抑えておいていただければと思います。Lighthouseあるウェブアプリを指してそれがプログレッシブウェブアプリかどうかを議論するのはあまり意味のないことですが、それを示す指標を得ることはできます。それがLighthouseというChrome拡張機能です。ウェブサイトを開いた状態でこの拡張を起動すると、プログレッシブウェブアプリの対応度合いをスコアで示してくれます。moduleとしても利用が可能です。https://github.com/GoogleChrome/lighthouseLighthouseはまだアルファ版の段階のため、評価できない機能が多数ありますが、今後対応していく予定です。リソースプログレッシブウェブアプリに興味を持たれた方で、最新情報を追いかけたいという方は下記のページをご覧下さい。RSSフィードも配信しています。https://developers.google.com/web/updates/資料が英語で読めない?英語が分かる人はぜひ、翻訳にご協力下さい。最後にプログレッシブウェブアプリについて長々と書いてきましたが、重要なのは決してこれらの機能すべてに対応することではありません。自分が提供するサービスがユーザーに最大の価値を提供するために必要であれば、ネイティブアプリを提供するべき場合もあるでしょう。オフライン機能だけが必要な場合もあるかもしれません。これらの機能をうまく組み合わせて、ユーザーが本当に求めている価値を提供できるアプリを開発していただければと思います。