サイト表示速度の高速化

投稿日:

前々回の記事にて予告しておいた当サイトの表示速度の高速化なのですが、1ヶ月以上かかってしまいましたがどうにか結果を出すことができたので、今回の記事はその備忘録というか作業記録です。

一口に「高速化」と言っても実際に行なった作業は多岐に渡るので、今回の記事も長くなりそうです…(-_-;)
 

さっそく取り掛かっていきたいところなのですが、その前に前回の記事「Contact Form 7 を Akismet と連携」にて行なった問い合わせフォームからのスパム対策の後日談を少し。

前回 Contact Form 7 を Akismet と連携させたことにより、毎日来ていたスパムがパタリと止んだのですが、1日半経っても「ブロックしたスパム」数には変化が無かったのです。
これではこのカスタマイズの効果でスパムをブロックできたのか、たまたまスパムが送られてこなかった日だったのかも判別が付かず、なんだかモヤモヤした締めとなってしまいました。

それからちょうど1週間(この記事執筆時)が経ち、改めて Akismet のページを見てみると、なんと「ブロックしたスパム」数が20件も増えていました!

スパムフォルダーには1件も入っていないことから、これらが全て Contact Form 7 製の問い合わせフォームから送られてきた物であるというのは間違いないので、現在進行形で問い合わせスパムが送られてきているという事ですね。

こちらが何の労力も無しにスパムをブロックしてくれるのはありがたいですが、スパムが送られ続けているという事実は変わってませんので、やはり「reCAPTCHA」とも併用し、そもそもスパムを送らせないというのが最善策でしょうか。

ま、今はサイトの高速化が最優先なので、とりあえずの対処としては充分でしょう。
 

『PageSpeed Insights』で現在の点を確認

さて、今回サイト表示速度の判断基準とするのは、おなじみ『PageSpeed Insights』です。 このサイトでも何度か記事に書きましたね。

まずは今までの点数を再確認しておきましょうか。

初めて PageSpeed Insights を利用したのは、「『PageSpeed Insights』でサイトの表示速度をチェック」の記事。 執筆日は去年の7月。 もう1年以上前ですね。 ……いつまでこのサイト作ってんだか。

パソコン:59~(65)~74
モバイル:50~(60)~72

( )内の数字は複数回計測し、最もよく出た数値。 「最頻値」というらしいです。

