WordPressのスピードチューニングをしてみた

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

サーバープラン変更で転送量増やしたり、リソース増やすという力技も良いのですが、そもそもスピード低下は検索エンジンのSEO的に最悪の事です。という事で色々チューンしてみました。Pagespeed Insightに着目してるため、GTMetrixなどでは評価が真逆になる可能性もあります。

※なお、自分のさくらのPHPはモジュール版ではなくCGI版です。モジュール版に乗り換えれば更に高速化するかもしれませんが、面倒なので自分は移行していません。よって、以下の検証はすべてCGI版での結果となります。

※お知らせに書いてましたがボリュームが増えすぎたので、エントリーとして書き直しました。

改善後の値

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にてそのラインをコメントアウトしました。

Lightningの場合、noto-sansというものが遅延の原因となっていたので、google fontsの読み込み拒否としてコードに追記しています。

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コードが遅延読み込みされるようになり、画面のロード時間が飛躍的に上がります。

プラグインの設定

WP-Optimize

今現在はもう主力で使っていないプラグインですが、以前は主力で使っていたキャッシュ系のプラグイン。ただキャッシュ系の機能は後述のWP Fastest Cacheに任せたので、こちらでは以下の機能だけを利用しています。

  • 画像の圧縮Smush APIを使ってのアップロード画像の圧縮を行う機能
  • データベース – データベースのクリーニングを担当。予約クリーニングで常に最適化もできるけれど、リビジョンが削除されても困るので、手動で実行

キャッシュ、Minifyについてはオフにしてあります。

図:普段の画像の圧縮が主な仕事

図:実際の圧縮画面

WP Fastest Cache

キャッシュ系をメインで担当。主に

  • HTML圧縮
  • CSS圧縮
  • CSS結合
  • JS結合
  • ブラウザキャッシュ
  • Gzip圧縮

などをオンにしています。CSSやJSファイルは結合したり圧縮する事で、読み込み量を減らし高速化に貢献します。またキャッシュしておく事で何度も同じようなリクエストに対してはキャッシュから払い出すので、DBからの呼び出しを大きく減らし、また、データの転送においてはサーバ側が対応してる必要がありますが、Gzip圧縮を有効化しておく事で、高速化にかなり貢献します。

尚、自分のサーバがGzip圧縮が効いてるかどうかの確認は、Gzipチェッカーで確認すると良いでしょう。こちらのサイトでのチェックだとどれくらい圧縮されたかも確認可能。

図:キャッシュ系はもはや必須のプラグイン

図:Gzip圧縮はとっても重要

Plugin Load Filter

通常プラグインはその役割の範疇で動作するものなのですが、テーマファイルと干渉したり不要なページなのに動作していたりと結構ファジーな感じになっていたりします。特に管理者が管理画面でしか利用しないであったり、バックグラウンドで動作するため、「表示には関わらない」はずのプラグインが動作していて、結果的にPagespeed Insightのスコアを落としたり、セキュリティ面でもあまり好ましくありません。

そこで、このプラグインを利用して特定のページではそのプラグインの動作を停止させるというプラグインです。

Normalが通常動作、Adminが管理画面でだけ使うもの、Page Typeがページ毎に動作の可否を決めるものという形で指定が可能です。Page Typeは記事の編集画面でその動作を決める事が可能です。

図:何をAdmin限定にするかでOK

Async JavaScript

このプラグインは、JSの読み込みを遅延ロードさせる事で、サイトの描画を優先しPagespeed Insightの評価アップに繋がるように入れています。特にモバイル側でのポイントが場合によってはかなり上がるのでオススメです。

特に設定もせず、インストールしたらそのまま使っています。

図:更に細かいチューニングも可能になってる

Native LazyLoad

Google提供の画像の遅延ロードをさせる為のプラグインがNative LazyLoad。インストールして有効化するだけのお手軽仕様です。画像の遅延ロードもPagespeed Insightの評価ポイントの一つになっているので、入れておいて損はないと思います(ただ、2年前に開発が止まってるのが気になる)。imgとiframeタグに関して、自動的にloading=”lazy”と付けてくれることで、実現してるだけのプラグイン。

似たような遅延ロードさせるプラグインとしては、Lazy Load (作者:WP Rocket)があり、こちらは現在も開発が続けられています。

その他

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

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

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

2021年 再度挑戦

時が経過すれば、それだけプラグインの追加やテーマの更新等により折角最適化してスピードアップしても、激減する事がままあります。Bizvectorが開発終了に伴って、Lightning + VK All in One Expansion Unitに切り替えて様子見していましたが、Google Pagespeed Insightの成績が激減し、50を下回る事に。以下、原因を追跡してみました。

