PSI; PageSpeed Insights
- ホームページの表示速度をスコア化してくれるツール
- PageSpeed Insightsで、サイトのアドレスを入力するとサイトのスピードを測ってくれる
- モバイル端末とPCに分けて評価される
- モバイル端末の評価では,ホームページにAMPを導入しているとスコアが高くなる
編集履歴
2022/09/04, Mr. Harikiri
編集履歴
2022/09/04, Mr. Harikiri
AMPプラグインをインストールしている場合、投稿/ページを公開/更新した際に、AMPの検証/再検証が行われます。サイト毎に使用されているプラグインがAMPに沿ったコードを作るわけでは無いため、AMPの仕様に沿わない場合があります。その結果として、「makeupエラー」や「スクリプトエラー」などがアラートされる訳です。これらのエラーは、AMPにおいてなるべく出なくすることが良いと考えます。そのエラーとなったコードを削除した場合にどうなるのかは、表示させたりしてその結果を確認しないと分かりません。
以下の情報は、AMPプラグインを使用している前提で、その他のブラグインの使用として、エラーが出ないように工夫してきた、知識情報です。
あるプラグインを使用する場合、使用していもエラーが出ないもの、使用すると前述のようなエラーが出るものなど、基本的にやってみないと分からないものばかりです。
機能を充実したり、見栄えを良くしたりするために、色々なプラグインを使用することは、速度の制約となるという、トレードオフの関係にあります。その規律(ルール)となっているのが、AMPプラグインです。AMPプラグインは、速度の制約となるものをエラーとして知らせます。エラーとならない使い方、すなわち、機能の有効化/無効化が、AMPプラグインで設定が可能です。
AMPエラーが出たとしても、そのプラグインを使用したい場合は、AMPページでの、そのプラグインの使用を無効化することで、AMPに非対応にできます。この最終手段により、そのプラグインを使用できます。
以下は、そのプラグインを使用して、且つ、AMP対応にしたい使い方について、プラグイン別に示しました。
現在は、以下、1つのプラグインのみです。
以上
編集履歴 2020/11/16 Mr.Harikiri 2020/12/11、追記 (基本的な設定方法) 2021/09/13,AMPの制限について追記
ID22640
このblogは、レンタル・サーバーではなくSynology NASを使っています。やはり、性能的にはレンタル・サーバーに勝てません。そこで、自宅のNASを使ったblogでは、以下のような工夫が必要になってきます。
この記事では、ページのレスポンスを向上させる2つのプラグインとして、「AMP」と「キャッシュ」・プラグインを組み合わせてについて解説しています。以前は、AMP対応をせずにページレスポンスの改善を目指していたので、AMPプラグインを使用せず、Autoptimizeプラグインを使用していました。現在では、AMP対応にしてページのレスポンスの改善を図っています。
ついでに、AMPプラグインで何度も生じている「検証済み」の問題についても経験談を載せています。
これらのページレスポンスの向上プラグインなどのSoftwareの適用以前に、ネットワーク回線やHardwareスペックアップの問題もありますが、ここでは述べていません。
AMPプラグインは、HTMLを高速化するために元のHTML文やJavaScriptなどをサブセットに変換します。それがblogのページになります。投稿/ページの編集を終えて、「公開」すると、このタイミングでAMP化の変換が行われます。変換時間は、AMP化を適用していない場合と比較して、5~10秒程度余分の時間を要します。変換時間を要しただけのレスポンス改善は、目を見張ります。当サイトでは、モバイルの場合、GoogleのSpeedPage Insightsを使って測定すると、5~10倍のポイントアップが見られました。それでも、当サイトのMobileで閲覧した場合、30~40%でした。100%が最高値なのでまだまだです。PCでは、80%程度です。
更にレスポンス改善するには、「キャッシャ」プラグインを追加します。そうすると、Mobileでは、50~60%に改善されました。キャッシュ・プラグインには、WP Super Cacheプラグイン、WP-Optimizeプラグインがありますが、主に、WP-Optimizeを使っています。
今回の記事では、WP Super Cacheにするメリットについて解説します。
キャッシュプラグインにも種々ありますが、これまでに色々試しました。その結果、ここ半年間使用し続けたのは、「WP-Optimize」プラグインでした。WP-Optimzieでは、データベースの最適化やデータベース・テーブルがアントールされているテーブルなのか、無効化されているプラグインのデータベース・テーブルなのか、すでに削除されているプラグインに関するデータベース・テーブルなのか、を示してくれます。この情報を確認しながら、データベース・テーブルを削除したり管理することができます。WP-Optimizeは、データベース管理プラグインであると認識するのが妥当です。WP-Optimizeは、キャッシュ機能もありますが、これまでに試したキャッシュ・プラグインの中で僅差ですが、最もレスポンス改善効果があったため、今回まで、キャッシュ機能も有効にしていました。
WP-Optimizeプラグインには、多数の機能が搭載されています。キャッシュ機能には「プリロード」機能も使えます。全ての投稿/ページのキャッシュする機能です。
今回、WP-Super Cacheプラグインをネットで発見して、キャッシュ・プラグインとして使用することにしました。その理由は、プラグインは多機能でない方が管理がし易いと考えているからです。それに、付属的な機能では、微調整ができないことが大です。WP-Optimizeのプリロード機能では、繰り返すプリロードの時間設定しかできず微調整ができません。もう少しでも攻め込みたい。やはり、専用機能に特化したプラグインを指向したいと思います。
ただし、ネットで調べてみると、WP Super Cacheのプリロード機能、その他の機能は使用しないことを推奨しているようです。WP-Optimizeのブリロード機能を使用しても、キャッシュ機能が効いていないようです。と言うのは、WP-Optimizeでブリロードした後に、PageSpeed Insightsでランダムにベージ/投稿を選んで測定したところ、モバイルで50程度、PCで80程度とPCの測定値が低くなりました。間髪入れず、もう一度測定すると、モバイル50程度、PCで95程度と改善しました。何度やってもこの傾向は、どのページでも同様でした。
結論としては、WP-OptimizeもWP Super Cacheも、プリロード機能は、使用しない方が良いということです。
結局推奨設定は、以下の図の通りになります。プリロードの使用を推奨していないのは残念です。
上記推奨設定のサイト
https://translate.google.co.jp/translate?hl=ja&sl=en&u=https://support.tigertech.net/wp-super-cache&prev=search&pto=aue
WP Super Cacheプラグイは、プラグインのキャッシュ/ブリロードに特化しています。多数の設定項目があり微調整も可能です。初心者には優しくて、デフォルトの設定についての解説もわかりやすいです。プリロードのキャッシュファイルの圧縮の設定もできます。
繰り返すプリロードの時間の設定は、ももちろん可能です。初期値は600分です。プリロード処理が開始される時、及び100や200毎に、メールを飛ばす機能もあります。機能していることが分かるので安心ですし管理に役立っています。
今回、WP Super Cacheの試用を開始しましたが、これまで使用していたWP-Optimizeの設定は、キャッシュを無効化し、データベース管理機能のみを使用している状態に設定しました。
SpeedPage Insightsによるレスポンスの測定結果は、従前の設定の場合と比較して同等の結果でした。しばらく攻め込んでみたいと思います。結果は、随時、追記していきます。
WP-Optimizeは、キャッシュ機能だけではなく、データベース管理、イメージ圧縮などの複数の機能を備えています。
kinstaというレンタルサーバーがあります。日々、パフォーマンス改善を進めていて、WP Rocketによるキャッシュ機能に関する記事がありました。その記事では、プリロード機能は、逆にパフォーマンス低下になるので、有効化しないことを推奨しています。プリロード機能は、理想としては良い機能なのですが、実際には、技術として実用化はまだのようです。
Kinsta and WP Rocket: Now Speeding up WordPress Together, 2020/10
https://translate.google.co.jp/translate?hl=ja&sl=en&u=https://kinsta.com/blog/wp-rocket/&prev=search&pto=aue
約900ある投稿とページをプリロードする時間を比較しました。先ず、全ての投稿とページについて、AMPで再検証します。全てが完了してから、ブリロード機能を実行しました。その結果、WP Super Cahceでは約50分、WP-Optimizeでは約25分でした。WP-Optimizeの方が高速でした。
AMPプラグインを使用していて、数ヶ月前の9/21に投稿/ページの「再検証」が、以下のエラーログと共に不可になっていました。
ネットで調べてみましたが、DNSが悪いので、ローカルにDNSを立ち上げろとか、AMPのサポートでは、AMPプラグインによる不具合ではないとか、結局、原因を見つけることは、できずにいました。
WP Super Cacheを導入後、blogのフォルダーにパーミッション設定がおかしいので修正するように、というようなワーニングが出ました。そこで、NASにログインして、chmodコマンドで、そのフォルダーのパーミッションを設定して確認をしている時に、それは起きました。
WordPressの管理者画面の左のメニューが、突然シンプルになりました。原因は、プラグインの全てが無効になっていた事でした。パーミッションの設定を間違えたことで、WordPressがプラグインにアクセスできなくなり、それを受けてWordPressが全てのプラグインを無効化したものと考えられました。
パーミッションを元に戻して、プラグインが認識されるようにしました。無効化になっているプラグインの全てを1つ1つ有効化していきました。
AMPプラグインで不可であった「再検証」が問題なく機能するようになっていました。これまでは、なんだったのか?
再検証を完了した後は、WP Super Cacheによる「ブリロード」を実行しました。
Advanced Adsは、AMPページ対応の広告表示プラグインです。色々な設定が可能です。これらの表示について、実際の投稿/ページを表示させて確認しました。
今回は、AMPプラグイン導入していることを前提に、キャッシュ・プラグインの変更について解説しました。また、相変わらず、AMPプラグインにおける「検証済み」において検証ができない記事があります。また、リストにすら表示されない問題もあります。その問題となる要因は、画像数が多かったり、記事が大きかったり、など色々と考えられます。一方で、シンプルな文字のみの投稿、文書量が少ない、埋め込みリンクがない場合には、ほとんどは問題が生じることはありません。マシンのパワー不足があるのかもしれません。今後も検討を続けます。
以上
2020/11/07、はりきり(Mr) 2020/11/15、追記 (プルロード機能は使えない) 2020/12/11、追記 (文言整備)
ID22520
AMPページに対応すべく奮闘しています。当サイトで記事にしたAMP関連と情報リンクをまとめました。AMPプラグインはVer. 2.2.0になりました。プラグインをアップデートした際、またもや、「検証済みURL」での投稿の非表示の問題が出ました。対応策を見つけて何とか全ての投稿ページを検証済みURLのリストに登録させることができました(直近の対応)。
Google Search ConsoleのAMP項目に、「エラー」、「有効(警告あり)」および「有効」があります。有効(警告あり)では、画像の大きさ関連のものが多く、推奨サイズを使うようにコメントが出ていることがあります。そのような場合には、投稿のアイキャッチ画像のサイズが小さいことが考えられます。当サイトでは、画像の最適化には「EWWW Image Optimizer」プラグインを使用していますが、画像のアップロード時にリサイズする設定において、推奨サイズ以下のサイズに設定されていることがあるので確認してみます。サイズが1200 x 675を推奨しているようなので、これより大きいサイズを設定し直します(例えば、2000 x 2000)。
すでにWordPressにアップロードした画像を大きいサイズにリサイズすることはできないので、改めて同じ画像を元サイズを大きくするか、多いサイズが既にあれば、それをWordPressにアップロードして、更に、アイキャッチ画面に設定しなおしなす。
AMPプラグインが正常に動かないことが多々あります。未だに完全解説には至っていませんが、以下の記録を続けてその内完全な解決策を見出せることを願いつつ、活動を続けていきたいと思います。
おそらくは、AMPプラグインとその他使用しているプラグインとの相性の問題があると考えています。
AMPプラグインのバージョンは、初期のバージョンアップの頻度からすると、現在は、その頻度は低くなっています、また、バージョンもだいぶ上がっています。また、使用経験も積み重ねているものの、このAMPプラグインについては、まだまだ挙動が読めません。まだまだ開発途上ということですね。
投稿は存在しているのに、AMPの更新済みURLが作成されていなと、AMPプラグインの関連するページの各種操作において、タイムエラーなどを起こす。また、更新済みURLが作成されていないことは気持ちが悪いなどのデメリットがある。
AMP: a well-lit path to optimizing for Google’s page experience signal
https://blog.amp.dev/2020/05/28/amp-page-experience/?utm_source=amp_newsletter&utm_medium=email&utm_campaign=amp_highlights_20126252
AMPページに対応するプラグインは、このリンクにリストされています。
「CoBlocks」には、アコーディオン・ブロックがあるので、助かっています。
https://amp-wp.org/ecosystem/plugins/
自宅のblog Serverを2台目として購入したDS920+に移行した時に、AMPの検証済みリストが出なくなってしまいました。データベースから消えたのか、データベースには存在するが、何らかの問題がありリスト化できないのか、理由はわかりません。
以前に、再検証済みのリストを表示されるようにできた経験があります。その方法は、作業中の不手際でフォルダのアクセス権の設定(777とか664とかの設定)でミスした結果、全てのプラグインの無効化が生じた時です。その後、レスキュー作業で全てのプラグインの有効化を行なったことで解決した過去の経験です。具体的には、「WP Super Cache」プラグインを導入後、blogのフォルダーにパーミッション設定がおかしいので修正するように、というようなワーニングが出ました。そこで、NASにログインして、chmodコマンドで、そのフォルダーのパーミッションを設定して確認をしている時に、それは起きました。
現在、過去の記事については、AMPの検証済みリストとして全く表示されないものの、新規に作った投稿では、AMPの検証済みリストに現れます。このことを利用して、投稿を一つ一つ開いて「更新」することで、AMPの検証済みリストに現れるようにできます。この作業は結構骨が折れます(2021/10/10 by MR.HARIKIR)。
結局、一つ一つ投稿を開いては更新する作業を850行いました。完全な力技で対応してしまいました。本当は、こんなことはしたくはなかったのですが、他に解決策を見つけられず仕方くな実施しました(2021/11/05)。
まだ、「検証済みURL」の問題は続いています。いっそのこと、有償版がある「AMP for WP」に乗り換えようとインストールして評価してみましたが、Free版では少しも速度アップは確認できませんでした。評価は、Page Speed Insightsを使用しています。
対策(2022/01/05): 「検証済みURL」が作成されない場合、
(1)AMPのデータベースが壊れている可能性があるので、「忘れる」処理をした後、投稿のページで更新する。
(2)直近のプラグインの更新により「検証済みURL」が消えてしまいました。AMPデータベースが壊れた可能性/仕様の変更があります。実施した対応は、以下の通りです。キャッシュプラグインの少なともデータベースを無効にしてから、投稿ページを一つずつ開く操作を実施すると「検証済みURL」にリストされことを確認できたので全ての投稿ページに実施することにしました。素早く操作するには以下の方法が可能です。「投稿一覧」から一つずつ開き、その投稿の編集ページが開いたら直ぐにブラウザの戻るボタンで「投稿一覧」に戻るを繰り返して、一つ一つの投稿ページを開く処理する方法をとることです。連続操作できる数はNASの処理能力に依存します。投稿ページが開く速度が低下してきたら(5秒以上)、一旦休止してください。因みに、AMP関連のデータベースは、AMPプラグインの削除で削除されない仕様であることは開発者の間では知られていますが、その改善対応は未だ不十分の状況のようです。そのような状況下、プラグインのアップデートにより挙動の変化が毎回起こっています。まあ、ユーザーの立場で追従するのは大変です^^)。
AMP対応にすると3つのURLができます。以下の参考文献に詳しく書かれています。
AMP URLの正体
https://developers-jp.googleblog.com/2017/02/whats-in-amp-url.html
2020/09/13 はりきり(Mr) 2020/12/13 Mr.Harikiri 2021/02/11 追記 (Google Search Consoleのエラーや警告に対応する方法) 2021/10/10,追記(AMP 検証済みリストが表示されない場合のとりあえずの対処法を「その他、問題解決」に記載) 2021/11/05,追記(検証済みリストにリストさせるために、一つづつ記事を更新する作業を実施) 2022/01/05,追記(AMPプラグインVer.2.20での「検証済みURL」の問題に対する対応策)
ID22353
現在、皆さんが、このサイトに来て見てみいるページ表示に関わるWordPressテーマ、およびプラグインのリストを公開します。これからWordPressでサイトの構築をされる方の参考になれば幸いです。
以上
編集履歴 2020/07/11 Mr.HARIKIRI 2020/12/15、現状にupdate
Advanced Adsプラグインは、Google Adsenseの対応に注力しているドイツ製のプラグインです。
今回は、Advanced Adsのホームページを元に応用できる機能について紹介します。
専用のプラグインを使わなくても、Advanced Ads(有料版)を使用しているなら、その機能の応用でコードをどこにでも挿入することも可能です。
Advanced Adsで選べる「広告タイプ」は、7種類あります。
今回紹介する内容は、「プレーンテキストとコード」を選択して「広告」を作り、Header/Footer部にコードとして「配置」を作れば、Header/Footer部にそのコードを自動的に挿入させることが可能です。
もちろん、広告としてつくることもできますが、今回想定しているのは、以下のようなネットワークから指示されてコードをHeader/Footerに挿入する場合です。
先ず、広告を「プレーンテキストとコード」を選択して作り、配置を「Header」として作る。
以上で、自動的にHeader部にコードが挿入されます。
<head>..</head>への挿入は、プラグインを使用すれば可能ですが、Advance Ads(有料版)を使用している場合は、そのような挿入プラグインを無効化して、Advance Adsにまとめることが可能です。それによって、サイトはシンプルになり、プラグイン同士のコンフリクトも少なくなり安定性も向上します。
以上
2020/05/03 はりきり(Mr)
ID14027
当サイトは、試験的及び備忘記録として記録した内容は非表示にするために、Ultimate Memberプラグインを試験的に導入しています。
よろしければ、「いたずら」してみて下さい。使い勝手などがわかると思います。どれだけの堅牢性(ロバストネス)があるか知りたいと思っているので、ぜひどうぞ。「ユーザー」> 「新規登録」です.
ロバストネスの確認、及び対策の強化には、以下の2つのプラグインを導入しています。これは、SiteGuard WPは、定番のようなので、極力導入してはいかがでしょうか。
よく海外からの「ヒヤカシ」があります。ユーザー登録はしていただけるのですが、その登録したe-mailに対して、自動で送られてくるリンク付きのe-mailの処理をしてくれません。
そのリンクをクリックすれば、登録したe-mailは実在すると判断できるし、且つロボットではないことを、おおよそ判断できるので、登録が完了するという仕組みです。
ご自身により登録した後に、登録の削除もできます。
WordPressのユーザー管理画面を見れば、メール一覧から、ステータスが確認できます。もしも、登録しようとしたユーザーが、自動で送られてくるUltimate Memberプラグインからの確認メール、すなわち、そこに記載のリンクをクリックしていない限り、「メールアドレスの確認待ち中」と表示されています。メールの確認が完了すれば、WordPressのユーザーの管理画面には、そのユーザーは「承認済み」と表示されます。以上、これらの挙動は、Ultimate Member -> 設定 -> Emailから設定します。
Ultimate Memberは、AMPページでは、エラー/ワーニングが出てしまいます。念のため、Ultimate Memberを機能させたい投稿/ページは、AMPを適用せず、更に、AMPプラグインの設定で、機能を無効化に設定しています。
Ultimate Memberプラグインは、登録したユーザーに「権限グループ」を設定し、権限グループ毎に、表示/非表示の区分について投稿全体や投稿内のブロック毎(Gutenberg使用の場合)に制限をかけ、ユーザー毎にサービスを差別化するプラグインです。
ユーザー登録して、そのユーザーの設定として例えば「Family」としたとします。次に投稿のブロックまたは、投稿全体に対して、制限(Restrict)のスライドボタンで設定して、Familyを指定すれば、Family設定のユーザーにしか見れないブロックまたは投稿を作成できます。これにより、クローズドなメンバーシップが可能です。
Ultimate Member – reCAPTCHAは、WordPress標準のログイン画面に上書きできない、又は、標準ログイン画面を無効化できないため、以下の事例のようにコンフリクトを起こします。
WordPressの標準ログイン画面を使用せず,Ultimate Memberのログインに集約します.且つ,reCAPTCHAも専用のUltimate Member – reCAPTCHを使用することで,セキュリティを保ちます.
このコンフリクト(エラー)は、2020/02現在で調べた限り、2017年から報告されています。
以下、対策方法も記載しているので、Ultimate memberを使う場合、合わせて設定して下さい。
AMP pluginを使用しいて、且つ、ultimate memberのloginページをAMPに適用している場合に、ultimate memberのlogin画面からログインした時、エラーが出て、ログインができない状態に陥ることがあります。AMPページの内容が古かったり、その他の理由があるようです。これを復旧するには、ultimate memberのloginページを、編集画面から更新する必要があります。その際、「AMPの有効化」が有効になっているはずなので、外しておけば、今後の対策になります。
以上の作業を行うには、先ずは、WordPressにログインしないといけませんが、WordPress標準のlogin画面を有効(復旧)にする必要です。WordPressのシステムファイルが置かれている「システム」に入って(または、WebDAVなどのファイルの名前が変えられるツールでも良い)、以下のように復旧させます。
編集履歴 2020/05/14 追記 (RedirectプラグインによるURLの無効化) 2020/10/24 追記 (UMのLogin画面が使用できなくなった場合にWordPress標準のLogin画面を有効にする方法)
Ultimate Memberは,メンバーシップを構築できます.自分専用のページは勿論,ページの中のあるブロックだけでも設定が可能です.このプラグインの基本は,Login管理な訳です.
しかし,そのLoginのセキュリティを高めるreCAPTCHAが,Ultimate Member専用のUltimate Member – reCAPTCHAと,WordPress専用のreCAPTCHAがコンフリクトします.ログイン画面毎のreCAPTCHAがあれば問題は解決しそうですが,そのようなプラグインは,今のところ見つけられていません.
現状での対策として,Ultimate Member -reCAPTCHAに集約することにしました.
「ダッシュボード -> Ultimate Member -> 設定 -> 一般」で表示されるように、Ultimate Memberプラグインを導入すると7つの専用ページが予め作られます。
まずは、新規登録pageでユーザーが登録を申請してきます。その後承認されると、ログインpageが使用されます。
Ultimate Memberの基本は、見せる/見せない、の設定にあります。ページ全体、ページの任意のブロックに設定できます
サイトに新規登録して、サイトのユーザーとなり、IDとPWでログインし、与えられている「権限グループ」に応じて、制限されているページの閲覧やブロックの閲覧が可能になります。
Gutenbergエディタでブロックを編集している際(下図)、右に表示される「UM access Controls」をONにすると、以下の設定が可能になります。
Logged in Userで、リストを選択すると、以下の設定が可能になります。
その他、必要となるプラグインについては、関連記事を参照ください。
以下の図のように、「ダッシュボード -> Ultimate Member -> 設定 -> アクセス」は、初期値で誰でも閲覧できるように設定されています。
その下の、「Restricted Access Message」は、Classic Editor用の代替メッセージです。制限がかかったページ又はブロックの代わりに表示されます。
以下の図では、Gutenbergエディタで使用する場合にチェックを入れてす。
制限がかかったページやブロックを表示する際、「Restricted Block Mesage」に、代わりに表示するメッセージを入力しておきます。
html文を使うことはできるので、「新規登録のページ」にユーザーを誘導するアンカー文(<a href=“xxx”> ◯◯◯ </a>)をコーディングしたいのですが、現在(2020/02/15)、アンカー文の絶対アドレスが、正常に機能しません。
Gutenbergエディタを使用していれば、エディット領域の下にスクロールしていくと、以下の図のように「Restrict access to this contents?」とあるので、これにチェックを入れれば、このページに制限をかけられます。
PageやPostの中で、あるブロックのみをログインしていないユーザーには見えなくすることもできます。
そうしたい場合、そのブロックの種類によっては、制御が効かない場合があります。
そのような場合は、gutenbergの標準のブロック(例えば”段落”)を挿入して、その段落ブロックのメニューからブロック化を設定したあと、その段落・ブロックの後ろに、アクセス制御したいブロックを図のようにクリックアンドドロップすることで、挿入できます。
以上の操作により、この段落と制御したいブロックの集合体としてのブロックが出来あがります。
このブロック化した集合体について、改めてアクセス制御を設定すれば、アクセス制御が正常に機能します。
最も楽でSPAMが回避できるユーザーの自動登録の手順は、以下のイベントの通りです。
下図には、「ダッシュボード -> Ultimate Member -> 設定 -> Email」で設定できる項目の具体例を示しました。
当サイトは、AMP対応です。AMPに対応させるためには、ページのコードであるJavaScriptやHTMLは、AMPのルールに沿った制限がかけられています。
AMPのルールに合わないコードや余分なCSSは変換/削除されます。それでも正常に動くプラグインでないと使用できません。
Ultimate Memberと専用のreCAPTCHAは、AMP対応可能です。アクセス制限の掛け方やユーザー登録の流れについて、今回解説しました。先ずは、自分だけしか見れない制限付きのページを作ったり、制限付きブロックを含むページを作ったりして動作確認をしました。
以上
2019/12/08 はりきり (Mr) 2020/02/15 文言整備、追記 (ユーザー登録) 2020/02/22 文言整備 2020/04/22 記事一覧を表示した際、表示制限にあるにも関わらず記事内容が表示させる問題についての対策を追記 2020/05/08 追記 (まとめ、システム構成) 2021/03/07 追記 (サイトのロバストネスを確認するためのプラグイン: Statisfy, SiteGuard WP Pluginの紹介と運用)
当サイトでは、AMPプラグインで全てのコンテンツをAMP対応にしています。
以下は、Advanced Adsプラグインについて、導入後の使い方についてまとめました。
まだまだ、AMPとそれに対応しようとしているプラグインは完全に互換性があるものではないのですが、最近では、相性も良くなってきています。しかし、試行錯誤で設定を変更したりして動くようにしていることも多くあります。
Advanced Adsプラグインは、ドイツ製のAMP版のページにも対応した、広告表示プラグインです。
AMP (Accelerated Mobile Page)は、スマホなどのモバイルでの表示を高速化する技術です。サイトをAMPに対応させたあとは、AMP用の広告の対応も必要になってきます。
一般の運営者では、AMP対応広告コードを開発者と同じ様には書けません。
そこで、AMP対応の広告表示用プラグインとしてAdvanced Adsを導入します。
このAMPプラグインは、GoogleとAutomatticが開発し、途中、これらの企業の名前は薄れ、ボランティアで開発が進められているWordPressオフィシャルのプラグインです。
その他、AMPページにするプラグインは、以下の4つがあります。
Advanced Adsプラグインは、AMPページに対応しています。また、このプラグインがお勧めしているAMPプラグインは、前述のAMP by Automatticです。
AMPは、PCと比較して非力なデバイスであるスマフォやモバイルにおいて、レスポンス良く表示するための新しい技術です。
AMP対応とは、フルセットのJavaScriptが使用できなくなります。その影響で機能しなくなるコードがでてきます。JavaScriptは、表示関係に使用されることが多いので、表示ができるようなコードにするなどの連携が必要です。
その表示には、広告の表示も含まれます。Advanced Adsとの連携も必要ということです。
広告には、Google, Amazonなど代表的な広告ネットワークがありますが、Googleでは、AMP対応と非対応を選択てきます。
AMP対応にした場合は、AMP対応の広告の表示の仕方に従う必要があります。Advanced Adsは、AMPに対応しています。
Google Adsenseなどから送られてくる広告コードの配信元を広告ネットワークと言います。
Google Adsenseの設定でAMPを有効にすると、AMPに対応した広告コードを送ってくる(と思われる)ので、AMPページでは、その広告は、正しく表示されます。
もしも、AMPに対応していない普通の広告コードが広告ネットワークから送られてきたら、ほとんどの場合AMPページでは正しく表示できません。
今回、このサイトでは、広告を出すほどアクセス数がある訳ではありませんが、勉強がてら有料版のAll Accessを導入しました。
有料版では、Add-Onとして幾つかの追加機能を導入できます。現在、以下のプラグインを追加しています。
2020/03/03 テストに没頭しすぎて、オーナー・クリックをしたことで、現在、Googleから30日間のペナルティーをもらっているため、テストは中断しています。広告が表示されたり、されなかったりと、イライラして、表示されていないスペースを連打したことが、大きな原因であると反省!
2020/04/02 自動的に復帰されたので、セッティングを再開
以下、Add-Onの説明をする前に、前提条件として知っておきたい基礎知識と、Advanced Adsの関連機能について、マニュアル原本から概説としてまとめました。
Display ads on AMP pages
https://wpadvancedads.com/manual/ads-on-amp-pages/#utm_source=advanced-ads&utm_medium=link&utm_campaign=notice-amp
Goobleの広告技術であるdoubleclickの例
Advanced Adsの有料版では、Advanced Ads Proが使用できます。特徴について、原文の文書から以下にまとめました。
Advanced Ads Pro
https://wpadvancedads.com/add-ons/advanced-ads-pro/
有料版では、Sticky Adsを使用可能となります。
2020/04/11現在、インストールするとAMPで不適合が出て、AMPの評価が▲になる項目がある。Stickyは、重要でない機能であるため、インストールしない方が良い。
AMPバージョンのページにGoogle Adsenseを表示させるには、以下の項目の2つの項目にチェックします
Responsive Ads
https://wpadvancedads.com/add-ons/responsive-ads/
キャッシュされたWebサイトでブラウザー幅の訪問者条件を使用する場合、おそらくAdvanced Ads Proからのキャッシュ無効化が必要になります。
AdSenseレスポンシブ広告のカスタムサイズも、余分なキャッシュ無効化をしなくても機能します。
以下の手順で、「新しい広告」を作る。この広告は、このままでは、自動で表示されないので、「配置」により自動的な広告に設定する。
Advanced Adsのサイトの和訳から、内容を以下にまとめました。
AMPプラグインを更新したり、その他WordPressを構成していプラグインを更新した場合、AMPプラグインによる検証が古くなってしまいます。そのため、Google Adsense (広告)が表示されなくなる場合があります。
表示に関係するプラグインを更新した場合、毎回、以下の操作を実施する必要があります。
対応策は、図1のように、AMPプラグインから、「検証済みURL」を選択します。図2のように、①から④の手順により「最新でない結果」の「URL」を再検証します。この処理は、Google Adsense 関連の外部サイトとやり取りして、キャッシュを保管するため、1つのURLの処理時間は、~10秒程度かかるので、選択したURLに応じて時間を要します。
選択数は、表示できる数に依存するため、処理するURLが多い場合は、表示数を多く増やしてください。最大100の表示は可能です。100を表示させてから一括でURLのチェックボックスにチェックを入れて100のURLを選択できます。
AdSense Auto ads not showing up
https://wpadvancedads.com/manual/?utm_source=Advanced+Ads&utm_campaign=983b5218bd-NL_Main_Manuals&utm_medium=email&utm_term=0_e6d3089448-983b5218bd-106541321
そもそも広告が悪い場合があるようです、縦不向きの450px幅の携帯で、その広告が表示されるののに、幅がもっと広い(~1000px)タブレットでは表示されないことがあります。よく調べてみると、携帯でも横向きにして幅が~780px程度になると表示されない、その広告は、動画広告です。おそらく、Google AdSenseから自動で飛んでくる、その広告は、幅が広いと表示されるされないような設定になっており、携帯の狭い幅でしか表示させないものと思われます。この動画形式の広告は、アニメ系の広告が多いですが、10回に1回程度でランダムに飛んできます。その都度、広い幅のタブレット、Windows PCでは表示がされません。現在のところ、解決策はありません。表示されないのは良いのですが、その広告スペースが空いてしまうのが、なんともみっともないです。Google AdSenseのサイトの設定で、何か設定があるのかも知れませんが、今のところ不明です(2020/09/21)
情報が古いですが、Google Adsenseのサイトに、プラグインによる広告の挿入について参考記事があります。2020/3現在「ネイディブ」は「Standard」、「ペア」は「Traditional」、「ネイディブ」は「Reader」と表現が修正されています。これらに関する記事は上記のAMPプラグインの記事をご参照ください。
広告コードの挿入方法 | ネイティブ | ペア | クラシック |
---|---|---|---|
Advanced Ads プラグイン(自動広告と広告ユニットの両方に対応) | ☑️ | ☑️ | ☑️ |
Ad Inserter プラグイン(自動広告と広告ユニットの両方に対応) | ☑️ | ☑️ | ☑️ |
Insert Headers and Footers プラグイン(自動広告のみ) | ☑️ | ☑️ | ❌ |
Genesis テーマ(自動広告のみ) |
AMP バージョンの WordPress サイトに広告コードを挿入する
https://support.google.com/adsense/answer/9579782?hl=ja
「automatically convert to・・・」は選ばない、他の設定の広告との組み合わせで不具合があったり、表示されなかったりするため、「user responsive width and static height of [200]px」を選択する。
[200]の値は、もしも、広告が表示されず、空白スペースとなって、見苦しい場合がある。その場合、[10]などの小さい値にしておくと良い。
Browser Width
を選択して、横版の大きさを指定する。試行錯誤がが必要だったが、設定したあとは、cacheをフラッシュしてから、表示テストをすること。
以下の2つの広告を用意しておけば、iPhoneとiPadで、異なる広告を表示できる。しかし、挙動はトリッキーで、以下の値の設定で、うまく表示分けができたり、つぎの日にはできなくなっていたりと、まだ、安定させきれていないのが現状です。広告タイプとの組み合わせの問題もあると考えられる。
以下の設定値を使うことで、モバイル(iPhone 6 Plus同等)と、Desktop(iPad Pro 11, Surface Pro 6と同等)での画面の大きさ別に広告を表示させることができるようになります。
Fallback width
は、とりあえず、790、に設定
<script async custom-element="amp-iframe" src="https://cdn.ampproject.org/v0/amp-iframe-0.1.js"></script>
<script async custom-element="amp-script" src="https://cdn.ampproject.org/v0/amp-script-0.1.js"></script>
Advanced Ads→ 配置→ 新規作成→ 広告の選択
表示は、Advanced Adsプラグインにお任せすることも良いが、テストするなど、明示的に広告を表示させる場合は、ページに受け込みます。
タイプの設定は、以下の図のように7種類。In-feedは使わない。広告リンクは、2種類ありますが、2021/03/10から使用できなくなることが、Googleから2020/12/10付で発表されました。
タイプ : 広告リンク(レスポンシブ)での設定
タイプ : レスポンシブデザインでの設定
以上
編集履歴 2020/03/01 はりきり(Mr) 2020/03/08 追記 (Display ads on AMP pagesを要約) 2020/03/09 追記 (Advanced Ads Pro, Responsive Ads) 2020/04/11 追記 (Sticky Adsは不要、AMP版広告の作り方) 2020/04/21 追記 (AMPプラグインとAdsense Adsプラグインの連携、その他、表示デバイス(モバイル、PC)の関係性について) 2020/04/30 追記 (広告の作成と広告の配置について、操作を追記。完全に抜けていた^^;) 2020/08/23 追記 (WordPressを構成する各プラグインを更新するとGoogle Adsenseが表示されなく場合があり、そのURLは、AMPプラグインで再検証が必要) 2020/09/21 追記 (幅の広い端末では、アニメーション広告が必要じされない) 2020/12/10 追記 (Google Adsenseの画像広告を、AMPページに表示させる。広告リンクは2021/03/10より使用できなくなる)