合格ラインは80点以上と言われていたので、この結果を見てショックを受けたのを覚えています(-∀-`;)
 

その翌日の記事、「『EWWW Image Optimizer』プラグインで画像を圧縮」にて2回目の計測を行ないました。 ……この頃は毎日更新とかしてたんだなぁ。

この時は記事タイトルの通り、画像圧縮プラグイン「EWWW Image Optimizer」を使用しての点数アップを試みました。

パソコン:61~(73)~81
モバイル:63~(63)~??点

画像圧縮はかなり効果がありましたね。 ??点は記録漏れです。

81点でもまだ緑色にならないことに驚きましたが、現在とは基準が違っていたみたいです。
今は60点以上でオレンジ、80点以上で緑になるっぽいです。
 

さらに3日後、「見出しタグのリデザインと『Jetpack』の再設定」の記事にて、3度目の計測を行ないました。

ここでは多機能プラグイン「Jetpack」から、デフォルトでオンになっていた使用予定の無い機能をオフにする事での点数アップを期待しました。

パソコン:72~(75)~81
モバイル:65~(65)~78

大したことはやっていなかったので、ダメ元ぐらいの気持ちだったんですが、確実に結果が出ていますね。

 

……とまぁここまでが過去の記録。 これ以降は PageSpeed Insights でのチェックは行なっていませんでした。

あれから約1年後となる7月1日、4度目の我が『ガンプラ気分』の表示速度チェックです。

 PageSpeed Insights

 PageSpeed Insights

パソコン:67~(69)~71
モバイル:36~(41)~59

……と、いう結果になりましたとさ…

PC・モバイル共に下がっていますね(T-T) 特にモバイル。 ヒドイ有様です。
 

このままではスマホユーザーはせっかく訪問してくれても即離脱、ってなことになりかねません。

実際、自分でスマホからこのサイトを見てみても、以前より明らかに遅くなってます。
私ならこんなサイト見続けようとは思えませんね……

 

ロリポップ「コンテンツキャッシュ機能」

さーて、当サイトの現状も分かったところで、いよいよ本題である「サイト表示速度の高速化」に取り掛かっていきますか。

最初に行なうのは、以前の記事にて予告しておいた通り、ロリポップレンタルサーバーの新機能「コンテンツキャッシュ機能」とやらを試してみます。

この機能自体はβ版として既に提供されていたらしいのですが、私がサイト高速化に着手しようとしていた正にそのタイミングで正式版がリリースされたとのことなので、ありがたく使わせてもらうとしましょう。
 

公式サイトの触れ込みによりますと、(細かい原理はよく分かりませんが) WordPress が最大24倍速くなる、だそうです。
しかも使い方は設定画面からワンクリックするだけ。

若干胡散臭い気もしますが、設定も解除もワンクリックで済むならまずはやってみましょうか。
 

……でコンテンツキャッシュを有効化してみたんですが、自サイトを確認してみても体感では特に速くなったという感じはしないですね。 全く。

※反映までに最大5分間かかります」の注意書きの通り時間も充分空けていますし、これではキャッシュが機能しているのかどうかも分かりません。

後にサイトのカスタマイズをした時に分かったんですが、サイトの更新作業後すぐに自サイトを(ログオフ状態で)見てみたところ、更新内容が画面上に反映されていませんでした。
これがネットをやっていればおそらく誰しもが聞いたことがあるであろう「キャッシュ」というヤツですね。
 

それでは PageSpeed Insights でコンテンツキャッシュ機能によるサイト表示速度高速化の結果を見てみましょう。

……結果は変化無し

まぁ、なんとなくそんな気はしてましたけどね……
ボタン一つポチった程度で劇的に速くなるとか、んな都合のいい話……
 

愚痴ってもしょうがないので、サイト高速化について書かれているサイトを色々と見て回ったところ、どうやらこの「サーバー側のキャッシュ機能」とやらは「やった方がマシ」という程度のものらしいです。

参考サイトを読み進めると、なんか「キャッシュ」にも様々な種類があって、サイト高速化に大きく貢献するのは「ブラウザ側のキャッシュ」だそうです。

しかしこの機能を実装するためには、コードを書き込んだり、プラグインを使用したりと多少手間がかかりそうだったので、私は後回しにすることにしました。
 

画像読込遅延(Lazy Load)

サーバー側のキャッシュ では効果が見込めなかった為、次の施策といきましょう。

次に試すのは「画像読込遅延」「Lazy Load」とも呼ばれるみたいです。

この機能はまぁ大体字面で分かるでしょうが、画面外の画像の読み込みをスクロールされるまで後回しにすることでページの読み込みを速くするというものです。

参考サイトによるとサイト表示高速化において必須級の機能だそうなので、これは期待が持てそうです。
 

Lazy Load系プラグインを使用することでも対応可能ではあるのですが、私が利用していますWordPressテーマ『AFFINGER4』ではデフォルト機能として画像読込遅延が備わっていますので、管理画面よりちゃちゃっとチェックを入れるだけで実装できます。

初めて使う機能なのですが、どうやら「記事エリアのみ」と「サイト全体」から選択できるようです。
 

とりあえず「記事エリアのみ」で適用させてみました。

サイト表示を確認してみたところ、明らかに体感速度が上がりました!!

しかしスマホから見た時の画像の読み込みがちょっと遅いように感じます……
もうちょっとスクロール位置の低いとこから表示され始めてもいいんじゃないかなーと。
 

それでは PageSpeed Insights で点数をチェック。 今回は改善できたでしょう。

……と思ってたんですが、点数には変化無し

うーーん、なんなんでしょ?
まー体感では表示速度が上がったので、一応は良しとしておきましょうか。

PageSpeed Insights の攻略法(?)を載せているサイトでも、最終的に重要なのは体感速度であって、PageSpeed Insights で高得点を取ることが全てじゃない的なこと言ってますしね。
 

一応、画像読込遅延を「サイト全体」にまで適用してみましたが、PageSpeed Insights の点数には変化無し。

トップページのサムネイルまで遅延読み込みされるようになりはしましたが、一覧画面では目的の記事までスクロールして利用するでしょうから、画像がいちいち遅れてくるのはやや利便性が悪いように感じます。

遅延読み込みされる画像の表示が遅めなので、ゆっくりスクロールするであろう記事エリアに限定した使い方のほうが良さそうですね。
 

『Test My Site』でモバイルサイトの表示速度を確認

サイトの表示速度を確認するにあたって、今までは『PageSpeed Insights』しか使っていませんでしたが、調べていく内に『Test My Site』という Google のツールがあることを知りました。

こちらはモバイルサイト限定ではありますが、サイトの読み込み速度を計測できます。

PageSpeed Insights だと計測されるのは「サーバーの応答時間」なんですよね。
これって多分ページが最初に表示されるまでの時間のことだと思うんですよ。
私が知りたいのはページが全て表示され終わるまでの時間。 ウチのサイトは特にコレが遅いのでね。
 

では早速 Test My Site を利用してみましょう。

Test My Site

結果は7秒。 「普通」だそうです。

意外ですね。 絶対遅いと思ったからこそ今回のブログカスタマイズをしている訳ですから。
 

続けて「同じ業種内の比較」の項目を見てみましょう。

Test My Site

この『ガンプラ気分』は趣味サイトなので、比較業種は[趣味、レジャー]を選択。

「普通」の評価が得られるのは6~8秒だった場合みたいですね。
 

PageSpeed Insights でも緑点(80点以上)を目指そうと言われているので、この Test My Site でも緑点となる5秒以内を目指していきたいですね。
 

「Plugin Load Filter」プラグイン

さて、サーバーキャッシュでも画像読込遅延でも PageSpeed Insights の点数には変化が見られなかったので、次なる施策を考えねばなりません。

サイトの高速化において指針となるのは、やはり PageSpeed Insights の分析結果画面に表示される最適化についての提案の項でしょう。

私も過去の記事でここを参考にサイト表示速度の改善を試みました。
その時にやったのは「画像を最適化する」の1項目のみでしたが。
 

10項目ある「最適化についての提案」の中で、適用済みの最適化となっていたのは「リンク先ページのリダイレクトを使用しない」と、「表示可能コンテンツの優先順位を決定する」の2項目のみ。

その他の項目に関してはパソコンとモバイルで多少の差異はあるものの、ほとんどの項で問題があるっぽいですね……

っていうか「画像を最適化する」に関しては画像圧縮プラグインで対処したはずなんですが、まだ圧縮が足りないご様子。
調べてみると、ここは他の人も残ったまんまにしても許容範囲内っぽいんで、PageSpeed Insights で100点を狙ってるとかじゃない限り、さほどナーバスになる必要もなさそう。
 

で、「最適化についての提案」を1つずつ見ていき、合わせて修正方法を確かめていって、とりあえず簡単に対処できそうなとこから手を付けていこうと思います。

細かく見ていくと、「スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript / CSS を排除する」の項で挙げられているファイル名の中に、“contact-form-7” の記述を見つけました。

これはもう見たまんまプラグイン「Contact Form 7」の事ですよね?

どっから手を付けていきゃいいのかも分からんような状況なんで、前回 Contact Form 7 をいじったばかりってこともあり、まずはここから修正していくことに決めました。

 

早速ネットで情報収集してみると、Contact Form 7 の公式サイトにてコレについての解決案と思しき記事が載っていました。

公式必要な場合だけ JavaScript とスタイルシートをロードさせるには | Contact Form 7 [日本語]

ここによると、Contact Form 7 では問い合わせフォームを設置したページだけじゃなく、全てのページにて読み込みが行なわれているのだそう。

そしてそれを解決するためのコードも合わせて掲載されてはいたのですが、私には難しくてよく分かりませんでした( ´△`;) …なんか前にもこんなことあったような?

 

