レ点腫瘍学ノート

Top / pukiwikiカスタマイズ箇所

AMP対応

78d3e6b858.png

これまでに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対応の断念のその後の記事を参照してください。

AMP対応を断念していた経緯 2019年夏頃にpukiwikiベースで作成したこのサイトをAMPに対応させようとしたが、CSS3を利用したハンバーガーメニュー(スライドメニュー)がAMP環境では正しく表示できず、AMP対応を断念していた。また、AMP下で用いるフォームに使用するamp-formではpostメソッドを使うことができず、検索

formタグのamp-form化

Pukiwikiの検索ボックスのほかに編集ウインドウ、commentプラグインなど至るところに<form>があるのでこれを全て対応させるのもなかなか大変です。

結論からいうと、これに全て対応させるのは現実的ではない気がします。AMP-formスクリプトはフォームに入力された内容を非同期的に送信するのですが、これをPHPで受け取ってpukiwikiを動かすというのがかなり難しいと思います。

編集ウインドウなど動的なページはAMP化させる必要はありません。当サイトではその場しのぎの対応として、検索フォームはcmd=searchのページとトップページのみに設置してトップページは非AMPとしています。コメントプラグインは使っていないので、コメントプラグインについては深くは追求できていません。

type属性などAMP非対応の属性を変更

78d3e6b858-type.png

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などをつかって検索エンジンにサイトの情報を伝えていたようなことと同じこと+αが実現できますが、必須でないので後回しで良いでしょう。

SEO対策にどれほど貢献するのかは不明ですが、検索エンジンで当サイトで記事を書いているキーワードがあったときに表示されやすくなればと思い、pukiwikiカスタマイズ箇所/2020の一環としてJSON-LDへの対応を行いました。schema.orgの中ではJSON-LDが使いやすい JSON-LD以外にもschema.orgに対応して

最後にヘッダの変更

これを記載して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ページとしてそのスクリプトはちゃんと動作するからです。

See related links to what you are looking for.
https://fwww.me/2018/06/07/img-to-amp-img/

不完全AMP対応で済ませる場合のAMP-boilerplate

完全にAMP化を目指すのでない場合はAMP-boilerplateを読むかどうかは各サイトの判断に任されます。これを読み込まなかったとしてもエラーにはならないようです。ただし、これまでの経験から言うとAMP HTMLによる高速化はAMP-boilerplateによってAMP jsが読み込み完了するまで画面を非表示にする遅延読み込みが働いている面もあるので、AMP-boilerplateを読み込みさせておくほうがpagespeed insightのFCP(First Contentful Paint)も改善する傾向があるようです。

AMP Boilerplate Code
head > style[amp-boilerplate] and noscript > style[amp-boilerplate]
https://amp.dev/ja/documentation/guides-and-tutorials/learn/spec/amp-boilerplate/

AMP対応断念と再開の経緯

2019年9月に当サイトのPukiwikiのAMP HTML対応に向けて様々な試みをしたが、CSSで描いたページレイアウトの崩れを避けられないことと、GoogleのAMPキャッシュでは動的なモジュールが予想外の挙動を示すことなどから、一時はAMP対応を断念しました。しかしその後にハンバーガーメニューの改良などを経て、再びAMP化の作業を始めてAMP対応を果たしました。

様々な試みをしてきてAMP化されたページがGoogleの検索結果に表示されるにいたったが、ここでまた新たな問題が生じた。pukiwikiカスタマイズ箇所/2019で書いていたハンバーガーメニューがAMP化されたページではうまく作動しない。どうもAMP化されたページにGoogleから到達した場合はページのトップにGoogleのタイトルバー
AMP対応を断念していた経緯 2019年夏頃にpukiwikiベースで作成したこのサイトをAMPに対応させようとしたが、CSS3を利用したハンバーガーメニュー(スライドメニュー)がAMP環境では正しく表示できず、AMP対応を断念していた。また、AMP下で用いるフォームに使用するamp-formではpostメソッドを使うことができず、検索

pukiwikiのAMP対応関連記事

AMP化したページではGoogle analyticsの実装がしにくいのですが、AMP用のanalyticsスクリプトも用意されています。当サイトはほぼ全ページがAMP HTML対応の構造になっていますのでAMPページと非AMPページでわけずにすべてのページでAMP用のanalyticsスクリプトを用いています(AMP用スクリプトは非AM
このサイトは個人のメモ書きという要素が強かったのでSNSでのシェアのしやすさはそれほど意識していなかったのと、ウェブサイトが重くならないように極力シンプルな構成を目指していましたが、AMP用スクリプトはいずれもウェブサイトの重さに極力影響を与えずに様々な機能が実装できることがわかってきたので、SNSでのシェアを容易にするためのAMP-so
AMP-Twitterプラグイン pukiwikiをAMP対応するとtweet_incプラグインを使うとAMPエラーが出るので、AMP化したpukiwiki でもTwitterからツイートを引用できるように、AMP-twitterスクリプトに対応するプラグインを作成しました。なお、描画に少し時間がかかるのが課題です。低速回線では読
AMPのsidebarでamp-imgの画像が出ないときの対処法 amp-imgの画像はスクロールして表示範囲に近づいたときに読み込みが起こる遅延ローディング機能を備えているのですが、サイドバーに含まれている画像は上下スクロールを伴わないために表示範囲に入っても表示されないという問題がありました。AMP-sidebarを使うとき

この記事に対するコメント

このページには、まだコメントはありません。

お名前:

更新日:2020-05-06 閲覧数:1441 views.