※今回はモバイルを80ポイント以上を目指します。

図:激減したスコア

全てのプラグインをオフにして見る

一番原因となってるであろうは、追加されたプラグイン達。これらがボトルネックになってる可能性があるため、一旦全部停止して、スコアを見てみることに。すると、以下のような結果が得られました。

この結果から、Themeに問題があるわけじゃないということがわかります。

図:スコアが劇的に改善

プラグインを一個ずつオンにして検査

次にプラグインを一個ずつオンオフしてGoogle Pagespeed Insightで調査。結果、スコア低下に大きな影響与えたプラグインは以下の通り。

  • vx expansion unit(47Pも下がった)
  • Responsive Lightbox
  • What’s New Generator
  • kk Star Ratings
  • Shortcode Star Rating
  • Ad Inserter
  • SEO SIMPLE PACK(10P以上下がる)

特にBizvectorから移行時に推奨されていたVX All in One Expansion Unitが物凄く下がる。他、レーティング系のプラグインもかなり悪影響で、SEO系での相当のパフォーマンス低下を引き起こしていたので、無効化してみた。とは言え、VX All in one Expansion Unitは色々な役目を担ってるので、ここをまずは深堀りしてみる。

図:特にモバイル系のスコア低下が酷い

色々プラグインをリストラ&最適化

大きくサイトに影響を及ぼしていた前述のプラグイン、これらをまず全停止してVX All in one Expansion UnitおよびSIMPLE SEO PACKは無効化のままにし、他は削除してみました。他の問題ないプラグインを有効化した後に、再度テストを実行してみると以下の結果が得られました。

図:問題ないプラグインは本当に影響を及ぼさない。