仕方が無いので別の案を探してみる。

すると、ページ毎に必要なプラグインのみを読み込む事ができるという今の状況にピッタリの機能を持った WordPressプラグインを発見しました!!

それが『Plugin Load Filter』! しかも日本製のプラグインです。
 

この Plugin Load Filter を使用することで、WordPress にインストールし有効化している全プラグインに対し、個別にフィルタをかけることで読み込ませるページをかなり細かく設定できるようになります。

フィルタは【URLフィルタ】と【Page Type フィルタ】の2つに大別されますが、URLフィルタは「エキスパート用」と書かれており上級者向け機能っぽいです。 私もここは利用していません。

なので【Page Type フィルタ】をメインに使っていく事になる訳ですが、これには[Admin Page]と[Page Type]の2タイプのフィルタがあり、どちらかを選択してフィルタリングします。
どちらも適用させない場合は[Normal Mode]となり、通常通りにプラグインが読み込まれます。

さらに[Page Type]に設定した場合はデバイス、ページタイプ、投稿フォーマット、カスタムポストタイプ等に細分化されたフィルタを別個に設定していくことになります。

また、【Page Type フィルタ】では個別ページ毎に有効化するプラグインを選択することも可能です。
Contact Form 7 を問い合わせページでだけ読み込ませたいという今回の場合にはこれを利用することになります。
 

ザッと機能を書き出してみましたが、最初はまるで意味が分かりませんでした。
やれることはまぁ分かるのですが、具体的にどうフィルタリングすればいいのかがサッパリ。

[Page Type]に設定したプラグインは一度無効化されてしまうため、その後に適切にフィルタリングしないとそのプラグインは機能しなくなってしまいます。 なので高速化したいからとテキトーにフィルタかけてきゃいいとはいきません。

以下、公式より抜粋した一文

設定はちょっと面倒かも知れませんが、うまく設定することが出来れば、プラグインの読み込みを減らし、ページ表示を高速化出来るのでぜひチャレンジしてみてください (^^)

とあるように、サイト高速化のためにはこのちょっと面倒な作業をこなさねばなりません。
 

私は自分でコード書いたりするような技量は無いため、サイトのカスタマイズの大半をプラグインに頼ってきました。
この時点でインストールし有効化しているプラグインは19個(Plugin Load Filter含む)。

サイトが重くなる要因として必ず挙げられるのがプラグインの入れすぎ問題。
この Plugin Load Filter はプラグインを多用する人にこそ効果を発揮するらしいので、頑張って設定していきましょう。

とは言っても、私にはそれぞれのプラグインがどう動作しているのかなんてまるで分かりませんので、【Page Type フィルタ】を[Admin Page](管理モードのみで使用)か[Page Type](特定のページのみで使用)かのどちらに設定すればいいのか判断が付きません。
 

そこで私はネットで Plugin Load Filter を使用している人の記事を探し、フィルタの設定画面のスクショの中から自分が使用しているのと同じプラグインを見つけてフィルタ設定の際の参考にするというクソ面倒くさい手を取ることにしました。

Plugin Load Filter はサイト表示高速化において必須級として紹介されているにも関わらず、どうにも情報が少ないですね。 いまいち知名度が低いのか、なんか知る人ぞ知るって感じの扱いです。

それでも有名どころのプラグイン(Contact Form 7とか)ならば、“Plugin Load Filter + ○○(プラグイン名)” で検索すれば参考になる記事が出てきたりします。

