カテゴリー: Synology

ID22640

はじめに

このblogは、レンタル・サーバーではなくSynology NASを使っています。やはり、性能的にはレンタル・サーバーに勝てません。そこで、自宅のNASを使ったblogでは、以下のような工夫が必要になってきます。

• ベージ表示などのレスポンスの改善
• セキュリティの確保
• NASの管理を含めたWordPressの管理

この記事では、ページのレスポンスを向上させる2つのプラグインとして、「AMP」と「キャッシュ」・プラグインを組み合わせてについて解説しています。以前は、AMP対応をせずにページレスポンスの改善を目指していたので、AMPプラグインを使用せず、Autoptimizeプラグインを使用していました。現在では、AMP対応にしてページのレスポンスの改善を図っています。

• AMPプラグイン
• WP Super Cache
• WP Optimize
• WP Rocket

ついでに、AMPプラグインで何度も生じている「検証済み」の問題についても経験談を載せています。

これらのページレスポンスの向上プラグインなどのSoftwareの適用以前に、ネットワーク回線やHardwareスペックアップの問題もありますが、ここでは述べていません。

[Synology] DS918+ 初期導入時にはJBOD HDD、その後、メモリ増設・SSDキャッシュ増設・HDD追加でRAID 5によりフルスペック化 — アプリ/ツール構成 [2021/08/28] ID33

ページのAMP化のみでもレスポンス改善は十分高い

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にするメリットについて解説します。

AMP

キャッシュプラグインを追加する

キャッシュプラグインにも種々ありますが、これまでに色々試しました。その結果、ここ半年間使用し続けたのは、「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も、プリロード機能は、使用しない方が良いということです。

WP Super Cacheの設定のほんとのところ

• プリロード機能は使用しない
  • 理由 : 古いキャッシュの表示が起こる場合がある
• 投稿またはページが公開されたときにすべてのキャッシュファイルをクリアする機能は使用しない
  • 理由 : 新しい投稿を作成するたびに、WPスーパーキャッシュが数分間効果的に無効になってしまうためです

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

WP Super Cacheプラグイは、プラグインのキャッシュ/ブリロードに特化しています。多数の設定項目があり微調整も可能です。初心者には優しくて、デフォルトの設定についての解説もわかりやすいです。プリロードのキャッシュファイルの圧縮の設定もできます。

繰り返すプリロードの時間の設定は、ももちろん可能です。初期値は600分です。プリロード処理が開始される時、及び100や200毎に、メールを飛ばす機能もあります。機能していることが分かるので安心ですし管理に役立っています。

今回、WP Super Cacheの試用を開始しましたが、これまで使用していたWP-Optimizeの設定は、キャッシュを無効化し、データベース管理機能のみを使用している状態に設定しました。

SpeedPage Insightsによるレスポンスの測定結果は、従前の設定の場合と比較して同等の結果でした。しばらく攻め込んでみたいと思います。結果は、随時、追記していきます。

WP Super Cache

WP-Optimize

WP-Optimizeは、キャッシュ機能だけではなく、データベース管理、イメージ圧縮などの複数の機能を備えています。

WP-Optimize – Cache, Compress images, Minify & Clean database to boost page speed & performance

WP Rocket

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

Super Page Cache for Cloudflare

WP Super CacheとWP-Optimizeの比較

約900ある投稿とページをプリロードする時間を比較しました。先ず、全ての投稿とページについて、AMPで再検証します。全てが完了してから、ブリロード機能を実行しました。その結果、WP Super Cahceでは約50分、WP-Optimizeでは約25分でした。WP-Optimizeの方が高速でした。

設定の際に思いもよらず得られた懸案の解決

AMPの再検証エラー問題

AMPプラグインを使用していて、数ヶ月前の9/21に投稿/ページの「再検証」が、以下のエラーログと共に不可になっていました。

• cURL error 28: Operation timed out after 15001 milliseconds with 0 bytes received. Please check your Site Healthto verify it can perform loopback requests. If you are stuck, please search the support forum for possible related topics, or otherwise start a new support topic including the error message, the URL to your site, and your active theme/plugins. Please include your Site Health Info.

ネットで調べてみましたが、DNSが悪いので、ローカルにDNSを立ち上げろとか、AMPのサポートでは、AMPプラグインによる不具合ではないとか、結局、原因を見つけることは、できずにいました。

WP Super Cacheのワーニングのお陰

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、追記 (文言整備)