【WordPress】AMP対応した＆2ヶ月で止めた話（AMP化の勘所・コツのメモ）
多分、最後発組かとは思いますが、2021年5月、当サイトはようやく AMP に対応しました。そして、2ヶ月ちょっと経った8月頭に AMP 対応を終了しました。
その過程でかなりハマったことがあるので、 貯まったノウハウを自分用にメモしておきます。
お分かりになる方向けの情報ということで平易な書き方はしません。また、多分に妄想を含んだ内容となっていますので、その点もご容赦ください。
WordPress の自前テンプレート + Automattic 公式 AMP プラグインの Transitional モードを使用、Gutenberg 以前の Classic Editor で書いた記事が大量にあるサイト、という前提で書いていきます。
AMPの利点と欠点
当サイトの AMP 導入の結果を総括するとこんな感じ。
＜Pros＞
- 爆速。ウチくらい画像が多いサイトでも、GA の「サイト速度」平均値が1.5秒前後に
- amp-ad コンポーネントが爆速。多分、他に選択肢がないレベル
- 広告視認率・CTR・CPMが驚異的に高い。特に ATF 枠で顕著
- AMP 以外でも HTML・CSS コーディング時に静的レイアウト情報の大切さを感じられるようになる
＜Cons＞
- 直帰率の上昇
- SERP からの導線減少（一行サイトリンクなどの対象外）
- 検索流入の減少と検索エンジン評価の低下
- ユーザビリティに難あり（ブラウザの「戻る」、iOS 版 Safari での共有など）
- 画像サイズ制約が面倒
- amp-ad のマッチ率が低い
また、これは技術の趨勢の話しにもなりますが、Google 検索が Core Web Vitals を重視する方針を打ち出す中、その背後にあるユーザビリティの追求まで見据えれば、最終的には AMP に拘らず、サイトの速度向上こそが重要という原点へと（世界が）立ち返りつつあるため、AMP の位置付け自体、微妙になりつつある、というのも欠点のひとつと言えそうです。
一方で、amp-ad の高速性は他に代替が思いつかないレベルであり、JS 版 AdSense や GAM で収益化しているサイトであれば、僕の感覚では、そうそう簡単には amp-ad の速度には勝てないとの認識です。（少なくとも2021年7月前半時点のタグでは）
それほどまでに AMP 広告は速いし、速いからセッションあたりの収益性が50%も向上（同期間のSP版比）しているわけで、この辺が Google が AMP に傾倒した背景なのでは？と勘繰りたくもなるわけです。
広告関連でもう一つ。AMP 広告はそのマッチ率の低さも特徴です。当サイトではSP版のマッチ率はほぼ 100% ですが、AMP 広告では低調でした。DSP/SSP は専門外のため間違っているかもしれませんが、恐らく AMP の広告入札は S2S とみられ、これがマッチ率の低さと広告の高速性の背景にあると見ています。（※ 導入サイトが増えることでマッチ率は改善すると思われますが。）
とはいえ、AMP 以外でも S2S はすでに広く利用されているわけで、それだけでは説明できない何かがある気はしています。感覚で申し訳ないのですが、AMP 広告は AMP 以外の S2S よりも速いように思えるため、AMP 広告にはエコシステム全体としての速度優位性がありそうな気はしています。
いずれにせよ、AMP キャッシュまで含めた AMP のエコシステムは、速度・収益性の面だけを見ればかなり良くできています。この部分は、脱 AMP した方にも共感していただける部分なのではないでしょうか。
ただ、今後、サードパーティクッキーからの脱却が進み、最近、ちょくちょく話題に登る non AMP＋SXG でプリフェッチ、といった選択肢も出てきている中、AMP の利点は「遅いサイトを作れないフレームワーク」という部分だけになってくる可能性はあります。
話が逸れました。
ここからは、当サイトが AMP 化するにあたり気をつけたことなどをまとめていきます。
AMP化の事前準備としてSP版テンプレートからJSを削減
サイトの AMP 対応にあたっては、まずは、SP 版テンプレートに含まれる JavaScript の削減から手を付けていきました。
AMP では利用できる JavaScript が厳しく制約されています。既存サイトを AMP HTML へ自動変換をするにしても、まずはトラブルの元となる AMP 非対応な JavaScript を取り除くことが重要です。
最近は LazyLoad もブラウザ側の標準対応が進み HTML だけで書けるようになりましたし、折りたたみメニューやアニメーション系も、多くは CSS だけで現実的に実装できるようになりました。
そもそも、見た目周りなら JS を使わないよう機能削減だってできるわけですから、JavaScript を使わない方向で改修を行ったわけです。
GA のイベントトラッキングやカスタムディメンション など、必要になる計測系 JavaScript については、一部は AMP 側の機能で対応。対応できないものは計測を諦める選択をしました。
これらの下準備により Transitional モードでの AMP HTML への自動変換の精度が上がりましたし、また副次的効果として SP版 の表示速度向上という効果も得られました。
Transitionalモードはかなり優秀。非対応ページは個別の非AMP化も可
公式 AMP プラグインの Transitional モードでは、既存の HTML 版テンプレート、およびコンテンツを自動で AMP HTML へ変換してくれます。
今回、このモードを使ってサイト全体の AMP 化を実現したわけですが、2021年夏現在、この自動変換はかなり優秀になっています。
これが2年前だと、「こりゃ駄目だ」というクオリティだったことをよく覚えていますが、現在では、静的レイアウト情報を持っていない iframe のスペーシングが崩れるくらいで、それ以外で見た目が破綻するケースは（当サイトでは）かなり減ったとの印象です。
この改善の背景には AMP プラグインのアップデートはもちろん、（サイト運営者からの要求を受けて）AMP の仕様が拡張されてきた事も大きそうです。
（※ 余談ですが AMP 推進と WordPress 公式 AMP プラグインの開発には Google が絡んでいます。ここ数年に渡って AMP 界隈をウォッチしてきましたが、その変化の背後には市場の要求や Google の考えなどが透けて見え、ダイナミクスが感じられました。）
当サイトの場合、コンテンツの永続性を意識して記事に使用するタグを絞っている、という事情もありますが、公式 AMP プラグインではエディタから記事単位でAMP対応・非対応を切り替えできるので、問題があるページは思い切って非 AMP 化する、という選択肢も取れました。
Gutenbergブロックエディタの存在理由
穿った見方かもしれませんが、僕は WordPress に Gutenberg が導入された際、「これは AMP 的なものを見据えたアップデートだな」と感じた記憶があります。
Gutenberg ブロックエディタの設計の背後には、「CMS からの出力は HTML だけとは限らない」という思想があるように思えて仕方なく、じゃあ他に何で出力するか、と言えば、これは当時、AMP HTML を差し置いて他になかったわけで。（いや、他にもあったのかもしれないけれども）
AMP ではレンダリング速度の確保を目的に、AMP HTML とそこに記述される CSS だけで各描画要素のサイズを確定できることを求めています。
例えば、その他のリソース読み込みが原則行われる <amp-img> <amp-iframe> タグでは、height / width 属性、つまり静的レイアウト情報が必須とされているわけです。
AMP HTML が必要とする静的レイアウト情報は、HTML からの自動変換時に静的取得できると限りません。ですから、これらの情報を無理なく取得できるよう、また、多様な AMP コンポーネントを見据え、新たに WordPress に Gutenberg ブロックエディタを導入した。当時の僕にはそう見えたわけです。
CMS 世界シェアの60%以上を誇り、世界の Web サイトの40%以上が WordPress によって生成されていると言われる今、Google がわざわざ WordPress 界隈に出張って来た理由、その背後にはきちんと合理性があったのだと僕は理解しています。
なお、現状、Classic エディタで書いた記事であっても公式 AMP プラグインによる自動変換は概ね正しく機能します。
ただ、Gutenberg で書けば、リッチなコンテンツでも AMP 自動変換で問題が発生しずらいため、AMP の導入を前提とするのであれば、Gutenberg で記事を書くことをオススメします。
AMPページのURL形式と、 ページキャッシュ戦略・プラグイン選定
公式 AMP プラグインの Transitional モードでは、AMP ページの URL 形式を ～/amp/ のパスサフィックスか、?amp=1 のクエリストリング付きから選ぶことができます。（レガシーリーダーモードもありますが）
AMP ページの URL は、サイト全体のキャッシュ戦略との兼ね合いや、同一コンテンツを2つの異なるURLから配信する場合のポリシー、といったあたりを考慮の上、サイト運営者が判断しなければなりません。
同一コンテンツを2つの URL から配信する、という歪さを嫌うなら、まずはクエリパラメータ形式を検討すると良いでしょう。この場合、AMP をやめた後、リダイレクトしなくても 404 エラーにならずに済む、という利点もあります。
ただし、トランザクション系サイト等ではクエリストリング付き URL はキャッシュしないポリシーの場合もあるでしょうから、その場合は ～/amp/ のパスサフィックス形式を選択することになるでしょう。
環境によっては、URL Rewrite の都合からもパスサフィックス形式（またはドメイン名を分ける形式）を採用するケースはあるでしょう。この他にも、将来の SXG 対応など、考慮すべき事はそこそこあります。
また、WordPress 向けキャッシュプラグインによっては、クエリストリング付き URL をキャッシュ対象にするとパスのみの URL のページキャッシュと比べてキャッシュシステム全体が低速になる場合がある、というのも注意点です。
URL 構造はインフラ周りや容量設計にも関わってくる部分です。インフラ担当とも相談の上で計画を策定すると良いでしょう。
URL 形式は Google Analytics の設定の煩雑さにも影響します。「?amp=1」のクエリパラメータ形式であれば、新規ビューを作成し、このクエリパラメータを無視する設定を入れれば AMP / 非AMP ページの PV を統合できますが、～/amp/ 形式では、もうちょっと複雑な設定が必要になります。
アイキャッチ画像のサイズ・比率制約は対応が面倒
AMP ではアイキャッチ画像のサイズ規定があります。また、記事ごとに必ず1枚のアイキャッチ画像が必要です。
AMP のアイキャッチ画像の要件は以下のとおりです。
- 幅1200px 以上
- 80万ピクセル以上の解像度
- 16:9、4:3、1:1 のいずれかの縦横比
これに従わない場合、現時点では Google Search Console 上では当該ページについて「警告」判定がなされます。が将来的には「エラー」扱いになり、ペナルティを受ける可能性が無いとは言い切れません。
当サイトは、積極的に過去記事を更新しており、また、過去分のフル解像度画像を保管しているため、基本的は目についたページから順次、手動で張り替えてゆく方針としていました。
AMP広告の高収益性と爆速性
冒頭にも触れたとおり、AMP 広告の収益性は高く、当サイトでは、同期間のSP版比でセッションあたり約25%の収益向上となりました。
これは、あくまでも「セッションあたり」であり、「PVあたり」では実にSP比50%弱もの収益アップでした。
ただし、後述のとおり AMP では直帰率が高くなる傾向があり、また、検索流入の減少分まで考えると、トータルではトントンといったところでした。が、効率だけを切り取って見れば、これは驚くべき成果と言えます。
AMP 導入以前は、特に SP 版 ATF 枠のロードが遅く広告視認率が低い、という課題を抱えていました。その解決のために JS 版 GAM の Single Request を導入したり、Amazon UAM や AdX を貼ったりと色々と足掻きはしたものの、これまでに amp-ad ほどの成果が上がった施策はありません。（ATF のアクティブビュー広告視認率は8.5%も向上しました）
非 AMP の WEB サイトの広告効率アップが見込まれるという AdSense の新コード、あと、GAM・AdX 絡みでも新広告コードの話が出ているようですが（2021年8月現在）、それでどの程度、差が縮まるかは未知数も、AMP 広告の表示の速さは尋常ではありません。
個人的には、bento AMP 的な形で amp-ad コンポーネントを非 AMP でも使えるようになれば、とは思うところですが、ページ全体の高速性があってこその AMP 広告の収益性の高さ、という要因もありそうではあり、なかなか一筋縄では行かなさそうな予感もしなくはありません。
もちろん、広告表示以上にコンテンツ表示も高速化されていますから、速度の面だけで言えばユーザビリティ的にもプラスとなっている部分はあります。
面倒な事を考えなくても高速化される。高速化されるから広告がより長く表示され、よりクリックされるようになる。これが Google が AMP 化を推進した大きな動機であり、わざわざ WordPress 界隈にまで出張って来た大きな理由の1つだったと思われます。
ただし、現在ではこの流れはちょっと変わりつつあり、AMP に拘る必要は無いようにも感じています。
Amazonアソシエイトのiframeタグは売上が上がらない
AMP へ自動変換したページの Amazon アソシエイトの iframe タグは、表示こそされるものの、収益はまったく上がりません。ゼロです（※ 2021年6月時点）。
これでは流石に売上的に厳しいですし、また、コード改変に相当することから Amazon の規約に抵触する可能性があるため、乗り気ではなかったものの、Amazon Advertising API を使う WordPress 用プラグインを新規導入しました。
そのためには、順次、タグを手動で貼り替える必要があり、貼り替え前のページは function.php のカスタマイズにより、一括で非 AMP 化する設定としていました。
AMPキャッシュ由来のユーザビリティの問題が多い（戻るボタン、URL）
僕が AMP を辞めた大きな理由の1つに「AMP ビューワ上で Android の戻るボタンでのページ遷移時、まれに 404 エラーが出る場合がある」という解決できない問題の存在がありました。
これは特に、サイト滞在時間が長く、複数ページを渡り歩いてくれる高ロイヤリティユーザーの使用感に関わる問題であり、かなり重い問題と受け止めました。
iOS + Safari で SNS への共有時、AMP キャッシュの URL が流れてしまう問題もそうですが、技術に明るくないユーザー視点で見たときに不可解な動きが複数ある、というのはやはり、サイト運営者としては相当に気になる部分です。
これらの背景には「AMP キャッシュのトポロジ自体に無理がある」という本質的問題が横たわっており、AMP と AMP キャッシュが Google 検索において不可分とされる限り、根本的には解決されない問題であろうと考えているわけです。（そのまた背後には、AMP 広告の効率の良さと AMP キャッシュが不可分、という構造があるのかもしれず。推測ですが。）
SERPで1行サイトリンクの対象外になるのが痛い
AMP 化すると Google SERP での「1行サイトリンク」や「～に移動リンク」の対象外となります。
この謎仕様、ニュース系サイトであれば問題なさそうですが、当サイトのようなノウハウ系サイトでは検索流入経路の減少に繋がるため、影響が大きい部分。改善してほしい点でした。
AMPリンカーの設定が必要
AMP ではAMPキャッシュと自サーバーという、異なる複数ドメインからコンテンツを配信する形になりますので、Google Analytics のセッションを統一するため、「AMP リンカー」の設定が必要です。
手順は調べればすぐ出てきます。設定自体は簡単です。
AMP-to-AMP linkingをどうするか
AMP ページ内に設置されている自サイトへのリンク先を AMP ページとするか HTML ページとするか、という所謂「AMP-to-AMP linking」の扱いですが、これについては、HTML、つまり、通常ページとしており、そのために公式 AMP プラグインの挙動を変更していました。
ただ、敢えて「AMP-to-AMP linking」を無効化する必要があったか、と言われれば疑問です。
というのも、昔は「AMP キャッシュ上の AMP」→「自サーバ上の AMP」の遷移時には GA のセッションが引き継がれない、と聞いていたのですが、実際に確認したところ、少なくとも2021年8月現在の PC 版 Chrome では、この遷移パターンでも cid が引き継がれており、セッション継続扱いとなることが分かったからです。
僕は保守的なため、コンテンツの真水部分は配信形式に依らず同一のものにしたい、という思いがありました。また、Android + Chrome であれば AMP ビューワの使い心地はそこまで悪くはないものの、iOS + Safari では、例えば共有時に AMP キャッシュの URL を拾ってしまうなどの問題もあるため、今回は「AMP-to-AMP linking」を無効化した、というわけです。（それでも Safari では2ページ目に遷移しない限り AMP キャッシュのURLを拾われるわけですが）
直帰率は上昇、検索流入は低下
AMP 導入後、直帰率が3～5%程度上がったため、ひょっとするとブラウザによってはセッションが引き継がれない場合があるのでは？との疑いは残っています。
というのも、当サイトでは、SP版・AMP版間の見た目の差がほぼ無かったため、AMP キャッシュ・自サーバー間で GA のセッションが正しく引き継がれていないか、速度アップ、また、広告クリック率の上昇以外に、直帰率上昇の大きな要因が考えられなかったからです。
また、この件と関係してか、Google Search Console 上でのサムネイルサイズの警告を無視していたからか、はたまた 6月、7月の Google アップデートの影響からか、検索エンジンからの評価はそこそこ低下。
なんとなーく、AMP は悪者ではない、という線も気もしなくはないですが、個人的には、AMP 化の作業に関連して検索エンジンの評価が変動した印象は拭いきれていません。
WEB広告・WEBコンテンツ配信の未来は思ったより流動的なのかも
といった紆余曲折を経て、当サイトでは最終的に AMP 対応を止めた、という流れになります。
今どきは自作のテーマでなく、配布されているテーマを使っている方が多そうなので、あまりこういった情報需要はなさそうですが。まぁ、自分用メモということで。
AMP HTML は「遅いサイトを作りづらいフレームワーク」としては非常に良くできています。
SERP から一瞬でページが表示されるのは利点ですが、Google は2021年5月、SERP において AMP であることを示す稲妻マークを廃止していますし、また、すでに non AMP＋SXG でも SERP でのプリロードには対応している状況です。
AMP は AMP キャッシュからの配信とセットになることで、解決困難なユーザビリティの問題を抱えている、というのが私の見解です。
そのため、すでに高品質な配信を実現しているサイトにとって、AMPキャッシュの恩恵はトータルでゼロ、あるいはマイナスとなるケースもあるだろうとは思います。
ただ、昨今のサードパーティ Cookie 規制の流れと広告効率の事を考えると、将来、再び AMP キャシュからのコンテンツ配信に脚光が当たるシナリオもあるのかも、とは妄想したりもしつつ。
一方で、最近の Google は非 AMP な WEB 広告の高速化を真剣に模索しているようにも思いますし、未来は思ったよりも流動的なのかもしれません。
いずれにせよ、もし、AMP がその役割を終えてゆくとしても、今回の試行錯誤で得た経験はかなり活かせそうだ、とは感じるところです。