残りは “Plugin Load Filter” で画像検索してフィルタ設定画面のスクショの山から目的のプラグイン名を目を皿のようにして探すだけですね(;´ェ`)

 

そんなこんなで当サイトで使用中のプラグイン18個に対してのフィルタリングがなんとか完了したのですが、各フィルタが正しく設定されているのか自信が無いので、詳細な設定に関しては割愛させて頂きます。

ただ、Plugin Load Filter の解説サイトと同じように設定したのに上手くいかなかったもの、他の解説サイトと食い違いのあったもの等、設定に注意の必要なプラグインに関してだけは記載しておこうと思います。

●「BackWPup」:[Admin Page]フィルタではエラーが出てバックアップに失敗するとの報告あり。

●「Broken Link Checker」:[Admin Page]フィルタだとリンク打ち消し線(←こういうの)はCSSで制御されてる為表示できなくなる。 また、500エラーが発生し修正ができない。

●「Category Order and Taxonomy Terms Order」:[Admin Page]フィルタだとサイト表示上のカテゴリーの並び替えが反映されなくなる。

●「Google XML Sitemaps」:[Admin Page]フィルタではエラーが出てサイトマップが送信されなくなるとの報告あり。

●「Jetpack-Site Stats(サイト統計情報)」:[Admin Page]フィルタだとアクセス数がカウントされなくなる。

●「Simple Local Avatars」:[Admin Page]フィルタだとサイト表示上のプロフィール画像が反映されなくなる。

以上が解説サイト通りの設定では正常に機能しなかったプラグインです。
※これらはあくまで私の環境下での話です。 Plugin Load Filter の公式サイトにも書かれている通り、フィルタを設定する度にプラグインがそれまで通り機能しているか動作確認を行なうようにしましょう。

私は使用プラグインが多かったこともあり、このフィルタ設定→動作確認の繰り返しにかなりの時間を費やす事となりました。
中には初期設定後時間が経っていたことでプラグインがアップデートされ色々と変わっていたりして確認に手間取ったものもありましたね。

今回のサイト表示高速化のカスタマイズにおいて一番時間がかかったのもこの作業でした。

 

さ~て、そんじゃ Plugin Load Filter の設定も終わったところで、PageSpeed Insights で点数を確認してみましょかね。

――結果は変化無し

ど、どういうことだってばよ?
 

実は PageSpeed Insights は一つプラグインをフィルタリングする度に毎回点数を確認していたんですよね。
ところが点数にはほとんど変化がありませんでした。

私は最終的には8個のプラグインにフィルタをかけたのですが、全く効果が無いなんてことがあるのでしょうか?

ネットで Plugin Load Filter を利用している人は皆口を揃えて PageSpeed Insights の点数が上がった!とスクショ付きで載せていたというのに……!
 

もっとガンガンフィルタリングしていった方が良かったんですかねえ?

でもプラグインが動かなくなったら嫌だし、公式でも

動作条件が不明のプラグインまでフィルタする必要はありません。設定するか迷うプラグインは通常ロードのままにしておくことをお勧めします (^^)

と言ってますし、いくら高速化のためとはいえ、サイトに不具合出す訳にはいかないし……
 

あ、でも当初の目的だった「スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript / CSS を排除する」で指摘されてた “contact-form-7” の記述は消えていました

ただ、その後代わりに “responsive-lightbox/fancybox” を含むファイルが指摘されるようになりました。
これはプラグイン「Responsive Lightbox & Gallery」のことで間違いないので、このプラグインをフィルタリングしておくことでこちらも解消できました

ところがぎっちょん、今度はま~た別のファイルが指摘されていました…… 何このイタチごっこヽ(`皿´)ノムキ~
このファイルはCSSのようですが、どこを指摘しているのか私にはサッパリ分からんかったので、もう放って置くことにしましたとさ。
 

そうそう、PageSpeed Insights と一緒に Test My Site でも計測していました。

コチラの結果は6秒8秒
普通」の評価の範囲内で±1秒ほどは誤差があるっぽいですね。

まぁこっちも変化無しと見ていいでしょう。

 

私では使いこなせなかったせいかサイト表示速度の改善には繋がらなかったみたいですが、『Plugin Load Filter』は評価も高く、日本製なので言語の心配もありませんので、プラグインの多用による WordPress の重さに悩んでいる人にはぜひ使ってもらいたいですね。

個人的には WordPress に標準インストールされててもおかしくないぐらいの必須プラグインだと思います。

たくさんプラグインを入れてからまとめて設定すると私のように大変面倒くさいことになるので、早めのご利用をオススメします(笑)
 

不要プラグインの削除

先ほど Plugin Load Filter のフィルタ設定後の各プラグインの動作確認をほぼ全ての有効化プラグインに対して行なった訳ですが、その際にちょっと見直した方がいいんじゃないかな~的なものもいくつかあったので、要らないプラグインをバッサリ削除していってしまおうと思います。
 

●「Edit Author Slug」:Plugin Load Filter にて[Page Type]フィルタを適用することにより、プラグインは一時的に無効化されるはずなんですが、このプラグインはこの状態でも何故か通常通りに機能していました。

変だと思って調べてみると、どうやらこの Edit Author Slug は設定完了後アンインストールしてかまわないらしいです。 んじゃ遠慮なく削除で。

●「Jetpack-通知」:多機能プラグイン「Jetpack」の機能の内の一つ。 WordPress の管理ツールバーからサイトのアクティビティを観測・管理する機能。

投稿コメントの通知や、サイトのアクセス数が急上昇していることなどがツールバーからいつでも確認できる。
個人的には便利な機能だと思っていたのですが、特に無くても困らない事に気付いたので削除。

●「Jetpack-ウィジェット表示管理」:こちらも Jetpack の中の一つ。 ページ毎に表示するウィジェットをコントロールできる。

何気にすごい機能なんじゃないかと思っていたけど、現時点では使用していなかったので削除。
 

とりあえずこの3つを削除。 基本的には「あると便利」程度の物は思い切って消して、「ないと困る」という物だけを残す感じにしました。
断捨離って苦手なのよね。 ガンプラの余ったポリキャップとか全部取っておいてるわ。
 

あとはインストールしたけど有効化していない、「いつか使うかも」的なプラグインも3つほどあったのでこれらも一応アンインストールしておきました。

この無効化中のプラグインがサイト表示速度に悪影響を与えているのかはネットを調べても分かりませんでしたが、セキュリティの面から残しておくべきではないと言っている人がいたので、念のため削除することに決めました。
まぁ本当に必要になった時に改めてインストールしなおせば良いでしょう。 無料なんだし。
 

大したことはしていませんが、PageSpeed Insights の点数を確認してみました。

やっぱり点数には変化無し

ここまでくるとなんかもう何やっても効果無いんじゃないかと諦めムードが漂ってきてますね(>_<)
 

「Jetpack-Photon」

プラグイン「Jetpack」の設定を見直した際に、昔使おうと考えていた Jetpack の機能の一つ、「Photon」の存在を思い出しました。

「Photon」とは、「CDN(コンテンツ・デリバリー・ネットワーク)」だとか呼ばれ、画像などの容量の大きいファイルをキャッシュサーバーから読み込ませるサービスで、特に画像を多く使用しているサイトで高速化の恩恵を受けられるらしいです。

