はじめに
AMP プラグインを運用していく場合、最も時間がかかる処理は、AMP検証です。AMPプラグインがインストールされている場合、投稿の編集ページの右上に丸印で稲妻マークがあります。これをクリックすると、現在のバージョン(Version : 2.2.1)では、そのページについて再検証が実施されるようになっています。この方法で1つずつページを検証することも可能ですが、1000もページがあるとその作業は、退屈極まりないものになります。
そこで、AMP->「AMP検証済みURL」ページから以下の作業で効率よく再検証することにします。
このページを表示されて、表示オプションから表示数を100にすれば、100のページが表示できます。この状態で、左の「URL」のチェックボックスをチェックして表示されている全てのページを選択状態にします。その上に表示されている一括操作を「再検証」にして、その右横に表示されている「適用」ボタンをクリックすれば、一括の再検証が可能です。この機能を効果的に使えば、AMPページの管理はだいぶ楽になります。
でも、自宅のSynology NASにWordPressを導入している場合、NASのシステム要件によっては、以下に説明したような制約がありました。対応策がやっと発見できたので、以下に解説してみたいと思います。
AMP検証済みURLの更新
新しいプラグインを導入したり、プラグインの更新をした場合、それまでのAMP検証済みのページは古くなります。そのため、AMP PluginによるAMP検証が再度必要です。
以前、WordPressを導入していたNASは、DS918+でした。メモリーは、2つのスロットにアクセスできるので、標準の4GBを取り外し、8GB x 2で合計16GBにアップグレードしていました。その場合、一括して実施できるAMP検証のページ数は、最大「100」が可能でした。
昨年、WordPressをDS918+からDS920+に載せ替えました。システム構成は、フルスペックとなったDS918+からすると、デフォルのままで、唯一、ストレッジをHDDではなく、4スロットともSSD: 1TB x 4 (slot)にアップグレードしていました。ところが、DS920+では、一括でAMP検証が可能なページ数は、どうしても「8」でした。これでは、全てのページを処理するには同じ操作が結構な回数になります。退屈極まります。
今回、ふとアイデアが浮かんだので、システムメモリの増加を試みました。メーカー (Synology)が推奨しているメモリ : 4GB 1枚(Synology)を追加 (デフォルトのメモリスロットにはアクセスできない)しました。
その結果、もう一つの懸案事項として取り組んでいるPageSpeed Insightでのスコアには変化がありませでした。
しかし、前述で説明したAMP検証が可能なページ数は、少なくとも「40」に増加しました。一括の検証処理の過程でどうしても続行できない場合があるため、全てのページの処理が終わる前の処理の途中で一括の再検証処理が停止してしまうことがあります。その場合、スムースに処理できる予定の可能数よりも少なくなることがあります。40よりも最大可能な一括検証数が多い可能性もまだあるので、今後確認しようと思っています。
因みに、AMP再検証の処理が継続しているかは、Synology NASのDSMにログインして、リソースモニターを起動して、CPUの稼働状況とネットワーク状況をグラフと数字で確認すれば判断が付きます。処理が終了した場合、CPUの稼働状況(%)、ネットワーク状況(KB/s)も一気に低下します。
[s-text id=37723]
[s-text id=37714]
まとめ
システムのメモリ容量がAMPプラグインの動作にここまで関係することは意外でした。
型番 | 仕様 | タイプ |
D4NESO-2666-4G | DDR4-2666 260pin | Non-ECC Unbufferd SO-DIMM 4GB |
AMP Plugin
https://ja.wordpress.org/plugins/amp/
編集履歴
2022/02/07, Mr.HARIKIRI