LIFULL FinTechの島田です。
LIFULL FinTechで運用するLIFULL保険相談サイトの一部ページにAMP（アンプ）を導入しました。
その際に検討した内容とリリース後しばらく運用してみて得られたAMPに関する知見を共有いたします。
AMP（Accelerated Mobile Pages）
AMPはGoogle社とtwitter社が共同で推進しているプロジェクトです。 もともとはネットワーク環境や端末のハードウェアリソースが足りない地域向けにデザインされたものと言われています。 AMPはAMP-HTML、AMP-JS、AMP-CACHEの3つのコンポーネントで構成されています。
AMP-HTML
AMP-HTMLはAMP用にHTML5の拡張として設計されたHTMLです。 AMPページとして認識されるために通常のHTMLとは異なる記述が求められます。
大きいところとしては以下の3点かと思います。
- imgタグの代わりにamp-imgタグを使用する必要があります
- cssはhead内に展開する必要があります
- 構造化データを挿入してページタイプを宣言する必要があります
ページタイプについてはすべてのカテゴリがカバーされているわけではありませんが、自サイトと乖離したページタイプを宣言するとスパム行為としてみなされる恐れもありますので注意が必要です。
定義済みページタイプはAMP Projectのガイドをご参照ください。
AMP-JS
AMPページではAMPプロジェクトが認可するJavascript以外は実行できません。 ここがAMPページを作る上でつらいところでもあるのですが、軽量化とキャッシングのために必要なものだと受け入れましょう。 サイトによってはGoogle Tag Manager（GTM）を使用してASPなどが提供するカスタムJSを実行しているケースも多いと思います。 その場合もカスタムJSは実行できませんので注意が必要です。AMP用のGTMコンテナを作成しコンテナ内で許可されているタグのみ実行可能になります。
開発時に調査した際にはAMPページから一度非AMPページへ遷移させて計測ポイントを経由させているサイトもありました。ただこの場合はユーザの遷移が１段増えますのでユーザビリティの観点から仕様の検討が必要だと思います。
AMP-JSには基本的なUIはカバーされています。LIFULL保険相談でもグローバルメニューや写真表示、アコーディオンなど、AMP-JSのコンポーネントを使用して運用中の非AMPページとUI的に遜色無いレベルのものを作成できました。
AMP-CACHE
AMPページを作成する場合に既存ページをどのように扱うか、サイトのURL戦略とすり合わせが必要になります。サイトの流入数に影響を及ぼしますので自サイトのAMP化のロードマップと既存のサイト戦略を慎重に整理して考える必要があります。
- アダプティブデザイン
- AMPページを新規に作る（１）
- 既存のモバイルページをAMP化する（２）
- レスポンシブデザイン
- AMPページを新規に作る（３）
- 既存のモバイルページをAMP化する（４）
- PC向けとモバイル向けのページをそれぞれのURLで配信している
- AMPページを新規に作る（５）
- 既存のモバイルページをAMP化する（６）
web検索で事例がよく上がるのは（１）のケースだと思います。多くの実績があり資料も豊富なのですが、このケースではページが３種類（PC向けページ、モバイル向け非AMPページ、モバイル向けAMPページ）出来上がることになります。同一URLでページの種類が増えるとそこにかける改修コストもn倍になってしまうデメリットもあります。
今回AMP化を検討したページはユーザの回遊フロー上、末端のページになりますので頻繁に改修が入り得るものでした。さらにクライアントからの入稿データが直接表示されるものでもありました。
また、偶然にもGoogle社のAMP推進担当の方とお会いすることができました。参考事例が少ないことに対するリスクはコミュニケーション量で回避できましたので、既存のモバイルページをAMP化する（２）の方針を選択しました。
UAによる振り分け
検索ボットがAMPページを見つけるためには以下の方法があると言われます。
- sitemapの送信
- 非AMPページのlink-rel属性
- ダイレクトアクセス
web上の資料では2の経路でAMPページが検索ボットの目に止まることになります。LIFULL保険相談の事例では既存ページのサーバが直接AMP-HTMLを返します。PC向けとモバイル向けでボットが別になっているので問題ないとされつつも事例があまりないということで、実験の結果を経てAMP-CACHEにモバイル向けページの内容がキャッシングされることが確認されました。
AMP対応してわかったこと
AMP化を実装して感じたことがいくつかありました。
SERPをイメージする
URL設計から実際に AMPページとしてインデックスされるところまでシナリオをイメージできるか、ということになります。AMP化する以上はAMP-CACHEに載り自然流入やリッチカードによるSEO効果を得たいところです。ただGoogle社のサーチに関する情報は秘匿されており確たる情報がありません。その中でも理論的な道筋と実証によりひとつずつシナリオを練り上げる必要があります。
URLの設計
既存のwebサイトでよくあるのはURLの最後に「/amp」のようなものがついていてそれがAMPページとなっているケースが多いです。ただURLはパンくずと厳密に対応させているサイトも多いと思います。この方法だとURLが示す情報構造が崩れ、設計上の柔軟性が失われかねません。また前述の通りページの種類も増えますので運用コストも増加します。とはいえ既存ページをAMPページで上書きすることによる技術的・ビジネス的なリスクを許容できるかどうかを判断する必要があります。
Javascriptが制限される
これはもうどうしようもないですね。言ってもしょうがないところがあります。とはいえajaxを使いたかったり計測用のカスタムタグを入れたかったりすることは多いと思います。すでにリリース済みの運用ページならなおさらだと思います。また、AMPを導入することを前提にしているとそこが技術的な判断の境界線になります。Javascriptが制限はされますがその分ロードする外部ファイルがスリム化されますのでダイレクトアクセスでもロード時間が短縮されることが多いと思います。AMPを導入する際には機能的な面からもメリットとデメリットを天秤にかけ長期的に検討する必要があると言えます。
まとめ
AMP導入によりインデックスも得られ、高速なレンダリングが実現できユーザビリティの向上が得られました。また国内の保険業界の中でもいち早く最新技術を導入することに成功しました。AMPは制限が多いことは事実ですがPWAなどと共に今後の技術展望も開けています。今回サイト内のすべてのページで導入するまでは至っていませんが、今後はAMPの効果を最大化させていきたいと思います。本記事がAMP導入において有益な情報となりうることを願います。
