AMP対応
これまでにpukiwikiカスタマイズ箇所/2019で示したように、自分が使用しない多数のプラグインを犠牲にしてでもPukiwikiの徹底的な軽量化と現代化を図ってきたところですが、当サイトのようにpukiwikiをベースにしているが個人で編集するのみで多人数編集を前提としていない場合は、ここまで来るとGoogleが提唱するAMP（Accelerated Mobile Pages）への対応はそれほど難しくないように思われました。
AMPは個人管理のお一人様用wikiに向いている（多人数wikiには向かない）
AMP対応はサイト軽量化などの効果があるほか、AMPそのものにSEOの効果はないものの、サイトが軽くなるとGoogleからの評価も上がり間接的にはSEOに寄与するという話もあります。一方で、多人数で編集するWikiとして使用する場合はキャッシュを効かせて高速化するという恩恵があまりありませんのでAMP対応を目指す意味はあまりないかもしれません。
AMP対応のために実際にすべきのは以下の事項です。これはPukiwikiに限らずAMP一般の話も含んでいます。
AMPの boilerplate とAMPライブラリを記載する（AMPでは必須）
AMPの boilerplateの記載
<style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>
AMPライブラリの読み込み
これを読み込むことでAMP対応に必要なキャッシュを生成するための機能がサイトに付与されます。
<script async src="https://cdn.ampproject.org/v0.js"></script>
なお、このライブラリはasync属性で読み込まなければAMPエラーがでます。
AMP対応には直接は必須ではないのですが、このAMPライブラリが意外にPagespeed Insightのスコアに影響します。高速化のために読み込んだライブラリでサイトのスピード評価が下がっては本末転倒ですが、これはpreloadを使うことでいくらか軽減できます。
<link rel="preload" as="script" href="https://cdn.ampproject.org/v0.js">
下記の一文をHTMLのできるだけ上の方に置いておきます。当サイトでは meta name="viewport" の次の行にこれを配置しています。
canonical URLの記載
AMPページを作った場合はAMPページのもとになるオリジナルページのURLを記載したcanonical URLを記載しておくことが推奨されています。
<link rel="canonical" href="<?php echo get_script_uri() ?>?<?php echo $r_page ?>" />
なお、短縮URLを導入しているpukiwikiではこれの導入時にcanonical URLを記載していると思います。しかし<?php echo $canonical_url ?>は短縮URLを吐き出すので、直感に反しますが短縮URL導入後のpukiwikiでは下記のようにcanonicalの欄にオリジナルURLを記載しつつshorturlの欄に$canonical_urlを記載します。
<link rel="canonical" href="<?php echo get_script_uri() ?>?<?php echo $r_page ?>" />
<link rel="shortlink" href="<?php echo $canonical_url ?>" />
AMPで利用できないHTMLを変更する
これが大変です。特に代表的なものは<img>と<form>で、これらへの対処がPukiwikiのAMP化の最大の難関です。
imgタグのamp-img化
AMPでは<amp-img>はwidthとheightの記載が必須になっていますが、絶対値記載が必要なのでCSSで相対的レイアウト（width:50%やwith:100vw）をしている場合などはレイアウトを再構築する必要があるかもしれません。サイズはスタイルシートでうまく工夫してなんとかしましょう。
個人的にはこのamp-img対応がAMP化の最大の障壁となります。何しろ、スキンだけでなくpukiwikiのプラグインなど至るところにimgタグがあるので…。
amp-imgで必須の画像サイズの絶対値表記のため、個人的に使用頻度の高いrefプラグインではプラグインをテキストエディタで開くと見える設定項目で画像のサイズを取得するという設定を探して、これをTRUEにしておく必要があります。この取得したサイズが$infoに格納されるので、これを350行目付近の画像HTML出力の中に表記されるようにしておく必要があります。
$params['_body'] = "<amp-img src=\"$url\" layout=\"intrinsic\" alt=\"$title\" title=\"$title\" $info></amp-img>";
詳しくはAMP HTML対応の断念のその後の記事を参照してください。
formタグのamp-form化
Pukiwikiの検索ボックスのほかに編集ウインドウ、commentプラグインなど至るところに<form>があるのでこれを全て対応させるのもなかなか大変です。
結論からいうと、これに全て対応させるのは現実的ではない気がします。AMP-formスクリプトはフォームに入力された内容を非同期的に送信するのですが、これをPHPで受け取ってpukiwikiを動かすというのがかなり難しいと思います。
編集ウインドウなど動的なページはAMP化させる必要はありません。当サイトではその場しのぎの対応として、検索フォームはcmd=searchのページとトップページのみに設置してトップページは非AMPとしています。コメントプラグインは使っていないので、コメントプラグインについては深くは追求できていません。
type属性などAMP非対応の属性を変更
AMP化について各種サイトであまり言及されていないのが、type属性が使えないというものです。
これまでdivのCSSを分岐させるために<div class="ogp" type="amp">としてCSSで.ogp[type="amp"]{}というようにtypeで区別するというのを多用していましたが、これはAMP testでは「属性「type」はタグ「div」で使用できません。」と言われてしまいます。
スタイルシートのclassは使えるので、typeを使わずにclassの並列で表記させましょう。上記の例で言えば<div class="ogp amp">として、CSSは.ogp.ampと連続して2つ書けば.ogpかつ.ampの要素のみにこのスタイルが適用されます。
schema.orgのJSON-LDを指定する
これはAMPが登場した当初は必須とされていましたが、現在のAMP対応では必須ではありません。metaタグでdescriptionなどをつかって検索エンジンにサイトの情報を伝えていたようなことと同じこと＋αが実現できますが、必須でないので後回しで良いでしょう。
最後にヘッダの変更
これを記載してHTMLが完全にAMPに対応していれば、GoogleからはAMP化ページとして認識されます。
<html amp lang="ja">
なお、AMP対応が完全にできているかどうかは AMPテストから調べることができます。AMPに対応できていないエラーがあればその箇所が表示されるので、順番に一つづつ潰してゆきます。
全てのページをAMP化しない場合
たとえば編集ページや添付ファイルページはAMP化する必要がありませんし、そのまま置いておくとAMPエラーの警告メールがくるだけでややこしいことになります。また、当サイトはトップページに検索フォームを置いていますが、AMP-formを入れていないのでこのままだとトップページもAMPエラーが出てしまいます。
AMPエラーが出たまま放置していても特に実害はないのですが、Google search formでエラーがいつまでも表示されたままになるのは気持ちの良いものではありません。そこで、これらのページではAMP化しないようにしておきます。<html amp lang="ja">とする代わりに下記の1行を書いておき、FrontPageか$is_readでないページでは<html lang="ja">と表示してAMPと認識されないようにしておきます。もちろん画像遅延読み込みなどのjavascriptとしてのAMPライブラリは問題なく動作します。
<html <?php ( $title != 'FrontPage' && $is_read ) ? print 'amp ' : print '' ; ?>lang="ja">
AMP対応は不完全でも無駄ではない
AMP対応は不完全でも無駄ではありません。むしろAMPライブラリを部分的に使用する方がコストパフォーマンスに優れるかもしれません。
AMPライブラリはAMPキャッシュを作成するためだけでなく、サイトを軽量に作成するためのjavascriptとしてもかなり優秀です。普通であればjQueryなどを用いなければ実装しにくい画像の遅延読み込み、画像のフェードインやスライドインなども、AMPライブラリとamp-imgを使用すれば簡単に実装できるのです。
もしサイトが完全にはAMP対応できていない場合も部分的なAMPライブラリの利用は可能であり、これはサイトの高速化に寄与します。完全にAMP対応できない場合はヘッダの変更だけせずに可能な範囲で部分的にAMP HTMLを使うという方法もあります。AMPスクリプトを使ったサイトが結果的にAMPエラーを全て修正できなくてAMPキャッシュが作成できなくても、非AMPページとしてそのスクリプトはちゃんと動作するからです。
不完全AMP対応で済ませる場合のAMP-boilerplate
完全にAMP化を目指すのでない場合はAMP-boilerplateを読むかどうかは各サイトの判断に任されます。これを読み込まなかったとしてもエラーにはならないようです。ただし、これまでの経験から言うとAMP HTMLによる高速化はAMP-boilerplateによってAMP jsが読み込み完了するまで画面を非表示にする遅延読み込みが働いている面もあるので、AMP-boilerplateを読み込みさせておくほうがpagespeed insightのFCP（First Contentful Paint）も改善する傾向があるようです。
AMP対応断念と再開の経緯
2019年9月に当サイトのPukiwikiのAMP HTML対応に向けて様々な試みをしたが、CSSで描いたページレイアウトの崩れを避けられないことと、GoogleのAMPキャッシュでは動的なモジュールが予想外の挙動を示すことなどから、一時はAMP対応を断念しました。しかしその後にハンバーガーメニューの改良などを経て、再びAMP化の作業を始めてAMP対応を果たしました。
pukiwikiのAMP対応関連記事
この記事に対するコメント
このページには、まだコメントはありません。
更新日：2020-05-06 閲覧数：1444 views.