このサイトは写真メインのギャラリータイプのブログとなる予定なので、ゆくゆくは Photon も使っていこうかなと考えていました。 Jetpack も既に使っていましたしね。
 

しかし、AFFINGER4公式でも WordPress高速化の一案としてこのCDNが挙げられていましたが、同時に Photon のデメリットも提起されていました(外部サイトですが)。

この Photon のデメリットをいくつか挙げると、

・ 一部プラグインと相性が悪い
・ 画質が劣化する
・ 画像が見切れる場合がある
・ キャッシュは削除できず、残り続ける

などが指摘されていました。
 

私が特に問題視したのは1つ目の「一部プラグインと相性が悪い」。 この一部プラグインには、lightbox系、Lazy Load、キャッシュ機能(サーバー側含む)などが該当するようです。
このサイトでは lightboxプラグインを使用していた為、Photon の導入は見送ることにしました。

2つ目の「画質が劣化する」は言わずもがな、3つ目の「画像が見切れる場合がある」は WordPressテーマとの相性により起こる場合があるようです。

4つ目の「キャッシュは削除できず、残り続ける」は、CDN上でキャッシュされた画像は削除できないため、たとえ Photon を無効にしたとしてもネット上にはキャッシュ画像が残り続けるのだそうです。
CDNを利用したことのない私にはよく分からんのですが、なんか怖いですよね。

 

キャッシュプラグイン「WP Fastest Cache」

いよいよやれることが少なくなってきました。 そろそろ覚悟を決めてキャッシュに手を出さねばならないようです。
サーバーキャッシュは既に試したので、次はブラウザキャッシュですね。

ブラウザキャッシュには .htaccess へコードを書き込む方法もあるようですが、難しそうなのでまずはプラグインに頼ることにしました。
もうプラグインはあまり入れたくないのですが、こればかりは仕様が無いですね。
 

キャッシュプラグインには「WP Super Cache」や「W3 Total Cache」という名前をよく聞きますが、どちらも到底初心者に扱いきれる様な代物ではなさそうです。
ちょいと検索かけるだけで阿鼻叫喚の声が聴けることでしょう。

実はキャッシュプラグインには既に目星を付けてまして、「WP Fastest Cache」という物を利用しようと考えていました。
これは AFFINGER4公式でも勧められていましたし、ネットで評判を見ても「初心者にも扱いやすい」という触れ込みです。
 

WP Fastest Cache は(だいたい)日本語化もされていますし、設定画面も基本はチェックを入れるだけ。
中でも WP Super Cache や W3 Total Cache では難しいとされる「キャッシュのクリア」がワンクリックで可能という点が特に優れているとのこと。

ただし、無視できないデメリットもありまして、それが「モバイル版のキャッシュが作成できない」という点です。 モバイルページの表示速度の改善を目指していた私にとってはこれは大問題です。
ちなみにこの WP Fastest Cache には有料版となる「プレミアム版」が存在し、こちらではモバイル版のキャッシュを作成する機能が備わっています。
 

サイトの作成にこれ以上お金を出す気は無いので、とりあえず無料版でできるところまでやってみることにしました。

設定できる項目は色々とありましたが、私にゃ何がなんやら分かりませんので、万全を期して一つチェックを入れて表示を確認して PageSpeed Insights の点数を確認して Test My Site で速度計測して……を繰り返していくことにしました。

 

WP Fastest Cache の設定を始めて2つ目の項目(「言語」は除く)となる「Preload(プレロード)」にチェックを入れた後の PageSpeed Insights での点数確認の時でした。 1回目の計測では今まで通りの点数だったのですが、2回目以降の計測から、

パソコン:6771点→84
モバイル:3659点→89

と爆上がりしました!!!

これまでの PageSpeed Insights の計測では、サーバーの応答時間次第によって点数に振れ幅がありましたが、緑点となった2回目以降の計測からはブレがほとんど出なくなったので、おそらくキャッシュで作成されたページが読み込まれてるって事なんだと思います。 たぶん。
 

しかし、この時はこの結果に舞い上がっていてまるで気付きもしなかったんですが、この時計測されたモバイル版の計測結果画面に表示されていた当サイトのキャプチャ画面上には、設定していたはずのモバイル専用メニューが表示されていなかったんですよ。

後に何度も何度も計測し直してやーっと分かったんですが、この WP Fastest Cache 無料版で表示されるモバイルページのキャッシュはパソコン版のキャッシュの様です。
つまり、最初からモバイル用のキャッシュは作成されていなかったんですね。

「モバイルユーザーに対してキャッシュを表示しない」にチェックを入れない限り、モバイルページではパソコン用キャッシュしか表示されません。
 

私の使用している AFFINGER4 はレスポンシブテーマなので、パッと見はちゃんとできてるように見えますが、モバイル閲覧時のみ表示される機能、CSS等があった場合、それらは表示されなくなります。 私の場合は[スマホ用ミドルメニュー]がそれに当たっていたという訳です。

AFFINGER4公式でも言われていますが、このままだとモバイル閲覧時にアドセンス広告が二重表示されてしまう(おそらくPC用の広告が表示される為)そうなので、AFFINGER4 で WP Fastest Cache を無料版で使うなら、「モバイルユーザーに対してキャッシュを表示しない」にチェックを入れて素直にモバイル時のキャッシュは諦めた方が無難でしょう。

 

……さて、ぬか喜びを堪能したところで、「モバイルユーザーに対してキャッシュを表示しない」にもちゃんとチェックを入れて、他の項目を試していくとしましょう。

残るはコードやら何やらの圧縮機能のようです。
一つずつチェックを入れて確認していきましたが、サイト上にも点数にも特に変化は無し。

