WordPressのチューニングでここまで変わる

ここ数日、特定の記事へのアクセスが急激に伸びてサイト全体が重たいというのもあったのですが、何よりも投稿時に503エラーやらInternal Server Errorが出るなどのトラブルも続いていました。また、1年間いろいろなプラグインの追加や削除、テーマの改造などを繰り返した結果として、Google PageSpeed Insightの点数がモバイルで50点まで下がってるのが判明。

サーバープラン変更で転送量増やしたり、リソース増やすという力技も良いのですが、そもそもスピード低下は検索エンジンのSEO的に最悪の事です。という事で色々チューンしてみました。

改善後の値

PageSpeed Insightの値

色々改善してみた結果としては、以下の図の通り。

モバイルで93点、デスクトップで99点まで改善する事ができるようになりました。レスポンスが非常に軽快になり、503エラーが低減しました。また、ページビューの観測比較をしてみた所、同じ曜日の先週、先々週との比較で49%増まで改善しました。

サイトスピードを放置してると色々損しますよという良い事例でした(機会損失したり、直帰率が増えたり様々)。

図:デスクトップの値はほぼ改善

図:モバイル側も大幅に改善しました

サーバリソースの低減

色々と改善してみた結果、ページビューは増加してるにも関わらず、同日先週比で相当数低減することが出来ました。

サーバ転送量で先週比で1.48GB減(27%改善)、CPU使用率では先週比で84分減(34%改善)しました。サーバ契約転送量は上限が決まっているので、上位の契約プランに変更せずにだいぶ余裕を確保することが可能になりました。

また、ディスク使用量は最適化前は20GB/100GB契約を使用していましたが、最適化後は4GB/100GB契約(1/5)まで減らす事ができ、ディスク容量に相当の余裕が生まれました。

図:CPU使用率が減ることでレスポンスが改善

図:サーバ転送量が減ることでコスト節約

ページビュー等の改善

最適化をしたことでサーバリソース消費の低減になった事のメリットとして、ページビュー数などが2倍近く上昇しました。PageSpeed Insightの項目でも記述したように、レスポンスの悪いページは、Googleでのランクが下がります。また一方でレスポンスの悪いページは、ページビュー数が下がる統計的な傾向があります。いいこと一つもありません。

最適化をした事でGoogleページランクが上昇するだけでなく、そのユーザのサイト内でのページビュー数まで上昇させ、結果的には収益性もそのまま上昇させることに繋がるわけです。

2021年1月時点でのページビュー数がおよそ17,000、最適化後のページビュー数は、39,000。もちろん記事の増加やバズった記事などで変動もありながらも、それらを除外しても30000ほどであることから、如何にレスポンスの改善が重要なのか思い知る事例でした。

実施した改善策

プラグインの断捨離

全体のうち、6割改善効果があったのはプラグインの断捨離。すでにもうWordPress公式には掲載されていない古いプラグインを、後継のプラグインに変更したり、より軽量な別のプラグインに切り替えたり。改善の為にあえて追加したプラグインもありますので、減らせば良いというわけじゃないという点がなかなか難しいポイントでした。

現在はだいたい28個のプラグインを使っています。プラグインの選定は慎重に。

プラグインの削除と入れ替え

削除したプラグインは以下の通り

  1. WordPress Related Post — 廃止されてたので、Yet Another Related Posts Pluginに入れ替え
  2. ARI Fancy Lightbox — CSS関係で引っかかってたので、Responsive Lightboxに入れ替え
  3. JetPack by WordPress — 廃止。これを止めるだけで、72点まで改善。
  4. Crayon Syntax Highlighter — 古すぎたので、後継のUrvanov Syntax Highlighterに入れ替え
  5. Google Site Kit — 最悪でした。入れただけで25点まで下がりました・・・速攻で削除

特にJetPackはNGでした。期待してた機能は他のプラグイン追加で対応させて、前述の数値を叩き出せてるので、メリットゼロ確定。古いプラグインは別のものに差し替えただけで、点数がわずかですが改善しています。

統計解析はもともとGoogle Analyticsを入れてるので、そちらで十分すぎるくらい把握できています。

代替プラグインの追加

Jetpackで担当させていた機能は他で代替させています。今回以下のプラグインを新たに追加して対応させました。前述のRelated Postのようにすでに代替させていたものもあります。

  1. Google XML Sitemaps — Google Search Console登録用のsitemap.xml生成プラグイン
  2. SEO SIMPLE PACK — SEO対策部分を対応。Analyticsコードの追加ウェブマスターツール認証なども担当

WordPress統計情報の代替

Google Analyticsでの代替

JetPackを使う目的の1つだったWordPress統計情報。SlimStat Analyticsのような強力な統計解析を入れても良いのですが、今回の目的のウェブサイト軽量化には反するものになってしまいます。せっかく上げたPageSpeed Insightの値を大幅に落としかねません。

しかし、1つを除いて殆どはGoogle Analyticsで代替出来てしまいます。トラッキングコードはSIMPLE SEO PACKで簡単に追加ができるので、導入自体で躓くことは少ないと思います。AndroidアプリのAnalyticsで閲覧もできるので、むしろ統計解析が楽になりました。主に代替させたものは

  • 訪問先ページのカウント – ページビュー数でのランディングページで代替
  • 参照元ウェブサイト – ページビュー数での参照元で代替
  • 訪問時検索キーワード – ページビュー数での上位のキーワード
