PWA 推しを始めて半年。
なんか最近、僕はすっかり PWA の人って思われてるみたいです。
そしてまだまだ推します PWA 。
今回は PWA を実装する上での “Points to note” 、注意点を書き留めておきたいと思います。
見落とされがちなところや、WordPress に特化した部分も含め、事前のチェック役立てばうれしく思います。
１．ちゃんと動くために必要なこと – HTTPS
まずは PWA が正しく動作するために必要なこと。
これは、Google の開発者ページによくまとまったドキュメントがありますので、英語が苦手でなければご一読ください。
Progressive Web App Checklist – Google Developers
https://developers.google.com/web/progressive-web-apps/checklist
ここではその中でも一番気をつけなければいけないこととして、HTTPS でよくある問題にふれておきたいと思います。
Site is served over HTTPS
サイトは必ずhttpsでなければなりません。
これは PWA が稼働する大前提となります。
PWA はアプリとしてローカル（端末内）で動きますので、これが通信する対象となる Web サイトは必ず正しい証明書を持った暗号通信ができなければなりません。
HTTP 混ざってる問題
正しく設定されていれば、URLの横に鍵のアイコンが表示されます。
また、その鍵をクリックすると、「この接続は保護されています」というメッセージが表示されます。
しかし、ページ内に http 接続で埋め込まれたコンテンツなどがあると、このような表示になります。
これは僕が意図的に、この記事の中に http:// で始まる画像を埋め込んでページを表示させてみたものです。
もしこのような表示になっている場合は、Chrome でしたら DevTools を開いて、Console 画面を確認してみてください。
Mixed Content: で始まる警告の行が出てませんか？
これが https のページに http のコンテンツが埋め込まれていますよ、という警告で、ページ全体が完全な https で読み込まれたコンテンツでない限り安全なページとは判定されません。
外部へのリンク “href=” であれば問題ありませんが、ページ内への埋め込み “src=” はひっかかりますので、”http://” をキーワードにソース内を検索してみて、src=”http:// ～ というのがないか確認してみてください。
WordPress でよくある http:// の埋め込みが残ってしまうパターンとして、以下のようなものがあります。
- 元々 http で運用していたサイトに証明書を入れた後、プラグインなどで https 対応した場合に、サイドバーウィジェットなどのテキスト内に img タグや script タグが src=”http:// ～で残っている
- テーマのヘッダーやフッターに外部サイトのアイコンやスクリプトの src として http:// ～ が残っている
- プラグインが埋め込むスクリプトなどに http:// ～ の src を埋め込むものがある
いずれもけっこう探しにくく、特にプラグインなどは、どのプラグインが埋め込んだのか発見が難しかったりします。
僕も画像のアルバムを作るようなプラグインでそのような挙動をしているものがあり、捜索するのに /wp-content/plugin のディレクトリ配下に対して全検索をかけました。
これは PWA の導入如何に関わらず、せっかくサイトを https にしたのであれば対応しておきたいことですね。
２．正しいナビゲーション
PWA はアプリライクに動くのがとっても COOL ですね。
アプリ設計の基本のひとつ、画面遷移。
Web もそうですが、Web の場合はブラウザの助けがあります。
進む、戻る、といったところはブラウザにボタンがありますので、案外なんとかなりますね。
しかし、PWA にすると Manifest の設定の中でブラウザのアドレスバーやボタン類を表示しないようにすることができます。
そこがアプリっぽくていいのですが、落とし穴もあります。
iPhone キラー ： 行き止まりページ
写真がたくさん！きれいなブログ！
でもこんなことしてませんか？
<a href="some-beautiful-picture.jpg"><img src="some-beautiful-picture.jpg" width=xxx height=xxx></a>
写真を選んでクリックすると、フルサイズの画像が表示される・・・
今どきさすがにここまでシンプルな書き方はないとは思いますが、他にも動画だったりとか、こういうのありませんか？
戻るボタンのない iPhone でこれを開くと、行き止まりになります。
あなたのアプリは画像１枚しか表示できないフォトフレームアプリとなります。
他のページを開くには、アプリを強制終了して最初からやり直すしかありません。
すべてのページにナビゲーションをつけることを忘れないようにしましょう。
３．外部ページを開いて処理した後、元のページに戻る動作
ちょっと表現が曖昧で、なにそれ？って思われるかもしれませんが、使われているケースとして大きく２種類あるかと思います。
認証と決済
ひとつは認証。
SNS などの認証を使ったログインなど( OAuth とか言ったりします )のときに、ポップアップウインドウが開いてそこから認証されて元のページに戻ってきてログイン完了、というサイトを使ったことがある人は多いかと思います。
まさにその動きです。
PWA でそのままこれをやるとどうなるかというと、PWA の上に１枚ブラウザの画面が開いて認証が始まります。
アプリから Web サイトのリンクを開いたときなんかに、左上に×がついたブラウザの画面が開くことがありますよね。
あれです。
そして認証を終えて戻・・・らないのです。
左上に×がついたブラウザのポップアップ画面のまま、PWA じゃなくて普通の Web サイトに戻ってきちゃいます。
そして、そのポップアップを閉じるとそこには、認証を開始して戻り待ちの状態のまま待機している PWA がいます。
なんだか泣けてきますね。
そしてもうひとつはもっと深刻な決済です。
決済サービスのサイトがポップアップで開いて、決済を終えたら元のサイトに戻って、「お買い上げありがとうございました」の画面になる、というパターン、EC サイトではよく見かけるごく一般的な処理の流れですよね。
これも認証のパターンと同じく、左上に×がついたブラウザのポップアップの中ですべてが片付き、PWA は裏でひたすら決済待ちの状態で待機してしまいます。
どちらもそのままの状態で PWA の機能で対応することは今のところできないと思います。
回避方法としては、ひとつは画面遷移をしなくても済む方法があれば、それを採用することです。
もうひとつ、既存のポップアップが発生する方法のまま対応するためには、認証や決済のひとつ前の画面をポップアップさせてしまうことでこの現象の回避ができます。
手順としては、ポップアップウインドウから認証や決済に遷移して、ポップアップに戻す。
そして処理を終えたポップアップはその処理結果を元の画面に戻す。
というちょっとややこしい方法になります。
とっても難しそうですね。
技術系ではない人にはちょっと難しい話かもしれません。
少し技術的な作業になりますが、解決方法はあります。
英語サイトですが、こちらのサイトが参考になると思います。
https://medium.com/@jonnykalambay/progressive-web-apps-with-oauth-dont-repeat-my-mistake-16a4063ce113
いずれ PWA での使用を考慮した簡単なプラグインや API なんかも用意されるといいですね。
（作れ！？）
４．キャッシュ計画
最後の項目は WordPress に特化させていただき、そしてまたしても、PWA for WordPress を推す感じになります。
多くの WordPress プラグインでは有無を言わさず決められたデータがキャッシュされてしまいますが、 PWA for WordPress を使用する場合は、ページごとのキャッシュの可否（除外）、そしてキャッシュの有効期限を設定できます。
PWA for WordPress
日本語：https://ja.wordpress.org/plugins/pwa4wp/
英語：https://wordpress.org/plugins/pwa4wp/
キャッシュの有効期限と除外
WordPress のサイトは複雑な情報がひとつのページ（ひとつのURL、ひとつのデータ）にまとまってダウンロードされますので、一部をキャッシュから切り離すことは困難です。
そこで、一定のキャッシュの鮮度を保つため、キャッシュの有効期限を設定しましょう。
オフラインのときにキャッシュが有効期限を迎えてたらどうなるか？
古いキャッシュだけど、そのときはちゃんとキャッシュを使ってくれるように作ってありますのでご安心ください。
そしてキャッシュの除外を設定します。
これは即時性が求められるページに対して設定します。
例えば予約状況だったり、なんらかのリアルタイムな状況を表示するようなページはキャッシュを表示しても意味がありませんから、除外しましょう。
また、REST API などを利用して JavaScript でサーバーからデータを取って表示している場合などは、 REST API の URL である “/wp-json/” を除外しておくことで常に最新の情報が取得できるようになります。
キャッシュ対象の選択
さて、設定すべきところはわかりましたが、どうやってそれをリストして選択すればいいのか？
各ページのソースを表示して部品をリストするのは大変ですので、ここは DevTools ( Chrome の場合)を使いましょう。
開発者ツール、とかブラウザによって名前が多少違うかもしれませんが、ほとんどのブラウザは開発者向けの機能があります。
その中で、パフォーマンスを計測するための、”Network” といったような画面があるかと思います。
これがページを表示するために読み込まれる、ページを構成する部品のリストとしてそのまま使えます。
この中から、キャッシュを除外しなければならないものを選定しましょう。
少し捕捉しておくと、PWA for WordPress を含む、ほぼすべての PWA プラグインは GET メソッドでリクエストされるデータのみをキャッシュします。
POST メソッドはフォームなどの入力内容を送信したりすることに使われ、これがキャッシュされてしまうと問題になりますので、キャッシュしないのがセオリーです。
また、ものによっては GET メソッドでもパラメーターに毎回違う値をつけて、例えば /url/?20180929010101999 みたいな感じでタイムスタンプをつけたりして、毎回違う URL としてリクエストをすることでキャッシュを回避するようなしくみがあったりもします。
この場合はキャッシュはできませんので素直にそのまま従いましょう。
以上４点、PWA の注意点でした。
- HTTPS
- ナビゲーション
- ポップアップ
- キャッシュ
参考になりましたらうれしく思います。