でも、PageSpeed Insights の「最適化についての提案」の項から、「HTML を縮小する」と、「CSS を縮小する」の2つが消えました。
点数への反映こそ無かったものの、効果はあったっぽいです。
 

そしていよいよ大本命、「ブラウザキャッシュ」にチェックを入れてみました。
すると……

パソコン:6771点→84点⇒92
モバイル:365989

と、さらに点数を上げることができました!!

……PCだけだけど。
モバイルは当然変化無し。 どうすりゃいいんだこれ?

 

さて、実は問題はこれだけではありませんでした。
合わせて確認していた Test My Site の方の計測結果が大変なことになっていました。

これまでは6秒8秒の範囲内だったのが、今回の WP Fastest Cache の動作確認中に、初の赤点となる9秒が表示されてしまいました(>_<)

さらにその後も、13秒16秒、仕舞いには18秒という数字を叩き出す始末……
 

これはあまりにもおかしいだろうと思い調べてみました。

てっきりキャッシュ関連をいじっていたのでコレが原因かと決め付けていたのですが、どうやらレンタルサーバーという物それ自体が原因だったみたいです。

レンタルサーバーは他の利用者とサーバーを共用している為、例え自分のサイトが1日辛うじて2桁のアクセス数のゴミクソサイトだったとしても、他の共用者のサイトでアクセスが集中しているとコッチまで遅くなってしまう、というのが仕様らしいのです。 …多分皆知ってただろうけど。

計測時に9秒を出した時は土曜、18秒を出した時は日曜夜だったので、たまたま他の共用者さんのサイトが賑わってたってことかな? 羨ましいねチキショー!!
 

この問題を解決するためには、もっと高性能のサーバーに移るしか解決法はなさそうです。
そんなんできるんだったら最初からそうしとるわっちゅー話なんで、現時点では解決策無しかなぁ……

ただこのままって訳にはいかんですね。 ここまでサイト高速化をやってきてモバイルの方に一切の改善が見られません。 ぶっちゃけ泣きそうです。
 

「YASAKANI Cache」

嘆いていてもいきなりサイトが爆速になったりするような奇跡は起きんので情報収集。
すると、「YASAKANI Cache」という妙ちくりんな名前のキャッシュプラグインを発見しました。

この YASAKANI Cache は名前からも何となく予想はつくでしょうが日本製。 しかも作者様はこの記事で Contact Form 7 のレンダリングブロックを解決してくれたプラグイン「Plugin Load Filter」を製作した方だったのです!
 

こちらのプラグインもやはり知る人ぞ知るって感じで情報が少なかったのですが、なんと YASAKANI Cache なら無料でモバイル用のキャッシュも作成できるらしいのです!!

日本製で無料だっつーんならもう WP Fastest Cache から乗り換えるしか手は無いわな!
 

……と思ったんですが、残念なお知らせが。

YASAKANI Cache はモバイル判定を “wp_is_mobile” で行なっているそうなんですが、私が使っている AFFINGER4 を含む STINGER系テーマでは、モバイル判定を “st_is_mobile” で行なっているらしいのです。
つまり STINGER系テーマではモバイルのキャッシュは使えないっぽい。

ネットにはその辺のコードを書き換えたり何やかんやすることで STINGER系テーマでも使えるようにしている人もいるみたいですが、当然私にはそんなカスタマイズはできんので YASAKANI Cache の使用は諦めざるを得ませんでした。

絶望の中で希望を見つけたと思ったらやっぱり絶望ですよ……

 

PHPバージョンアップ

どう足掻いても絶望状態を脱却すべく、今まで「難しそう」・「意味分かんね」と流し読みしてきた施策に手を出してみることにしました。
それがPHPのバージョンアップ…!

PHPってのは……えーっと……分かんね(´・ω・`)
なんかサーバー側で設定できる機能で、とりあえず「PHP7」にすりゃ速くなるんだとよ。 細けぇこたぁいーんだよ!
 

まずは今の自分のPHPのバージョンを確認してみましょう。
私は1年半ほど前にロリポップレンタルサーバーのライトプランを契約してから何もいじっていなかったので、[PHP5.6(CGI版)]となっていました。

プルダウンメニューを押すと、他の選択候補として[PHP7.1(CGI版)]というのが選べるようです。
 

(CGI版)というのが分からなかったので調べてみると、どうやら(モジュール版)というヤツの下位バージョンみたいですね。

モジュール版にした方が圧倒的に速いとの触れ込みですが、モジュール版は私の契約しているライトプランよりも上のプランからしか選べないので、今回は[PHP5.6(CGI版)]→[PHP7.1(CGI版)]へのバージョンアップを行なおうと思います。
 

基本的にはただ選ぶだけで良いみたいですが、公式サイトによるとパスワード形式が古い場合はエラーが出るだとか何とか。

他にも、WordPressテーマや各プラグインがPHP7に対応しているかを前もって確認しておいた方が良いらしいです。

…なーんか面倒くっさいですなぁ(-∀-`;)
AFFINGER4がPHP7に対応してるっぽいのは公式サイト内で何度か見かけた気がするので、問題はプラグインかぁ。

……ま、いっか。 別に確認なんかしなくても。
だってもうサイト表示速度改善のためにはコレやるしかないんだし。
退く道が無いんだったら進むだけよ。 エラーなんて出てから対処すりゃいいでしょ。
もう半ばヤケクソですよ。

 

というわけで特に前準備することなくPHPバージョンアップ開始。

案の定エラーが出ました。 「データベース接続確立エラー」。

これは公式サイトに載ってたやつですね。 案内の通りにデータベースのパスワードを再設定。
 

