ワードプレスが遅い！
一言でワードプレスが遅いと言っても、たくさんの要因が考えられます。個別のサイトの何が遅いかという特定は、見てみないと何とも言えないところがあります。
ざっくり要因としてあげるとしたら、
- 重たいデータ
- 重たい処理
この二つのどちらかです。
ちょっと当たり前の事ドヤ顔で言ってみましたが、ワードプレスが重い！と言う方はどっちかが出来ていないワケです。
かなり長いんで、全部読むのがめんどくさい方は目次から特定の項目にスキップどうぞ。
表示の遅いサイトは何がヤバい？
「そりゃ、遅いより早いほうがイイに決まってるけど、具体的に何がヤバいの？」
ってところは気になりますよね。
UXの低下
UXってのは、ユーザーエクスペリエンス。
要するに、体験の事です。
ちょっと古い記事ですが。
操作開始時間が1秒のサイトと3秒のサイトを比較しても、3秒のサイトは1秒のサイトに比べ、ページビューが22％低下、コンバージョン率は38％低下、直帰率は50％上昇してしまうというデータがあります（増山氏）
https://webtan.impress.co.jp/e/2014/07/08/17757
サイト表示が2秒遅いだけで直帰率は50％増加らしい。
さらにさらに、天下のGoogleさん曰く、
モバイル サイトの読み込み時間が 5 秒を超えると利用をやめるユーザーが平均 74% に上りますが、モバイル ページの読み込み時間はまだ平均 6～10 秒もかかっています（Kinsta 調べ）。また Aberdeen Group の調査によれば、ページの読み込みが 1 秒遅くなるごとに、ユーザーの満足度は 16%、ページ ビュー数は 11% 低下します。
https://adsense-ja.googleblog.com/2016/10/blog-post.html
アドセンスの公式ブログですね。5秒かかったらサイトとしての価値が74％失われるって言われてるのと同じです。
これ、どう考えてもヤバいです。
SEO的に不利
さらにさらにさらに、天下のGoogleさん曰く、「スピードは検索結果に及ぼす」と2010年に明言している上に、2018年7月、表示速度に関するアップデートを実施することを発表。
The “Speed Update,” as we’re calling it, will only affect pages that deliver the slowest experience to users and will only affect a small percentage of queries. It applies the same standard to all pages, regardless of the technology used to build the page. The intent of the search query is still a very strong signal, so a slow page may still rank highly if it has great, relevant content.
https://webmasters.googleblog.com/2018/01/using-page-speed-in-mobile-search.html
要約すると、
- めっちゃ遅いページにだけ影響しまっせ。
- 影響するのはちょっとのクエリだけだよ。
- クエリとの関連性が最重要だよ。遅くてもいい記事は上にくるよ。
とは言っているものの、重要な「何秒かかったら遅いと判断するのか？」などは同ページ内に明示されておらず・・・。
まぁ総合的な情報から考えても「5秒以上はまぁまぁヤバい」って感じかと思います。
ワードプレスの弱点
ワードプレスの唯一に近いレベルの弱点が「ページスピードが遅くなりがち」ってことだと思います。
何と比べて遅いのか？と言われると、「静的なHTMLサイトと比べて」になってくるので、大抵の人は「いや、それはどう考えてもワードプレス一択」って話になるんですが(笑)
PHP（プログラム）による処理を挟むので、この辺は仕方ないですね。
自分のサイトの表示速度(スコア)を調べる
遅いとヤバい、と言うのは伝わったと思いますので、あなたのサイトの表示速度がGoogleにどの程度と評価されているのか、調べてみましょう。
Google アナリティクスで調べる
まずは一番気になる「Googleからの見え方」を確認します。
Googleアナリティクスの左側のメニューから、
行動→サイトの速度→速度についての提案
表示されたページの一番右の部分がそのページのスピードをスコア化したもの。
表示速度改善に着手する前のこのサイトはこんな感じ。
「？？？？」
「ZERO～♪」
0点のページがありますね。なんなんでしょうね。最高点のページでも42点って・・・。
とりあえず、ヤバいです。
ここで表示される数値は必ずしもアテになるわけではなく、平均読み込み時間なんかは割と表示されていないこととかも多いです。PV少ないからかな？
更に詳しくページスピードスコアを調べる「PageSpeed Insights」
先ほどのページの項目の中の「PageSpeedの提案」列の「合計〇個」の部分をクリックすると、別のウインドウが立ち上がり個別ページの現在のPageSpeedをチェックすることができます。
こんな感じのウインドウです。
ワードプレスの高速化 – 重いデータを軽くする
冒頭ではざっくりと、
- 重いデータ
- 重い処理
が原因であると述べましたが、まずは重いデータの処理をしていきます。
ワードプレスの中で重いデータは・・・
「大体、画像説」
もちろん画像以外がボトルネックになる可能性も全然あり得るんですが、普通にワードプレスで記事ばかり書いている人なんかは、余計なところいじったりしませんよね？
特段カスタマイズしていないのに、ワードプレスが遅いと来たら、ほとんどの場合は画像を適切に処理することで表示速度を大幅に改善できる可能性が高いです。
以下ではプラグインで重たい画像を処理する方法を紹介します。
【ワードプレス】画像圧縮プラグイン
この項では、画像処理に焦点を当ててワードプレスプラグインを紹介していきます。
ワードプレスに画像をアップロードする時キチンと圧縮処理してアップロードしている方はどのくらいいるでしょうか？
「やった方がいいのは知ってるけど、やってないわ。」
そんな方も多いのではないでしょうか？
ブログ作り始めてまだ間もない状況であればさておき、100記事200記事の全画像を圧縮して再アップロードなんて、考えただけで吐き気が止まりません。
EWWW Image Optimizer
このプラグインを使えば今までアップロードした画像の圧縮も一括で可能です。救世主です。
インストールはワードプレスのプラグインタブから検索するだけで一発です。
EWWW Image Optimizerの設定
有料版でしか使えない設定が割と多いですが、画像の圧縮等一切していない状況であれば無償版で十分に威力を発揮します。
圧縮率は「まぁ、ボチボチ」って感じですが、無料かつ制限なしですから、一番高効率かなと思います。
基本的にメタデータなどサイトでの表示に不必要な情報は削除した方がいいです。 Remove Metadata にはチェックを入れます。
後ほど専用のプラグインも紹介しますが、EWWW Image Optimizerには
Lazy Load （画像の非同期読み込み）を実装する設定が存在します。
色んなプラグイン入れたくない派の人にはこの機能だけでプラグインが一個減らせますのでうれしいですね。
既にアップロード済みの画像を圧縮する
既にサーバーにアップロード済みの画像を一括で圧縮するには設定ページ上部の一括最適化より。
注意してほしいのはリサイズタブで、画像の最大横幅と高さを指定できるのですが、一括最適化する場合はメディアライブラリ全ての画像にその設定が適用されるということです。
例えばヘッダ画像用に横幅一杯の1920pxを覆い切る画像なんかを使っていて、それがメディアライブラリ内に入っているようであれば、一括処理時にリサイズタブで指定した値に変更されてしまいます。
「特段大きな横幅の画像なんか使ってないよ」と言う方は、基本的に画像の最大横幅はメインカラムの最大幅と同じに設定しておくと無駄がなくなって最高効率で圧縮できるのでいいと思います。
テーマによると思いますが、768pxとかの事が多いかなと思います。
PCフルブラウザ状態でのメインカラムの横幅を超える画像は無駄以外何物でもありません。
例えば1280px × 780px の画像をアップロードして記事に当て込んだ場合、表示上はメインカラムに収まるように表示されていても、実際のデータの容量は元の画像の転送データ量が必要です。
WordPress5.0以降のブロックエディタでは、画像のサイズを選択して挿入することもできますが、どうせメインカラム以上の画像が必要でないなら最初からEWWWでリサイズ＆圧縮しておくのがベストです。
更に踏み込んだ設定として、同プラグインでJPEGやPNGに代わる、WebPという「次世代フォーマット」配信する事が出来ます。PageSpeed Insightsでも推奨されている項目ですので、この機に対応しておくのもいいと思います。
詳細は以下の記事で解説しています。
【ワードプレス】画像遅延（非同期）読み込みプラグイン
上でも軽く触れましたが、画像遅延読み込みという方法で画像を表示処理するだけで、体感速度が向上します。
遅延読み込みとか、非同期読み込みとか言ったりします。
ざっくり説明すると、画像は表示処理にも、読み込みにも時間がかかるので、先に準備完了してるHTMLを表示させちゃって、画像は見てる人がスクロールして画面に入った瞬間読み込む、という処理です。
通常のページ表示は同期処理といい、ユーザーに表示する情報全ての準備が整うまで、表示を待機します。これがクリックした後に真っ白な画面が表示される空白時間の要因になります。
サイトの画像を非同期で処理をすることによって、何もない真っ白な画面が表示される時間を大幅に軽減、体感表示速度の向上が見込めるというわけです。
僕の個人的な意見としてはEWWWの方だけで処理しちゃった方がいいと思うのですが、一応専用のプラグインも紹介します。微妙に読み込み時のエフェクトとか違うので。
Lazy Load
そのままの名前のプラグインです。
非常にシンプルでインストールするのみ。
設定なども一切ありません。
画像が「ふわーっ」と浮かび上がってくるようなフェードインエフェクトと共に読み込み表示されるのが印象的なプラグインです。
Lazy Load Optimizer
ちょっとだけ名前が違いますが、別のプラグインも紹介します。
画像の読み込みエフェクトは、ローディングクルクルです。
何となく伝わりますか？(笑)
Lazy Load Optimizerの設定
こっちはちょっとだけ設定もあります。
と言っても、ほとんどいじるようなところはなく、iframeにLazyLoadを適用するかのチェックくらいですね。
あとは、ざっと読むに、表示されていない位置の画像を読み込むためのバックグラウンド処理のあれこれの設定だと思います。
ほぼいじる必要ないかと。
LazyLoad系は重複で入れる必要ないので、どちらか一つにしましょう。
EWWWのオプションで済ませる人は、それだけで！
プラグイン入れまくるのも表示速度遅延の要因になりますからね。
画像だけが犯人だった場合、たぶんここまででスコア90オーバーかもしれません。
ワードプレスの高速化 – 重いデータをキャッシュする
画像処理だけで改善すればよかったんですが、そうは問屋が卸さない。
一応このサイトの場合、画像処理終了の時点でトップページのスコアは、65～68点程度まで改善はしたんですが、表示速度時間は3秒台中～後半と言ったところでした。まだ遅い。
ということで、次にやったのが、キャッシュを使うってことです。
キャッシュとは？
よく使うデータへのアクセスを速くするために、より高速な記憶装置に一時的に保存する仕組み。たとえば、アプリケーションの作業中のデータは、ハードディスクからメインメモリーに読み込んでおくことで、処理を高速化できる。また、Webブラウザーやサーバーのキャッシュ機能では、一度表示したページの内容をファイルに保存することで、次回からは、そのページをすばやく表示できる。
https://kotobank.jp/word/%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5-2698
ものすごく簡単に言うと、「何回も読み込まねーからな」ってことです。
遅い原因を潰すというよりは、「早く表示させるための処理」
攻めと守りで言えば、どちらかと言うと攻めです。
【ワードプレス】キャッシュプラグイン
読み込みや書き出しと言う、いわゆるI/O処理というのは、特段重たい処理でなくとも「空白の待機時間」が発生しやすく、動作遅延の要因になりやすいです。キャッシュはそれらを低減してくれます。
WP Fastest Cache
今回選んだのはこれ。サムネイルからして早そうですね。
プラグインタブから検索で一発インストールです。
WP Fastest Cacheの設定
とにかくチェックを入れまくります(笑)
ちょっと英語表示になっていて何してるのかわかりにくそうなところだけ解説すると、
| Preload | 最初のユーザーが訪れる前に、事前にキャッシュを作成しておく。初速から最高速ってことです。 |
|---|---|
| Update Post | 記事更新があったらキャッシュを削除する。 |
| Disable Emojis | 絵文字関連のCSSを無効化 |
Preloadにチェックを入れるとこのような設定が現れるので、上記のようにしてOKを押します。
どのページのキャッシュを作成するかってことですね。全てチェック入れてもいいんですが、公式の解説を読んだところ、割とサーバー負荷かかるようなことがかかれていたので、必要最低限に留めます。
固定ページやカテゴリページもキャッシュしたい方はチェックを入れてください。
あと、モバイルユーザーに対してキャッシュしない的な設定箇所だけはチェックを外します。
次に「キャッシュの削除」タブから「Add New Rule」をクリック。
僕は1日に一回を選択して保存しました。
キャッシュのリフレッシュレートだと思いますが、そんな分刻みで更新しまくるワケでもないですし、日に一回もリフレッシュされれば必要十分かと。
そもそも「更新したらキャッシュクリア」の項目にチェック入れましたしね。何のための設定なんでしょうね。これ。まぁやった方がよさそうなのでやりました。
ここまででキャッシュプラグインの設定は終了です。
この設定の終了時点でトップページのPageSpeedスコアは、
85点
おお～。来ましたね。中々ですね。
でもねGoogleさんの推奨スコアは、
| PC | 90点以上 |
|---|---|
| モバイル | 85点以上 |
らしいんですね。ちょっと足りない。
こちらも記事ではキャッシュの仕組みをもう少し詳しく解説しています。上級者向けのキャッシュプラグインも紹介していて、今はこのサイトではそちらのプラグインを利用しています。
ワードプレスの高速化 – 重い処理を遅らせる
ここからは少し、中～上級者向けのお話になりますので、生まれつきのスピード狂の方だけご覧ください。
重い処理を遅らせると書いていますが、ここで言う「重い」と言うのは、CPUに負荷がかかる処理の事ではなかったりします。
データ量以外のボトルネック
これ以上どうにかならないものかと、先ほどのPageSpeed Insightsの改善提案を見に行ったところ、「レンダリングを妨げる JavaScript を削除する」と言うのが目につきました。
この項目の改善で900msの速度改善見込みの余地があるとのこと。約1秒近い数値。
「割合デカくね？」
レンダリングを妨げる～の意味
少し専門的な話で、先ほど軽く説明しましたが、I/O処理というのはデータ処理の中でボトルネックになりやすい部分です。特段CPUに対する負荷が大きな処理でなくとも、http通信などのI/O処理は待機時間生み、プログラムが次の処理に移ることを妨げます。(同期処理の場合)
何気なく見ているWebサイトの、たった1ページでも、裏側では何回も読み込み(http通信)が行われています。
こと「Webサイトの表示速度」と言う点に関して言えば、<head>～</head>内でのI/O処理がレンダリング(描画)の開始を大きく遅らせる可能性が出てくるとのこと。
<head>タグ内での外部スクリプト読み込みを把握する
で、まぁ、調べたところありましたよ。このサイトにも。あるってGoogleが言ってるんだからあって当然なんだけど。
自分で書いたJavaScriptのファイルと、そのコードを動かすためにCDNで読み込んでるVer3系のJQuery。
具体的に取った対応策
問題のJSファイルでやってる処理としては、以下の二つ。
- サイトのロゴ画像をPC時閲覧時と、スマホ閲覧時で別々のものを表示するように分岐させる処理。
- スマホ閲覧時に表示されるフッターパネルをスクロール方向に応じて出したり消したり。
まぁ、どっちもいらないっちゃいらない処理かもしれないんですが、ただ消すのは悔しかったので、1の処理はJQueryで処理するのやめて、PHPの処理の時点で分岐、2の処理は、そもそもファーストビューに関係ないので<head>内ではなく、</body>直前に移動することで対応しました。
ちなみにキャッシュのプラグインまでの対策で85点だったスコアはついに・・・。
目標値をクリア！
やってやったぜ。
JS以外にCSSもこのレンダリングを妨げるリソースとして表示される場合もあります。
細かい事わからないけど、「とりあえずクライアントに点数改善しろって言われたからさっさと解決したい」って方はこちらの記事へどうぞ。
特効薬的にfunctions.phpにコピペするだけで「レンダリングを妨げるリソースの除外」をクリアする裏技を紹介しています。
それでもPageSpeedスコアが改善しない人へ
今回紹介した改善案はどれもクリティカルに影響が出るものだったと自身で実践してみて感じましたが、もしかしたら「それでも改善しなかった」、という方も出てくるかもしれません。
または、90点越え最後の決め手となった「レンダリングを妨げる JavaScript を削除する」という項目の改善の仕方が分からない方もおられるかもしれません。
そういった方のために多少なりともヒントになりうる項目を紹介します。
プラグイン入れまくり
プラグインは基本的に「タダだからとりあえず入れたモン勝ち！」みたいなものではありません。
不要なプラグイン、機能が重複しているプラグインなどがあれば、可能な限り整理してみると、改善されることがあるかもしれません。
参考までに、94点のスコアが出たときの最終的な僕のプラグイン全てです。
- Contact Form 7
- Crayon Syntax Highlighter
- EWWW Image Optimizer
- Google XML Sitemaps
- WP Fastest Cache
- 賢威キャラクタープラグイン
最後はこのテーマ専用のプラグインですので、他のテーマをお使いの方にはあんまり関係ないですが、一応記載しています。
テーマを疑う
今日日、あまり考えられませんが、「レンダリングを妨げる JavaScript」などを地で実装しているテーマなんかも、もしかしたら、あったりなかったりするかもしれません。
これはプラグインにも言えることで、目的の動作を達成するためだけに作られたプラグインなんかは、もしかしたらサイトの表示速度の事なんかそもそも考えて作られていない可能性まであります。
僕が使っているテーマはこの記事で紹介していますので、ご興味ある方はご覧ください。
サーバーのスペックを見極める
ここまで、全てのことを試して、必要なプラグイン/JS/CSSだけに絞り込んで、なお、遅いようならサーバーのスペックが、要求される水準にないという可能性が高いです。
逆に言うと、出来ることをやらずにサーバーだけ変えても、効果はないとはいいませんが、影響は限定的だと思われます。
ちなみにこのブログのサーバーはCoreServerのCORE-Aというプランで、あからさまにコスト重視で選んだサーバーで性能は決して高くありません。むしろ、低いと言えるレベルかも・・・。
廉価サーバーでもスコアは出せるということですね。
ワードプレス高速化まとめ
いくつかのクリティカルな速度改善の施策に絞り込んで詳しくお伝えしてきましたが、実際個々のサイトのPageSpeedのボトルネックになる部分は見てみないと何とも言えない部分はあります。
ただ、少なくともGoogleアナリティクスで見たサイトの平均的なスコアが50以下であるような場合は、PageSpeed改善に大きく寄与してくると思いますので、プラグインの施策だけでも是非とも試してみてください。
よりしっかりとワードプレスの高速化について学びたい方は書籍による学習なんかもオススメです。
コメント