最近でもないけど、スマホでGoogleの検索結果を見てると雷マーク（AMP対応している記事）をよく見るようになってきた。
そういう案件も来るかもだし、AMP対応くらいできるようになっとこうと思って、まあ、失敗してもいいのでこのブログで試してみることにした。
こういうやつ。ページ読み込みが早い。
結果としてはAMP対応できたんだけど、このブログでのメリットとデメリットを比べた時に、ちょっとAMP対応の恩恵が弱かったので、結局元に戻すことに。
でも色々勉強になってよかった。
ちなみにたまに「AMP対応するとデザインがシンプルになっちゃう」ってデメリットを見るけど、それはWordPressのプラグインで対応しているような場合だと思う。
（かなり）頑張れば元ページのデザインの再現は相当高いレベルでできますよ。
AMP対応は万能じゃない
まあ、当たり前なんですけどね。AMP(Accelerated Mobile Pages)の名前が示すとおり、ページ速度を早めるための仕組みなので犠牲にしてることもあるし、管理が煩雑になったりする。
対応の難しさ
これは「元となるサイトの構造、デザイン、それをどこまで再現するか」で大幅に変わりそう。
元となるサイトのソースを流用できるパーツがほぼなくAMP用に書き直す必要があるからだ。
例えば本サイトみたいなWordPressで構築された「THE、ブログ！」みたいなサイトをAMP対応してみるとする。
段階1：記事部分をAMP対応する
AMPページは記事内容だけ見られればいいって場合は、比較的簡単に対応できる。が、それだと回遊性が著しく下がるので、できれば関連記事とか、グローバルメニューとかも対応させたいところ。
段階2：ヘッダー（とフッター）をAMP対応する
サイトの顔になるヘッダーは対応必須項目に近い。モバイルフレンドリーに作られているサイトなら、グローバルメニューはハンバーガーメニュー等を採用していることもあると思うが、当然これはそのまま使えない。
まず、AMPで許可されているJS以外を使うことができない。
AMP用に用意されている「amp-sidebar」を使用するのが現実的だけど、特殊なタグを利用するのでwp_nav_menu()で素直に吐き出されるソースは使えない。
かと言ってソースベタ打ちなんて非効率なこともやってられないので、メニュー出力用のシステムを書く必要がある。
※一応、AMP開発チームは任意のJSを動かせるように努力しているらしい。裏を返せばまだ発展途上で、導入をためらわせる記事とも言える。
好きなJavaScriptをAMPで実行できるようになるかも。Web Workerで実現か？
段階3：SNSシェア、関連記事、コメント等
AMPではフォームが使えないので、コメント機能をどうしても使いたいなら「Disqus」で実現できるらしい。
SNSシェアもAMP専用の仕組みがあり、対応しているサービスも限られている。
関連記事もimgタグを使っている場合はそれ用のシステムを書く。。
段階4：ウィジェットエリア
もはや以下同文って書きたくらいだけど、ウィジェットエリアのソースは容易に編集できず、検索機能も使えないのでそれ用に書く。
システムゴリゴリかける人だったら、フックとか使って書き換えた方がいいのかも；。
デザインの反映：CSSの制限がつらい
AMPではCSSファイルを読み込むことができる。
もし元となるサイトに使用されているCSSファイルがAMPの要件を満たしているならば、そのファイルをAMP用に読み込めばいい。
が、実際は
- 容量は50KB以下
- !importantは使用不可
- :notも使用不可
等々の制約があって、元のCSSをそのまま使えるってケースは極めて希だと思われる。
このブログではAMP対応をしないことにした
ページ速度は魅力的だったけど、対応箇所を増やすほど、多元管理になって修正の手間が増えるのがすごく嫌。
色を少し変えたり、広告を差し替えたりメニューを追加するだけで、AMP対応してない状態であれば1箇所いじって軽くチェックして終わりなところを、AMP用のファイルも書き換えて、実機でもテストしなければならない。。
って考えるとそこまでページ速度大事かなーっていうのが正直な感想。
AMP対応後のこのサイトの読み込み速度も、自分の環境だとあんまり実感できなかった。
コメント、シェア機能の制限もあるし、なにより、まだAMPが発展途上で、もう少し安定して機能も充実してからの方がいいかなって思って、今回はAMP対応を見送ることにした。
でも、曖昧だったAMPのことを知れたのはよかった。やっぱり何事もやってみることですな。
もし誰かが望むなら、WordPressでプラグインなしで記事ページだけAMP対応させるやり方でも書こうかな。
では、よいAMPライフを。