すると、ちゃんとサイトにアクセスできるようになりました。
パッと見サイト表示に変化は見られず、思っていたよりも遥かに簡単にPHP7にできたっぽい?

……と思ったのも束の間、他のページを見てみるとアクセスカウンターが表示されていません

さらに別のページを見てみると、なんとページが真っ白になってしまいました!!
やっちまった感!

でも真っ白になるのは特定の一ページだけで、他はふつうに表示されてるんですよね。 アクセスカウンターがたまに無くなりはするけど。
 

「PHP Compatibility Checker」

さて、PHPバージョンアップの前に現プラグインがバージョンアップ後のPHPに対応してるか事前に確認しておけという忠告を無視した結果、我がサイトの一部ページが真っ白になってしまうという現象が起きてしまいました。

しょーがねーので確認作業に入るとします(いまさら)。
 

と言ってもやり方は簡単で、「PHP Compatibility Checker」というプラグインを使うだけです。
これにより、指定バージョンのPHPに対するインストール中のプラグインの互換性が確認できます。

使い方に難しい点は無かったので割愛し、結果だけ。

 Unknown :BackWPup、EWWW Image Optimizer、Jetpack
 Warnings :Broken Link Checker(1)、WP Fastest Cache(4)、Hit Counter Max(1)
 Errors Hit Counter Max(4)

( )内の数字は警告・エラーの数。
 

案の定、という結果でしたね。 「Hit Counter Max」こそがアクセスカウンターを設置していたプラグインでしたので。

このアクセスカウンターは、過去記事「SNSボタンの設置とアクセスカウンターの導入」で結構頑張って入れた物だったので、消すのは残念で仕方ないんですが……
まぁアクセスカウンターなんて既に旧時代の遺物となりつつあるので、ここはスッパリ諦めましょう。

実はアクセスカウンターを消す事になるのは少し前から分かっていたんですよね。
具体的に言うとキャッシュを使おうと決めたあたりから。
 

キャッシュについてはほとんど何も知らない状態だったため、ネットで情報収集に明け暮れた訳なんですが、その中でキャッシュのデメリットというものについての記述がありました。

その内の一つが、正にアクセスカウンターだったのです。
もうちょい正確に言うなら、リアルタイムに更新され表示される機能全般のことみたいです。

画面上に変化があると、その変化した画面に対してキャッシュが再作成される必要があります。
アクセスカウンターのように頻繁に表示が更新されてしまうと、キャッシュがいくら作られてもすぐに新しいキャッシュを必要とするため、キャッシュを使っても逆にサイト速度が遅くなってしまう事もあるそうです。
 

なのでアクセスカウンターにはもう見切りをつけていました。 本当に残念ですが。

そうそう、「PHP Compatibility Checker」の Warnings の結果なんですが、こちらは無視してしまってもさほど問題は無いらしいです。
なんか現行バージョンのPHPでテストしてみた結果でもこの Warnings の警告は出てしまうとの事なので。

 

では「Hit Counter Max」を削除し、あと役目を終えた「PHP Compatibility Checker」も削除し、サイト表示が元通りになっていることを確認し、PHPバージョンアップ完了!!

体感では特に速くなったとは感じませんね……
まぁ廉価版である「CGI版」ってのじゃーそんなモンなのかもしれませんね。
 

だが重要なのは PageSpeed Insights の点数だ! いい加減にモバイルの点数を上げたい!!

PHPバージョンアップの結果……

パソコン:6771点⇒7384点(※キャッシュ停止)
モバイル:3659点⇒4076

と、PC・モバイル共に点数がアップしました!!ヾ(*´∀`*)ノ

あ、キャッシュ未使用時の純粋なサイトの表示速度を比較したかったので、WP Fastest Cache は無効にしておきました。
 

続いて Test My Site での計測結果はと言うと……

6秒8秒5秒6秒

と、初となる合格点(緑点)です!!
 

いや~… PageSpeed Insights も Test My Site も安定して緑点が出せるわけじゃーないとは言え、進展しましたねぇヽ(´ー`)ノ

モバイルの点数をもーちょい底上げしたいところですね。 なんだかんだまだ赤点出てますから(;´д`)

 

コードでブラウザキャッシュ・Gzip圧縮

長かったサイト表示速度の高速化もいよいよ最後の施策となってまいりました。
最後に試すのは、ブラウザキャッシュを .htaccess へコードで書き入れる方法。

ブラウザキャッシュはプラグイン WP Fastest Cache の設定でチェックを入れるだけで対応できてはいるのですが、無料版だとモバイル用のキャッシュが作成されないんですよね。

代案となる YASAKANI Cache も我が AFFINGER4 では使用できない。
だからと言ってこのまま諦めるという訳にもいきませんので、必死こいてネットで解決策を探し回りました。
 

すると、WP Fastest Cache について興味深い一文が。

それはこのプラグインの設定項目にある「Gzip圧縮」と「ブラウザキャッシュ」については、.htaccess にそれぞれのコードを書き込んでいるだけだというもの。

なのでこの2つを既に .htaccess に自分で書き込んでいる人はここのチェックは入れなくていいですよ~という注意書きでした。
 

ここでちょっと思ったわけですよ。

WP Fastest Cache のチェックで Gzip圧縮とブラウザキャッシュを設定しているからモバイルに対応できていないって事なら、このプラグインの力を借りずに自分で直接 .htaccess にコードを書き入れれば少なくとも Gzip圧縮とブラウザキャッシュだけはモバイルに対応させられるんじゃないか、と!!

コードについてはさっぱし分からんのですが、たぶん特別な書き方をしたりしない限りは、モバイルだけに適用させない、なんて設定にはならんと思うのですよ。

確証は全くありませんが、もうこれ以上はホントにも~~やれることが無いので、これに最後の望みを賭けるとしましょう。

 

一度に両方のコードを入れるのはリスクが高いので、まずは「ブラウザキャッシュ」用のコードをネットで探して入れてみるとします。
ブラウザキャッシュの機能がサイト高速化において絶大な効果を誇るのは既にプラグインの設定で確認済みですからね。

ネットには多くの人がこれらのコードを公開して下さっていましたが、私にゃ何がどう違うのかまるで分からなかったので、なんとなく良く効きそうという理由で見つけた中から一番長かったブラウザキャッシュ用のコードをコピペで .htaccess へ書き込みました。

しかし、PageSpeed Insights で確認してみても点数に変化は無し。
どうやらキャッシュが効いていないようです。 はて?
 

使用したコードが悪かったのかと思い、テキトーに違うやつに書き直してみる。

再び PageSpeed Insights で確認するも、やはり変化無し。

もう何がなんやらちんぷんかんぷんです。 こりゃもう諦めるしかなさそうだわな…
 

…と思っていたのですが、その翌日、なんとキャッシュが作成されていました!!

PageSpeed Insights で確認してみると……

PageSpeed Insights

PageSpeed Insights

パソコン:7384点⇒90
モバイル:4076点⇒89

と、WP Fastest Cache のブラウザキャッシュを使用していた時と同等程度の点数を出すことができました!!ヾ(*゚∀゚*)ノ

そして問題のモバイルのキャッシュなんですが、ちゃんとモバイル用のキャッシュが表示されていました!!

長かった……ついにやりましたよ……(ノ∀;`)
 

あ、なんで次の日にならないとキャッシュが作成されなかった(次の日になったらキャッシュが作成された)のかは、私には分かりません。

キャッシュには色々な種類があるようですが、その中のブラウザキャッシュってのは、一度開いたページをブラウザに保存しておいて、次に開くときにはその保存しておいたデータを使うことで高速化するとかいう物らしいので、初めて開くときには効果を発揮しないんだそうで。

もしかしたらその辺のブラウザキャッシュの仕組みによるところだったのかもしれません。
 

おっと、忘れるところだった。 Test My Site での計測結果も載せておきます。

Test My Site

ほい、5秒

キャッシュを使っていれば計測結果にブレはほとんど出なくなるようなので、今回のサイト表示速度高速化においての目標だった、合格点(5秒以内)圏内には無事入れた、と言っていいでしょうね。 あぁ…ほんと長かった……

ってか、5秒の読み込みで約1/5の人が離脱してしまうんですね……
いや、5秒っくらい待てない? 俺は待てる。(キリッ)

 

ではブラウザキャッシュはどうにかこうにか上手くいってくれたようなので、続けて Gzip圧縮もやってしまいましょう。

使用するコードはブラウザキャッシュのコードと一緒に公開されていた物を引き続きコピペさせて頂きました。
 

コードの追記後、サイト速度を計測してみましたが、特に変化は無し。
まぁ元々プラグインで Gzip圧縮していた時も何も変化ありませんでしたから。 こっちはついでみたいなもんです。

追記

ロリポップは最初から Gzip圧縮の処理が行なわれているらしいです。
記事執筆後、.htaccess から Gzip圧縮のコードは取り除きました。 その結果かどうかは分かりませんが、Test My Site で3秒が出ることもありました! たぶん偶然ですが(^^;

 

さて、ブラウザキャッシュ・ Gzip圧縮のコード書き込みも完了したことですし、一時的に停止していた WP Fastest Cache を再有効化しました。

これまでは参考サイトでも言われていた通り、全てにチェックを入れていましたが、自分でブラウザキャッシュと Gzip圧縮は対応させましたので、この2つの項目からはチェックを外しておきました。

WP Fastest Cache は盲目的に全部にチェックじゃなくて、自分が別途行なった処理に関してはチェックを入れないように気を付けましょう。
例えばプラグイン「AutOptimize」でコード圧縮を済ませているのであれば、当然コード圧縮関連のチェックは不要となってくるでしょう。
 

それではいよいよ最後となる計測です。

まずは PageSpeed Insights

PageSpeed Insights

パソコン:90点→92
モバイル:89

パソコンの点が以前の WP Fastest Cache の全チェック入れてた時の最高点数と同じになりました!
コード直書きでのブラウザキャッシュがちゃんと機能している証拠ですね!
 

そして Test My Site

 Test My Site

5秒4秒!!

さらに速度を縮めることができたようです!
どうやら WP Fastest Cache のコード圧縮の機能が効いてるっぽい?

 

「サイト表示速度の高速化」まとめ

は~~い、お疲れ、俺!!

PageSpeed Insights で90点前後、Test My Site で4秒も出せときゃ充分でしょ、もう。

正直もーなんも考えたくないんですが、記事も2万字を超え大分とっ散らかってしまったので、軽めにまとめて終わりにしようと思います。

 

今回やった施策の中で、PageSpeed Insights の評点アップに効果があったもの

●PHPバージョンアップ
●ブラウザキャッシュ

 
評点アップには繋がらなかったものの、体感速度の向上が見られたもの

●画像読込遅延
●(「Plugin Load Filter」)

「Plugin Load Filter」でのフィルタリングは、サイト表示速度よりも WordPress 管理画面の重さが和らいだように感じます。(気のせいかも…)

 

「まとめ」にしてしまうとあの作業量もこんな簡潔になってしまうんですねw

まー時間こそかかってしまいましたが、今回は結果を出すことができたので! 良しとしましょう!
 

んじゃーそろそろいい加減に、この『ガンプラ気分』の本運営を開始できそうですね……!

-ウェブサイト作成

Copyright© ガンプラ気分 , 2020 All Rights Reserved.