sugiken のメモ帳

知ったことを書いていく

トップ > Rails > Google激推しのAMPをなぜ止めたか＜効果とデメリット＞

Google激推しのAMPをなぜ止めたか＜効果とデメリット＞

Rails Rep サービス運営 開発 SEO

こんにちは。
今回はタイトルにもある通りAMP（Accelerated Mobile Pages）の話です。実際に導入して半年間くらい経った段階で、「AMPやーめよ」ってなりました😨
AMP導入による効果と感じたデメリットを書こうと思います！
＊メリットは調べればたくさん出てくるので、書きません！

はじめに

どのサイトでAMPを導入したのか

自分の運営している「Rep 立教大学シラバス検索システム」というサービスで導入しました。

https://www.rep-rikkyo.com/

なぜ導入したのか

理由は3つです。

  • AMPの効果である検索流入増加のさらなる向上
  • 速度改善にハマっていた
  • AMPってもんを触ってみたい

もちろんサービス的には流入を増やすことが大きな目的です。
他は大した理由ではないですが、結果として多くの知見を得られたのでよかったです。

導入した効果

インデックスについて

さすがGoogleさん激推しなだけあって、普通にインデックスされていきます。
しかし、全体で1万ページ以上はAMP対応しているので、それに比べると少ない気が・・。通常のHTMLでは1.2万ページがインデックスされているので、それに比べても少ないです。
しかし表示回数は確かに多いですねー。あくまで表示回数ですが。

f:id:kentear:20180922220200p:plain

エラーがあるのが恥ずかしい

CVR的な目線で

向上は見受けられませんでした。

RepではCVRとしてレビュー登録者数やユーザー登録者数を設定しており、GAでトラッキングしています。
GoogleさんのAMP紹介サイトでは、

CVRが30%もアップしました！速さがユーザーに与える体験は・・・

とありますが、Repではあまり・・・😅後半に詳しく書きます！

ユーザーの声

ちゃんとは集めていませんが、元々Repは速かったし、ECやニュースサイトと比べてSEOの競合もいません。普通のユーザーにとってはどうでもよかったことかもですねー

kentear.hatenablog.com

なぜ止めたのか

1. 効果がイマイチ

通常のHTMLとAMPを比較してみると効果がイマイチでした。
GoogleAnalyticsを全面的に信用するなら、全体的に数値が低くなっていることがわかります。

通常のHTMLの場合

f:id:kentear:20180922223717p:plain

AMPの場合

f:id:kentear:20180922223746p:plain

余談

上記のように通常のHTMLページとAMPページは共存しないので、測定が難しいです。 ベストは同一ページのHTML版とAMP版のデータを比較するべきですが、AMPがインデックスされるとAMP版の方にランディングが集中するため、純粋な比較ができなくなるのです。

2. viewファイルが煩雑に

AMP対応をするにあたり、AMP用のViewをゼロから書くことはやりませんでした。
なるべく既存のリソースを活かした開発をしようと思い、既存のviewにif文を生やすことで対応しました。おかげでAMP対応はすんなり！

if amp?
  # AMPの場合
else
  # 通常の場合
end

しかし↑がviewのアチコチにあるのは意外と面倒でした。
AMPではJSが動かない。いくつかのタグが使えないので、こんな分岐が15個くらいある状態でした。

3. cssの容量管理

AMPではCSSの容量に制限があります。
Repではこれまた既存のリソースを活かすために、AMPページに必要なcssだけをimportするscssファイルを作成しました。
それをインラインにしてAMP用cssを作っていました。

がしかし、bootstrap（その中でも必要なモジュールのみ）やいくつかのcssをimportしていると制限一杯一杯💦
通常サイトのリデザインをすると、毎回AMPの方も気にしなきゃいけないのは結構面倒でした・・

まとめ

効果 < めんどくささ

完璧にこのバランスになっていまい、AMP撤廃に至ったわけです！
効果も対して上がってないので、もはや失敗ですね😅

次にAMP対応するかもしれないプロジェクトがあったら

とりあえずやって見ると思います！
小さく影響と工数の小さいところから始めてみます。
しかしサイトの事業ドメインや開発チーム、viewの管理方法などによって効果はマチマチであることを念頭に置いて、測定・検証を細かく回しながらやります。
ECで効果が出たーとか聞きますよね〜👂

これからに活かす知見

長くなったので箇条書きで！🙇

  • AMPは対応時だけでなく、その後も大事
  • 大事というかまとわりつくw
  • 効果測定はGAでできる
  • ベストの開発方法はわからないが、既存リソースと切り離すか流用するかは慎重に
  • 効果が出た！という事例はたまに見るので、やってみる価値はあると思う
  • 次やるとしたら、小さい検証をしながら。
  • AMPは絶対的ではない！

終わりに

以上AMPを止めた理由とその考察です！
結果的にはRepにAMPを導入したのは失敗でした！
失敗するという発見をできたのと、開発が少し面倒になるという気づきは大きい収穫です。

効果はやってみないとわからないです。みなさんもこの記事を読んだからといって、AMPを止めるのではなく、小さく始めて、試行錯誤してみてください。 そして『Google激推しのAMP最高だぜ！＜効果とメリット＞』という記事を書いていただければと思います！😆