前回に続いて弊ブログのPV激減の原因を調べていたところ、Google Search Console の ページエクスペリエンス において、ある日突然全ページが「改善が必要」と判定されて2ヶ月経過していました。その原因を探すと共に、 キャッシュ 系の WordPress プラグインを導入してみます。
ページエクスペリエンスの良好URLが0のまま放置
Google Search Consoleでは普段、ページがインデックスから弾かれていないかは適宜チェックしているのですが、メニュー下方にあるページエクスペリエンスはあまり気にしていませんでした。
日に日に落ちてゆくPVの原因を探して、ページエクスペリエンスの項目を確認してみると、良好URLが皆無と見なされて2ヶ月経過していました。
図01.良好URLが0のページエクスペリエンス
その理由はLCPの2.5秒超問題。PC向けでは全ページが「改善が必要」と判定される事態に。
図02.全ページ改善が必要と判定
モバイル向けは、まだ6割程度生き残っていました。
図03.モバイル向けは良好URL6割生存
PageSpeed Insightsでブログトップページを計測
対策を考える前に、GoogleのPageSpeed Insightsで弊ブログトップページを開くのに掛かる時間を計測。
実際のユーザーの環境で評価するの項目 は、過去1ヶ月ほどの間に実際にサイト訪問者がページを開くのに要した時間を表していて、やはりLCPは2.7秒掛かっていました。
図04.実際のユーザーの環境で評価する
その下にある パフォーマンスの問題を診断する が今回の計測結果なので、ここで現在のパフォーマンスを確認。
図05.パフォーマンス診断 改善前
ホスティング現状確認
本記事執筆時点で弊ブログはレンタルサーバ大手ロリポップの安価なサービスプラン、ライトプラン（月額220円）で運用しており、PHPやmysqlの仕様は以下に示すようにエントリーレベル。
- PHP : 7.4 (CGI版)
- mysql : 5.1
LightSpeed対応のハイスピードプラン（月額550円）へのアップグレードで、おそらくパフォーマンスが改善されることは分かっていますが、現時点でやれることを探るのが本記事の主旨です。
ちなみにサーバ上でキャッシュを保持するロリポップアクセラレータは当初より有効にしています。
図06.ロリポップアクセラレータ
対策1) JetPackの画像読み込みをスピードアップ
WordPressのJetpackプラグインにある、サイトアクセラレータは以前から利用していましたが、対象を静的ファイルにとどめていたので、これを画像にも適用してみたところ、
図07.Jetpack サイトアクセラレータ
パフォーマンスに大した変化は見られず。一方でページ右下に貼っている、ブログ村PVランキングのバナー画像までキャッシュされてしまい、アクセス数が取得できない弊害に見舞われたことから、画像への適用は再び無効にしました。
|
1 2 3 4 |
キャッシュ無効時） <img src="https://blogparts.blogmura.com/parts_image/user/pv########.gif" title="PVアクセスランキング にほんブログ村" alt="PVアクセスランキング にほんブログ村" width="160" height="87" loading="eager"> キャッシュ有効時） <img src="https://i0.wp.com/blogparts.blogmura.com/parts_image/user/pv########.gif?resize=160%2C87&ssl=1" title="PVアクセスランキング にほんブログ村" alt="PVアクセスランキング にほんブログ村" width="160" height="87" data-recalc-dims="1" class="jetpack-lazy-image jetpack-lazy-image--handled" data-lazy-loaded="1" loading="eager"> |
対策2) facebook公式ページへのバナーウィジェットが犯人
先ほどのパフォーマンス診断結果（図05）には内訳が続いているので、その中にある JavaScriptの実行にかかる時間の軽減 という項目に注目してみると、Google関連のスクリプトが多いのは仕方がないのですが、facebookのスクリプトは解せません。
図08.JavaScriptの実行にかかる時間の軽減
と、ここでfacebookに開設した弊サイト公式ページへのリンクバナーを、ページ右下に追加したのを思い出しました。
図09.fb公式ページへのバナー
これはJetPackプラグインが生成してくれるウィジェットを利用したもので、
図10.Jetpackのウィジェット機能
単純なリンクバナーだったら良かったのですが、中で複雑なことをしてまで必要な代物でもないので削除しました。
図11.fbページウィジェット設定
対策3) キャッシュ系プラグインを導入
さらにページ読み込みの高速化に有効な、キャッシュ生成プラグインのW3 Total Cacheを導入します。
（なお、導入に際し、上述のロリポップアクセラレータは無効にしました）
プラグインをインストール、有効化すると wp-config.php を編集できないエラーが現れたので、
図12.wp-config.phpを編集できないエラー
ガイダンスに従い、次のスクリプトを wp-config.php へ追記しておきます。
|
1 2 |
/** Enable W3 Total Cache */ define('WP_CACHE', true); // Added by W3 Total Cache |
W3 Total Cache 一般設定
数多くあるキャッシュのうち、一般設定でどれを有効にするか取捨選択します。
いくつかのページを複数の環境で実際に試しながら、最終的に次の3つのキャッシュを有効にしました。
- ページキャッシュ
- 圧縮
- ブラウザーキャッシュ
図13.有効にしたキャッシュ
一方、500エラーが出てしまうので、以下のキャッシュは有効にしませんでした。
- データベースキャッシュ
- オブジェクトキャッシュ
図14.無効にしたキャッシュ
この辺りはホスティング環境にもよるので、トライアンドエラーで各々のサイトに合った設定を見つけるしかなさそう。
W3 Total Cache ページキャッシュ設定
キャッシュするページの種類はデフォルトのままで、管理者やバックアップ関連はキャッシュ対象から除外。
図15.ページキャッシュ一般設定
ページアクセス前にキャッシュを生成するプリロードは、試しに有効にしてみたところ、大した負荷でもなさそうなのでそのままにしています。
図16.ページキャッシュのプリロード
ページキャッシュのパージポリシーは、記事がポストされたり編集されたりした際に削除するページキャッシュを指定するものです。デフォルトに加え、日次・月次・年次の各アーカイブページもパージ対象に加えました。
図17.ページキャッシュのパージポリシー
W3 Total Cache ブラウザーキャッシュ設定
ブラウザキャッシュの設定では、 一般 項で次の項目にチェックを入れたのみ。
図18.ブラウザキャッシュ一般設定
W3 Total Cache キャッシュグループ設定
キャシュグループ設定は実はあまり理解できていませんが、ユーザーエージェントの2つのグループにチェックを入れて有効化しました。
図19.キャシュグループUA設定
PageSpeed Insightsで改善効果を確認
しばらく経過してから再びPageSpeed Insightsで計測してみると、数値がだいぶ改善していました。主にキャッシュの効果でしょう。
図20.パフォーマンス診断 改善後
Google Search Consoleのページエクスペリエンスも再検証の結果が反映されて、良好URLが復活してくれました。
図21.ページエクスペリエンスも改善
果たしてこれでPVは元に戻るのか、数ヶ月見守りたいと思います。