しかし、これではリストラした分だけサイトの利便性が下がってしまってるので、代わりになるプラグインを調べ上げて一個ずつ調査。影響が低いものを選別し以下の処置をしてみました。

  • トップページに戻るボタン ⇒ to topプラグインで代替
  • Lightbox系を代替必要 ⇒ Easy Fancyboxで代替
  • レーティング系プラグインは使わないようにする(全部リストラ
  • CSSカスタマイズ ⇒ 標準のカスタマイザーで対応
  • Googleタグマネージャの代わりをみつける ⇒ Google Tag Manager for WordPressで代替
  • 関連記事表示 ⇒ Yet Another Related Pluginで代替
  • Google Analytics関係 ⇒ True Lazy Analyticsで代替(Analyticsコードの遅延読み込み)
  • Google Adsense関係 ⇒ 取り敢えずオフにしておく
  • キャッシュ系 ⇒ WP-Optimizeに一本化(WP Fastest Cacheは500エラーが頻繁に出たので廃止)

VXが担っていた殆どの機能を専門のプラグインに変更してVXオン時と比較するとVXにやらせるよりも、専用のプラグインのほうがパフォーマンスが良いので、VXとしては上記の担当機能は全部外しました(実質使ってるのは、カスタム投稿タイプの機能くらい)。カスタム投稿タイプもCustom Post Type UIに入れ替えて実験しましたが、殆どスコア変わらずなので、こちらに交換してVXはリストラでも良いかなと思います。

ここで判明したのが、VX All in One Expansion UnitにてAdsenseコードの反映を使っていましたが、これが40ポイント台まで下落させている一番の元凶だと判明。Adsenseコードの直貼りは、害悪以外の何物でもないのがよくわかりました(Pagespeed Insightが下がるとSEO的にはマイナスとなるので、広告の意味がない

よって、VXもオンにしてみて、上記の機能をオフにし、専門プラグインに任せ、Google Adsenseの機能も外してみた結果が以下の通り。SIMPLE SEO PACKをオンの場合は、デスクトップが90ポイント、モバイルは88ポイントでそこまで壊滅的に影響を及ぼしているわけじゃないとわかったので、再度オンにしています。

図:多少下がったけれど、これは仕方ない

個人的今後絶対に入れないプラグイン

長年、WordPressを利用してきていますが、非常に具合が悪い、スピードパフォーマンスの低下を招くなどで今後もう絶対に入れないだろうなというプラグインは以下の数点。

  • JetPack – ウェブで勧めてる人いるけれど、パフォーマンス低下が酷すぎるので入れません。
  • Autoptimize – 色々とトラブルが出て散々な目にあったので
  • WP Total Cache – こちらも同上。キャッシュ系は本当によく選ばないとだめだね。
  • Google Site Kit – Google提供のパフォーマンス低下するだけのプラグイン。ハッキリ言って要らない
  • All in One SEO – パフォーマンス低下が他のSEO系に比較して大きい為排除

いかに便利であろうとも、どんなに利便性があがろうとも、ウェブサイトというものは人に見てもらえてナンボ。Webfonts系などもハッキリ言ってパフォーマンス低下しか招かないので基本排除しています。

何よりも、Search ConsoleやPagespeed Insightに影響が出るようなプラグインなど、ページランク下げて見られなくなるだけなので、Google検索基準で作らないとウェブサイトは意味がない時代になってる。また、ユーザにとっても何秒も表示に待たされるページはストレスでしかない(人間が待てる最大の時間は最大3秒間と言われる)。

WordPress側もスピード評価を入れて頂きたい。

Analyticsコードを遅延読み込み

Adsense同様、第三者コードとしてものすごくスピード評価の低下を招く要素がGoogle Analyticsのコード。故に普通に挿入するプラグインやテーマファイルに書き込んで置いても、スピードダウンします。よって、これを遅延読み込みするプラグインにて対応しました。

前述のTrue Lazy Analyticsがそのプラグインで、UAから始まるトラッキングコードを登録するだけ。実際に他のプラグインの場合相当下がっていますが、このプラグインの場合、速度低下を招かずに遅延ロードしてからトラッキングを行うのでスピードダウンしません。但し、遅延読み込みしている関係で若干正確性は失われますが、スピード低下のほうが大問題なので、ここは由しとしました。

特に第三者コードの影響を抑えてくださいという項目で顕著で、メインスレッドが○秒ブロックされたという事で、先にAnalyticsの処理が走ると終わるまで他のJSの読み込みなどがブロックされる為、遅延読み込みの効果は非常に高いです。

※また、やりがちな大チョンボとして、SIMPLE SEOなど他のプラグインでAnalyticsのトラッキングコードを入れてるのに、他のプラグインでも同じように入れてると、ダブルカウントされてしまうだけでなく、二重にJSをロードしてたりするので激重になります。自分のサイトでテーマ付属やプラグインなどで二重でトラッキングコードを入れていないか?もチェックしておくべきでしょう。

広告コード

Adsenseコードを遅延読み込み

どんなプラグインの影響よりも、やはり壊滅的に影響を与えているのは「Google Adsenseのコード」であることがよくわかりました。拡張機能の癖して遅延読み込みといったものに対応していないという状態では、正直ちょっと使えないです。ということで、前回同様の処置をしてみます。今回は自動広告のケースについて記述しています。

  1. テーマエディタを開き、Lightningテーマの場合は、_g2および_g3のfooter.phpにある</body>の前に対して前回同様の遅延読み込みコードを記述する(但し、テーマを更新すると初期化されてしまうので要注意
  2. ca-pub-xxxxxxxxxxの部分はAdsenseから取得したコードを入力しておく
  3. ファイルを更新をクリックする
  4. 自動広告ではなく、意図して挿入する広告の場合は、googlesyndicationのjsのコードは削除し、以下のようなコードをテキストウィジェットなどに貼り付ける。ca-pub-xxxxxxxxxxやdata-ad-slotについてはAdsenseから取得したコードを入力しておく。
  5. 一応、WP Fastest Cacheなどを入れてる場合は、キャッシュをパージしておき、ページをリロードして広告が表示されるまで待つ
  6. 広告が出るようになったら、再度、Pagespeed Insightにてテストをする

この結果、以下のような結果が得られた。殆ど広告表示によってスコア低下が発生する事がなくなり、レスポンスが向上。以下のコードは、2021年7月以降の新コードに対応させたものになります(広告自動挿入の為のコードになります。通常のブロック挿入の場合も殆ど同じような感じです)

図:目標達成。これで引き続き安心して運営を続けられる

図:遅延ロードのコードの書き込み先

他の広告コード

A8.netもしもアフィリエイトのようなサードの広告コードについては、こちら側でどうこう出来るものではないのですが、貼っているとPagespeed Insightのチェックで頻繁にCLSの問題、読み込みの遅さ、画像の圧縮不足、テキストの圧縮関係で怒られます。自分のWordpressで配信してるものではないので、これらの最適化は出来ませんが、Adsense同様にロードの遅延読み込みをさせることで若干軽減が可能です。

Ad Inserter Proを購入し、広告コードを管理することで、各ページに直接貼らずにショートコードで挿入、キャッシュ機能もついてるようですが目的は遅延読み込み。Misc⇒Display⇒Lazy Loadingにチェックを入れて保存で、広告コードの遅延読み込みが実現出来ます。

図:遅延読み込みオプション

Youtubeの埋め込み

実は、Youtubeの動画のコード、アレの埋め込みはPagespeed Insightのチェックではものすごく評価を下げる原因になっています。ましてや、複数の動画を貼り付けるとなると非常に表示自体にも影響する。だからといって貼り付けないというのもちょっと困る。そこで利用するプラグインがWP Youtube Lyteです。

既存のYoutubeの埋め込みリンクを置き換えもしてくれますが、Lite Youtube Embedのようにサムネイルをキャッシュし、ボタンをクリックされるまではロードさせずに待機。ボタンをクリックすると初めて動画のコードが読み込まれる仕組みになっています。使い方はちょっと事前準備が複雑なのでまた機会があれば記述しますが、基本はインストールして終了です。

自己評価では、30まで下がっていたとあるページが、プラグイン導入後は50以上まで回復しました(5個くらい動画が貼り付けてありました)

図:埋め込みの見た目はコレまでと同じ感じ

functions.phpの改造を追加

前述のfunctions.phpの改造のうち、サムネイル生成・jsにasync属性を付与以外のコードをfunctions.phpに追加した上で再度Pagespeed Insightでテストしてみました。デスクトップはほぼ変わらずですが、モバイルがそこそこスピードアップに繋がりました。

追加で、JS読み込みを非同期化するプラグインを導入し、そこそこ効果があったと思います。

※Lightningの場合、jsにasync属性を付与の改造コードを追加すると、スマフォでのハンバーガメニューが動かなくなるので外しておく必要がある。

図:モバイルも合格圏内の90ポイントまで持ってこれた

逆にプラグイン追加で改善したもの

これまでの改善を踏まえて、最後に新たに2つのプラグインを追加しました。Async JavaScriptおよびNative Lazyloadの2つ。入れたことによって、スピードアップが更に改善されて、スコアが以下のようになりました。

これまでトップページだけでテストしていましたが、フルで色々表示してるエントリーページはトップよりも評価が低かったのですが、これがかなり改善されました。モバイル側は殆ど変わらずですが、デスクトップ側が大きく改善。

尚、Lazyload系プラグインは他のプラグインでも提供されていたりして、干渉しやすいので慎重に。

図:デスクトップ側が大きく改善した

画像の超最適化

WP-Optimizeを使ってる理由の一つとして、Smush APIを使ってアップロードした画像の圧縮をしてくれるという利点があります。これによりスクショや写真などを圧縮して最適化し、ロード時間の短縮化を図っています。

しかし、これでもまだまだで、更に上のWebP形式というものがあり、IE以外の主要なブラウザは対応済みで、透過色にも対応している為、Animation GIF以外の形式はオリジナルよりも更にファイルサイズを小さくすることが可能です。(Smush APIで圧縮したものをSquoosh(Googleが提供してるサービスの模様)にて圧縮すると30〜50%さらに軽量化出来ました)

一個ずつ手で変換がアレという人はWebP Converter for Mediaというプラグインをインストールして、一括変換を掛けることも可能。オリジナルはそのままに違うディレクトリに変換してくれます。プラグインを無効化するとオリジナルの画像表示に戻る仕様になっています。こうする事で全体的な転送量の削減にも繋がる為、さらなるスコアアップが期待出来ます。

これだけ圧縮してるにも関わらず目立った画像の劣化も無く、またIE11はWindows11でいよいよサポートされなくなった事で今後もう考慮する必要性もなくなったので、WebPへの移行をしても良いのではないかと。

※85%でプラグインにて変換掛けてみましたが、全画像トータルで630MB分くらい削減出来ました。ただ、一部の画像はWebPのほうが大きいケースがあるのでその場合は処理がスルーされるようになっています。ファイルは拡張子はオリジナルと同じままでwebpにはなっていませんが、Chrome Devtoolを使って調べると、きちんとWebPになっていました。

図:更に画像を圧縮してスコアを稼ぐ

図:きちんとWebPに変換されてたケース

図:一括変換中の様子

Lightning Themeについて

Bizvector後継ということで利用してるLightningテーマですが、このテーマにはCSS関係で色々。

まず、標準機能であるLightning CSS最適化Tree ShakingというCSSをインライン化し主要なものだけを利用に限定する機能。これをオンが推奨であったので、変更したことで若干パフォーマンスが改善。また、Preload CSSというCSS読み込みを遅延化する機能。これもオンにすることで、一部ブロッキングしてた要素の問題が改善。

気になったのが、ずっとPagespeed Insightのモバイル側で出ていた2つのCSSについて、利用されていないであったり、ロードでブロッキングが発生してると指摘されていた項目があり、bootstrap.min.cssとall.min.cssの二種類。これがブロックしてるようなのだけれど、外すとレイアウトが崩れる(デスクトップ側で)。困ったものだ。

細かい事ではありますが、こういった無駄やオカシナ点も手動で直していく事で軽量化に繋がります。テーマを更新したらまた発生するのでちょっと手間ではありますが。

図:これはテーマ自身の問題点

.htaccessの設定変更

プラグイン系でもこの.htaccessの設定変更でパフォーマンスを稼ぐ手法をキャッシュ系が行っていたりしますが、現在の自分のWordpress環境だと記述がなかったので、追記したのが「テキスト圧縮の有効化」。自分のサーバから発信するデータに対して、テキスト系のデータを圧縮するものです。

WordPressインストールディレクトリ直下にある.htaccessファイルを以下の項目を追記。

改善項目で出ていたテキスト圧縮についてこれで改善されて僅かですがパフォーマンスも改善。WP-Optimizeのほうではgzip圧縮の追記については行ってくれてるようなので、追記せず。

拡張機能でパフォーマンス測定

Chromeの拡張機能で調査

LCPやらCLSやら現在のウェブの指標は非常に細かくなってきており、それらの結果として速度に現れ、Pagespeed Insightに評価が出ています。それらを細かく追跡するのに非常に役に立つChrome拡張機能が、Web Vitalsです。

Chromeに拡張機能を入れて、対象のページを開けば指標が計算されて色とポイントで表示されます。

図:この指標が緑色になるように色々チャレンジ

WordPressプラグインで調査

WordPressにプラグインで追加した形で特に「DBのクエリパフォーマンス」を測定する為のプラグインとして、Query Monitorがあります。さらにアドオンなども用意されているようです。

インストールすると上部の管理バーに数値と色合いが表示される仕組みで、数値は左から生成時間、メモリ量、クエリ実行時間、クエリ回数が表示され、あまりにも遅いと「赤色」で表示されるようになっています。プラグインなどによるDBアクセスなどもあまりにも多いとここがボトルネックとなるのがよくわかります(どのプラグインがボトルネックになってるか?が何回も測定するとよくわかります。

基本、表示したいページを開けば自動計測されます。細かいオプションや設定が沢山あるので、突き詰めたい人は入れておくと良いでしょう。

図:DBアクセス量は表示に影響が大きい

その他

なぜスピードが重要なのか?

Pagespeed InsightやSearch consoleのエクスペリエンスでもいろいろな指標の結果が表示されていますがこれらが、直接Googleの検索結果の優先度に影響しているわけではありません。人気のあるコンテンツならば表示がモッサリしていても見てもらえるでしょう。しかし、SNSなどでも勘違いしてるSEO対策の人がいますが、「数値が直接GoogleのSEOに影響を及ぼすことはなくても、結果的にSEOには影響がある」ということ。

人が待てる時間というのは、とある計測では3秒と言われています。それ以上遅延する場合にはページから離脱したり、結果的に非参照リンクとして他のページからも参照されなくなったり。故に直接ではなくとも間接的にGoogleの検索結果の優先度に大きく影響していきます。表示スピードが遅くて良いことなど1つもありません。自分自身の行動を鑑みても、やはり遅いページは速攻で閉じてしまいます。

図:デスクトップ側は最適化しやすい

雑感

プラグイン排除によって、トップページに新着であったり、固定ページのYet Another Related Pluginによる関連リンクの表示、カスタム投稿タイプのエントリーの表示、スポンサーリンクの表示自体がなされていない。これらを後で装備し直そうと思う。

確かにVX All in one Expansion Unitプラグインはお手軽ではあるものの

  • それぞれの専門機能は専門のプラグインのほうがパフォーマンスが良い
  • Adsenseに至っては何の役にも立たないどころか、サイトパフォーマンスを落とす結果につながってる
  • 殆どの機能が専門プラグインで代替可能

という事で、手軽さの変わりに正直かなりウェブサイト運営に於いてはちょっと使えないなぁという印象(今回もカスタム投稿タイプの為だけに残している状態)。Jetpackの件もそうなんですが、多機能って正直いいことばかりじゃない。

※しかしここまで手間の掛かるチューニングしないとまともにスピード出せないWordPress。。ブロックエディタ装備よりもまず、こういった手間掛からず軽量化できるようにしてほしい。

関連リンク

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください