昨日、「AMPが導入された結果、現時点ではモバイルのブラウズ体験が大きく損なわれてるのですが、そう感じるのは僕だけでしょうか」とTwitterでつぶやいたら、いろいろ反応があり、いろんな観点を知ることが出来たのでメモしておく。なお、自分自身はまだAMPのコンテンツを実装したわけではなので、開発者の知識はなく、ただのコンテンツ消費者としての知識しかない。開発している人から見るとまた違った見え方があるかもしれない。
コンテンツ消費者側のメリット・デメリットという観点
- AMPによるコンテンツ消費者側のメリットは速度面だが、モバイルを利用していた時に現時点では速度に困っていなかったので、自分はメリットを享受できていない
- 現時点では、いろんな理由によりユーザ体験が損なわれている部分がある
- ユーザ体験が損なわれている例としては、プラットフォームの問題とコンテンツ制作側の問題の両方がある
- プラットフォームの問題 : ブラウザバックすると変なところに戻ったり、閉じるボタンを押すとタブ自体閉じてしまうときがあるなど
- コンテンツ制作側の問題 : 開発者側がうまくコーディングが出来ていないなどの理由で、画像や動画など一部コンテンツが見えなくなってしまうなど
- 現時点で自分の環境では、速度が向上するというメリットよりも、ユーザ体験が損なわれる(そもそもコンテンツが見れないなど)というデメリットのほうが大きく感じられる
過渡期の問題であるという観点
- しかし、今は過渡期ということもあるので、ユーザ体験が損なわれるのは今だけかもしれない
- もし、AMPのコンテンツを構築すること自体が難しかったり、標準ページとAMP用ページの二重管理が難しかったりと、AMPの根本的な難しさが一定以上だと、過渡期という問題だけでは済まないかもしれない
サービスによっては必要ないという観点
- サービスがそもそも一定の速度を保てているのならAMP対応は必要ないのかも
- しかしグローバル展開するなら、地球の裏側でもまともなUIを提供したいので、AMPに乗っかることでレイテンシの観点で速度に大きく影響を与えるのかも
ノウハウが蓄積すれば改善されそうという観点
- 例えばHTMLを与えると、それをAMPに変換してくれるモジュールがあれば問題ないとか
商業的メリットの観点
まとめ
いろんな観点がある。まだ発展途上な部分はあり、みんな手探りでやってる感があるので、今後どうなるのか気になった。
しかし、何かが変化することはインターネットが良くなるためのチャンスでもあると思うので、試したら細かいことでもどんど?フィードバックすると良くなりそうという印象も受けた。下のようなTweetもあったし、気軽に日本語でレポートしたら良さそう。
「AMPを実装してうまく動かなかった」という体験などを公にしてもらいたい。技術面であればOSSだし本体に直接レポートでも構わないし、日本語でブログなどに書いてもらったら、見つけ次第妥当なものは開発チームと共有したい。
— Yoshi Yamaguchi (@ymotongpoo) 2016年11月9日
Twitterのログ
会話したり、いろんな意見を書いてくれた人のログを貼っておく。
AMPにした場合のメリットが速度なのであれば、確かに速度が上がったのは嬉しいのですが、これまでそもそも速度で困っていなかったので、単にユーザビリティが減ったと感じていました。これが今後成熟するのかそうでもないのかはわかりませんが…
— 柴崎優季 (@shiba_yu36) 2016年11月8日
なるほど、そういうことがあるんですねぇ。
— Jxck (@Jxck_) 2016年11月9日
現段階ではそうですね。ただこれはサービスリニューアルと同様の現象に感じるので、どうなるかはもう少し経ってからじゃないと分からなそうです
— 柴崎優季 (@shiba_yu36) 2016年11月9日
AMP 化されたページが早くなった結果、相対的に遅くなった広告がなかなか表示されず、ユーザの目に止まらないためコンバージョンが下がるみたいなケースは聞いたけど、雑な適用で壊れてるコンテンツもやっぱりあるのかなぁ。
— Jxck (@Jxck_) 2016年11月9日
AMP 対応するコンテンツ側の問題は、過渡期だってことで様子見になるかもしれませんが、そうでない場合 AMP の最適化方針自体、つまり現在のコンテンツ作成プラクティスとされてる何かに穴があるのかなと思い気になりました。
— Jxck (@Jxck_) 2016年11月9日
僕が正しく理解できているかわかりませんが、AMPのコンテンツを構築すること自体が難しかったり、標準ページとAMP用ページの二重管理が難しかったりと、AMPの根本的な難しさが一定以上だと、過渡期という問題では無いかもしれませんね
— 柴崎優季 (@shiba_yu36) 2016年11月9日
AMPで画像出なかったりして使い勝手悪いというの,AMPを配信する側のブログサービスとかがHTMLをAMPに変換するときの実装が足りてないために画像が出なかったりしている,という認識で,正しく実装しないと見れないのはHTMLもそうなので,ノウハウが蓄積されれば改善されそう
— 趣味はマリンスポーツです (@hitode909) 2016年11月9日
「AMPを実装してうまく動かなかった」という体験などを公にしてもらいたい。技術面であればOSSだし本体に直接レポートでも構わないし、日本語でブログなどに書いてもらったら、見つけ次第妥当なものは開発チームと共有したい。
— Yoshi Yamaguchi (@ymotongpoo) 2016年11月9日
HTMLをそのままAMPに変換するモジュールがあると解決するのかもしれない(適当なことは言ってる)
— 柴崎優季 (@shiba_yu36) 2016年11月9日
AMP なんかなくても十分に速度的 UX が提供できてるサイトにとっては無駄でしょうね。一方どの程度のサイトでそれが可能かはわかりませんが。その上で時間をかけても解決できない根本的な問題があるなら AMP は失敗なのかもしれませんね。
— Jxck (@Jxck_) 2016年11月9日
乗っかると自分のサイトが表紙に出るという商業ですからね。
— mattn (@mattn_jp) 2016年11月9日
Web の速度で困ってないのは、日本だからというバイアスに注意する必要がありそう。一方、日本語サイトはこの国にしかみる人がいないから、地球の裏側でまともな UX が無くても別に構わないというのは、経営判断としては妥当。 AMP のプロジェクトは国を限定してない。
— Jxck (@Jxck_) 2016年11月9日
きちんとチューニングができてるサイトにとって AMP なんてやる意味はないが、 SEO の問題でやらざるを得ないのは、完全に無駄。逆を言えば「まともにチューニングできてない」サイトの改善に向けて AMP に SEO などの餌をつけたのは、多分そっちの方が大多数だったからだと思う。
— Jxck (@Jxck_) 2016年11月9日
AMPはやっぱり過渡期の技術なんじゃないかなーとは思いますが。
— 徳永広夢 (@tokuhirom) 2016年11月9日
AMP 対応の敷居のために Chrome にビルトイン入れ、 SearchConsole もエラーを出すから、成熟って意味だとネックは CMS なんだろう。二重管理の手間は、多くの技術の無いサイトが最初から一重(origin=AMP)っていう構成になるのを促したい雰囲気を感じる。
— Jxck (@Jxck_) 2016年11月9日
AMP にはプラクティスのサブセットが盛り込まれてるけど、そのせいでプラクティスを適用できている publisher が余計な手間をかけさせられてるという現状は実際あると思うけど、そうことできるところなら AMP だってなんとか乗りこなすだろって Google は舵を切ってる感。
— Jxck (@Jxck_) 2016年11月9日