Tender Surrender

前回の記事で解説したように、Payment Request API によってウェブでの支払いにおけるユーザーエクスペリエンスは大きく変わる可能性があります。しかし、これが本当にメインストリームになるのか、将来的に自分のサイトを対応させる必要性は出てくるのか？そんな疑問を持つ方は少なくないと思います。

僕はかなり高い確率で、今後ウェブ上でのほとんどの支払いが Web Payments を経由したものに変わっていくと予想しています。この記事では、その理由を説明していきます。

前回の記事では、フォームを最適化することでウェブの決済フローを改善するアイディアについて書きましたが、今回は新しい標準 API を使ったアプローチについて書きます。

インターネットが登場して 20 年以上が経過し、時代はデスクトップからモバイルへと移り変わりました。モバイルでは、単に小さな画面に対応しているだけでなく、よりスピード感のある体験が求められています。それは E コマースビジネスも例外ではありません。

モバイルでの決済において、66% がネイティブアプリではなくウェブ上で行われているというデータがあります。検索結果からアプリをインストールしてまで商品を購入するのは手間がかかりすぎるため、そのままウェブ上で決済しようとする人が多いことが原因と考えられます。

ただ逆にモバイルウェブサイトは、デスクトップのウェブサイトと比較として、コンバージョンレートが 66% 低いというデータも存在します。これは逆に言えば、モバイルウェブでのコンバージョンレートにはまだ伸びしろがある、ということも意味しています。

そこで今回は、フォームを改善することでモバイルウェブのコンバージョンを向上する方法を 2 つ紹介したいと思います。

3 月 13 日、Chrome Beta のブログポストが出ました。Android 版 Chrome でプッシュ通知が使えるようになったのが個人的なハイライトです。

「確かにプッシュ通知は便利かもね〜」と思ったあなた、驚きが足りません。のけぞるべきです。小躍りするべきです。
理由を説明します。

この記事は webcomponents.org の記事とのクロスポストです。

Template や Shadow DOM、Custom Elements を使うことで、機能ごとの UI コンポーネントが実現できるようになることはこれまでに説明してきました。しかし、それらを使ったコンポーネントの HTML、CSS、JavaScript を別々に呼び出すのは、非効率です。

依存関係の解決も容易ではありません。jQuery UI や Bootstrap を思い出して下さい。JavaScript、CSS、Web Font といった各種リソースを、必要に応じて別々のタグに記述しなければなりませんでした。特にタグごとにコンポーネントとして扱うことが想定されている Web Components の場合、状況が複雑化することは簡単に想像できます。

これらのリソースを、ひとつの HTML ファイルにまとめてロードできるのが、HTML Imports です。