WordPressサイトがある時から激重になってかなり困っていました（このサイトではありません）。
どのように重いのかというと、表示にメチャクチャ時間がかかるようになりました。
TOPページの表示が始まるまでに10秒ぐらい待たされます。
Aberdeen Groupの調査によると表示速度が1秒遅くなることでページビューが11%下がり、カスタマー満足度が16%下がり、コンバージョン率が7%下がるそうです。
訪問者だけじゃなく、自分もストレスなので重い腰を上げて調査しました。
結論から言えば、サイトの表示速度は、WordpressがHTMLを吐きだすまでの時間が短くなれば高速化になります。
インストール直後は早かったはずのWordPressがHTMLを吐きだすまでの時間を遅くしている原因を調べて取り除く必要があります。
まず、キャッシュプラグインを入れれば殆どの場合は表示速度の遅さは解決しますので、プラグインを入れていない場合は、迷わずキャッシュプラグインを入れてください。
この記事は、キャッシュプラグインを使わない時のWordpressの高速化についての記事になります。
高速化には静的ページのキャッシュプラグインが効果あり
WordPressの表示速度を上げたければ静的ページを生成してキャッシュするキャッシュプラグインを導入すればいいと申し上げました。
しかし、キャッシュを読み込まない場合、実際のサイトの表示速度は遅いままなので、キャッシュが無いページの初回アクセスは遅いままとなります。
これはプリロード（アクセスが無いページのキャッシュを生成する仕組み）で回避できますが、得てしてサーバー負荷が高くなるのでプリロードは使わない前提です。
キャッシュプラグインは管理者でログインしてサイトを閲覧しているとキャッシュ除外するものが殆どですので、管理者から見ると素のWordpressになるのでサイトは遅いままです。
今まで述べたように、サイトの速度を改善したいのであれば、キャッシュプラグインではなく、Wordpressサイトを根本的に速度改善しないと問題は解決しません。
WordPressサイトの表示がなかなか始まらないのはなぜ？
WordPressサイトの表示がなかなか始まらないのはなぜでしょうか？
WordPressのサイトはHTMLの生成が終わると表示が始まります。
サーバーにリクエストが送られてからサイトの表示が始まるまでの時間をTTFB（Time To First Byte）と呼んでいます。
HTML生成後はPage Speed Insightでお馴染みの項目で評価されますが、サイトの表示が始まるまでの時間はPage Speed Insightではサーバーの応答時間と呼ばれています。
今回の問題はサーバーの応答時間、つまりFTTB時間を短縮したいという話です。
WordPressがHTMLを用意できるまでの時間（TTFB）をどれだけ短縮できるかが、課題となります。
TTFB（Time To First Byte）が悪化する原因は？
今までサイトの表示が速かったのに突然サイトの表示が遅くなったということは、サーバー側の問題というよりテーマやプラグインの変更に起因する可能性が高いです。
そういう場合は、プロファイラーを使いましょう。
プロファイラーを使えば、テーマやプラグインなどの処理時間が分析された結果を確認できます。
表示速度の低下は、テーマ起因の可能性は低く、殆どが良かれと思って入れたプラグインが原因になります。
プロファイラーを使えば、プラグインを停止したり、他のプラグインに切り替えるなどの検討が行えます。
P3 Profilerは使えるのか？
プロファイラーと言えば、P3 Profilerが定番でしたが、PHP7対応がなされず長期間放置されていました。その後、PHP7に対応はしてくれたようですが、あまりお勧めできません。
Code profilerがおススメ
P3 Profilerはおススメできないという話でした。ではどのプラグインがいいのでしょうか？
最近リリースされたCode Profilerの方が良いです。このプラグインは有料版があるのでメンテナンスされ続けると思います。
テーマとプラグインに分けて処理時間を表示してくれるのでわかりやすいのですが、自前スクリプトなどのボトルネックはテーマの処理時間に含まれてしまうので詳細はわからないです。
プロファイラーを使うと、おそらく処理時間が大きなプラグインがあると思います。そのプラグインを使わないようにすることで単純に表示速度は改善します。
TTFBの悪化要因①：DOMパーサーを使うプラグイン
DOMパーサーを使用するプラグインはボトルネックになる
DOMパーサーというのは、HTMLをプログラム内部に取り込んで構文解析し、プログラム上で簡単に扱えるようにする処理のことです。
WordPressが生成したHTMLを書き換えるプラグインにはDOMパーサーが使用されているものがあります。
DOMパーサーは扱うHTMLサイズが大きくなると大量にメモリを消費し、処理が極端に遅くなる傾向があり、サイトによってはDOMパーサーを使用するプラグインはボトルネックになります。
DOMパーサーを使用する代表的なプラグインとして、以下の2つがあります。
- Lazyloadプラグイン
- 目次プラグイン
lazyloadプラグイン
サイトの表示速度を速くするためにLazyloadプラグインを導入する人は多いでしょう。
高機能なLazyloadプラグインは、得てして高機能（低速）なDOMパーサーを使用しており、DOMが大きくなると処理遅延が大きくなりやすいです。
せっかく高速化のために導入したLazyloadがサイトの表示速度を遅くしては意味がありません。
WordPress標準のLazyloadが一番軽い
幸い、WordpressがNative Lazyloadに対応したので、それを使うのが一番良い解決策になります。しかし、細かい制御をしたい場合はプラグインを使いたくなりますので、使用するプラグインは慎重に選ぶ必要があります。
プラグインのおススメはAutoptimizeのLazyload
プラグインを使う場合は、Autoptimizeに組み込まれているLazyloadがおススメです。
AutoptimizeのLazyloadはDOMパーサーを使用してない（preg_matchを使用）ので、色々試した中で一番速いと思います。
Cocoonの場合は、Autoptimizeの導入は注意点があるので、以下の記事を参照してください。
Lazyloaderはおススメできない
Lazy loaderはlazysizeを使っていて使い勝手も良いプラグインですが、いかんせんDOMパーサーが遅すぎて、DOMサイズが大きくなると耐えられないぐらい、HTMLの吐きだしまでの時間が長くなってしまいます。
- WordPressのNative Lazyloadを使う
- AutoptimizeのLazyloadを使う
- DOMパーサーを使ったプラグインは避ける
目次プラグイン
テーマ付属の目次機能が一番軽い
目次機能は、テーマについている場合はテーマ付属のものを使うのが一番良いとおもいます。
理由は単純で、テーマ付属の目次は多機能ではなく、DOMパーサーを使用せず、DOMの解析時間がかからないからです。
自前の目次スクリプトも悪くない
機能的に複雑なものが必要無くて、目次機能がテーマに付属していない場合は、プラグインを使用しないで目次を実装する例がたくさん検索すると出てくるので、そちらをコピペするのが良いでしょう。
プラグインの目次は遅いので避ける
ただ、除外機能が必要だったり、複雑な機能を持つ目次プラグインを使いたい時もあると思います。
どの目次プラグインがダメだったか、紹介します。
Easy Table of Contentsは多機能で使いやすい反面、DOMパーサーを使用しているため、DOMが大きくなると徐々に遅くなっていくことが確認できました。
- テーマ付属の目次機能を使う
- プラグインを使わないで自前で目次を実装（検索してコピペ）
- DOMパーサーを使ったプラグイン（Easy Table of Contents）は避ける
TTFBの悪化要因②：外部ファイルの読み込み
jQuery
jQueryは読み込むタイミングが難しく、headで読んでもfooterで読んでも問題が起きやすいです。
一番良いのはjQueryを使わないこと。
最近ではテーマやプラグインでjQueryを使っているものはほぼありません。自分でスクリプトを書いたり、jQueryライブラリを組み込むときは非jQueryのものを選びましょう。
video.js
mp4などの動画を再生する時にvideoタグと組み合わせてプレイヤーを豪華にするjavascriptがあります。
video.jsはその一つですが、とりあえずjavascriptのサイズが大きいので、動画を読み込むよりもjavascriptのサイズの方がインパクトが大きかったです。
Playerをリッチにするためのjsですが、動画自体が短い場合は無理に使う必要もないので、videoタグだけで対応する方が良いです。
もし、jsでの対応が必要であれば、video.jsではなく必要な機能だけ組み込む方がいいかもしれません。
TTFBの悪化要因③：外部画像のwidth/heightサイズをプログラムで取得
外部画像のwidthとheightの取得にgetimagesizeを乱用しない
CLS対策のため、imgタグにはwidthとheightは必須です。
外部画像の場合、width/heightは画像を取得しないとわかりません。
外部画像のwidth/heightを取得するのに便利なのがgetimagesize関数です。
確かにgetimagesizeは便利ですが、便利だからといって多用していると秒単位で処理時間が増えてきます。
画像のwidth/heightは正確性は必要無く、widthとheightの比率だけあっていればいいことが殆どなので、画像が多いサイトではgetimagesizeは使わず決め打ちする方が断然速くなります。
しかし、画像のアスペクト比が画像ごとに違う場合は、決め打ちしてしまうと画像を読み込むまで正確な高さが決まらないので、スムーススクロールの飛び先がずれたり、CLSの問題が再燃します。
widthとheightが正確でなくてもCSSだけで対応できる方法を以下の記事にまとめてありますので、参考にしてみてください。
外部画像の存在を確認するcURLを乱用しない
外部画像を直リンクする場合、画像があるかどうか確認しないといけない場合があります。
その時に、cURLを使って外部画像の存在を確認（404確認）すると、画像の数が増えてくるとサイトの表示速度がどんどん遅くなる原因となります。
外部アクセスを可能な限り減らし、集約し、キャッシュすることでサイトのHTML生成が高速になっていきます。
外部画像を直リンクすること自体はlazyloadがあるのでサイトの表示速度は遅くなりません。
サイトの表示が遅くなるのは、外部画像の情報を得るために外部と通信し、その結果が出ないとHTML生成できない方が影響が大きいです。
TTFBの悪化要因④:ACFの繰り返しフィールドをなるべく使わない
ACFの繰り返しフィールドは便利ですが、読み込みが遅いです。
繰り返しフィールドはなるべく使わないようにすべきです。
繰り返しフィールドをどうしても使う場合は、繰り返しフィールドを連想配列とtransientキャッシュの組み合わせにコピーして使う方が速いと思います。
また、ACFのget_field()もフィールド数が増えてくると読み出し回数（クエリ回数）が増えるので、サイトの表示が遅くなる原因となります。
get_field()ではなく、get_fields()を使うと1回のクエリで全てのデータを読み出せますので高速化できます。
TTFBの悪化要因⑤:APIで取得したjsonデータをキャッシュする
APIでjsonを取得することがあった時に、毎回外部のAPIにアクセスするのはリソースの無駄です。
jsonデータをtransientを使ってキャッシュして、次回はキャッシュを読み込む方が速くなります。
まとめ
WordPressサイトの高速化はPageSpeedInsightの改善項目ばかりに目が行きますが、最終的にはサーバーの応答時間の短縮が課題となることが殆どです。
キャッシュプラグインを導入したとしても、キャッシュが無い時の表示速度はサイト自体の高速化をしないと遅いままです。
この記事では、Wordpressサイトの表示が遅いなと感じた時に何が原因となりやすく、どのように改善するかについてまとめました。