Google Tag Managerでの代替

ただ1つ問題が。Google Analyticsでは、離脱ページはわかっても、離脱先つまりクリック先が取得は出来ません。ウェブサイトにたくさん貼られてる外部のリンクの参照数は、Google Tag Managerでトリガーを作成し、WordPressにGoogle Tag Manager for WordPressを導入して、登録し、Google Analyticsへと連結が必要です。

結構複雑な作成手順が必要なので、こちらのサイトを参考に作り、コンテナを作り、コンテナIDをプラグインで登録しました。PageSpeed Insightへの影響は殆ど有りませんでした。

結果として、WordPress統計情報の一つである離脱先のリンクの情報を、Google AnalyticsにTag Managerを使って連結する事が出来ました。これで全ての統計情報を代替出来ました。

キャッシュの改善

これまで、ウェブページの最適化ではWP-Optimizeのみを使っていました。データベースのクリーニングの実施、ページキャッシュ、画像の圧縮が主な役割ですが、後半2つを別のプラグインに担当させて最適化を図りました。これで大体、1割くらい改善しています。

  1. AJAX Thumbnail Rebuild  — 投稿した画像のサムネイルの最適化。普段は停止。
  2. Disable and Remove Google Fonts — Google Fontの参照はPageSpeedにとってマイナスです。
  3. EWWW Image Optimizer — 投稿した画像の一括圧縮を行います。無駄にバカでかい画像は縮小するに限ります。
  4. WP Fastest Cache — 有名なキャッシュ系のツール。ページキャッシュとCSS, JSの圧縮ではOptimizeより効果が高かったです。

データベースクリーニングだと、Optimize Database after Deleting Revisionsを使うのも効果があります。

Plugin Load Filterの導入

地味に効果の高かったのが、このPlugin Load Filterの導入。実は、WordPressのプラグインは導入し有効化すると、編集画面でしか使わないものであっても、プラグインとしては通常のページでも負荷が発生するようで、編集画面でしか使わないものは、ページの側ではオフにするように設定するのが、このプラグイン。

ただし、Google XML Sitemapのようにページと編集画面両方で使うものをページの側でオフにしてしまうと、Googlebotがsitemap.xmlを読みに行けなくなってしまうので、慎重にオンオフをセットしましょう。自分が編集画面のみオンにしてるものとして

  • TinyMCE Advanced
  • Classic Editor
  • Disable Gutenberg

などなど。編集系プラグインばかりです。

functions.phpの改造

各Wordpressのテーマに同梱されているfunction.phpに直接記述をしてみて、若干改善効果があったものがありました。以下ソースコード

劇的に改善というわけではないのですが、いくつかPageSpeed Insightで引っかかってた項目がこれでクリア出来ました。また、自分が今使ってるテーマは、一部でGoogle Fontsを導入していたので、function.phpにてそのラインをコメントアウトしました。

※jsにasync属性を付与については、テーマなどによってはモバイルメニューボタンが動作しなくなるなどの不具合が出る可能性があります。

Adsenseコードの遅延読み込み

ブログがある程度軌道に乗って、サーバ代やドメイン代をAdsenseから広告収入を得て・・・と考えると、導入するのがGoogle Adsense等ですが、この時、AdsenseのJSコードをそのまま導入してしまうと、JSの読み込みがボトルネックとなって、かなりPage Speed Insightのスコアを落としてしまいます。

85点くらいのスコアが場合によってはこのコードだけで45点以下にまで落ちたりします。これがページの数だけ全て下がるのでかなり堪えます(特にモバイル側のスコアが下がります)。そこで、このAdsenseのコードを遅延読み込みに変えて上げるとスコアが一気に改善します。

  1. コードのうち、「<script async src=”https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js“></script>」については削除もしくはコメントアウトする
  2. WordPressのテーマの場合はfooter.phpの一番下、Bodyよりも上のエリアに以下のコードを追記して保存する。このコードはこちらからお借りしました。
  3. キャッシュ系のプラグインを入れてるのであれば、一度全てパージをして再キャッシュする
  4. これでAdsenseコードが遅延読み込みされるようになり、画面のロード時間が飛躍的に上がります。

その他

これは契約サーバによる所が大きいですが、このサーバの場合、国外IPアドレスフィルタが、WAFとは別に用意されています。WAFは攻撃に対しては効果は高いのですが、コメントスパムのような厄介な連中を防げるわけではないので、国外IPアドレスフィルタは非常に効果的です。

特に中国・ロシアあたりからの無駄なアクセスはリソース消費の原因になり、503エラーを頻発させた上に、スパムがじゃんじゃん届きます。Akismetプラグインである程度防げるといっても、実際に問い合わせフォームからたくさん、要らないお手紙が届きました。国外からの概ねのアクセスを遮断することも少ない資源を活用する上では重要です。

※サーバレスポンスの悪化は当然、PageSpeed Insightの点数を下げる大きな要因になります。

関連リンク

共有してみる: