WordPress高速化/チューニング方法総まとめ！10倍高速化も夢じゃない！

2018-08-08　

ここまで何回か記事にしている通り、自分は最近VPSに移行して様々なWordPressに対する性能チューニングを行いました！それにより、レスポンスに関しては5倍程度高速化することに成功しました！ページの表示速度もだんだんと速くなっており、2~4秒程度とかなり高速にページ表示出来るようになりました！Google先生による評価も、下図のように「ページ表示速度2秒」で超高速という判定になっています！数あるサイトの中でトップクラスになっています！

ここまでくるのに本当にたくさんのチューニングを行いました。そこで、そのノウハウの共有のために、今回は「WordPress高速化/チューニング方法総まとめ」として、自分がやった高速化手法を全てこのページに列挙しようと思います！是非参考にして下さい！

1 サーバー/VPS選択
2 DB系チューニング
3 apache/nginx系チューニング
4 PHP系
5 キャッシュ系対策
6 WordPress専用チューニング
7 DNS/ネームサーバーに関する高速化
- 7.1 高速な日本のネームサーバーを選択する
- 7.2 レコード保持期間TTLを長くする
8 まとめ：速さは正義！とにかくやれる事はたくさんあります！

サーバー/VPS選択

まず最初に重要なのが、適切なサーバー/VPSといった動作環境を見つけることです。確かに、チューニングでも高速になりますが、やはり元の性能で上限が決まってしまいます。特にネット回線などは、チューニングでは限界があります。良いサーバー/VPSを選択することが、一番のチューニングになると思います！

高速な回線のあるサーバー/VPSを選択する！

一番サーバー選択で重要なのは、回線の速いサーバーを見つけることだと思います。何度も言いますが、回線の速さはどんなに頑張っても限界があります。どんなにデータ圧縮しようとも、
送れる量には限界があります。良い回線を選ばないと、いくらチューニングしても無駄となってしまうのです。

自分は、検討に検討を重ねた結果、他環境と比べて8倍ぐらい高速なWebARENAのVPSを選びました！コチラの記事でその理由と実測データ等を詳しく公開しています！

メモリが多いプランを選択する！

高速化の基本は「ディスク⇒メモリ」です。ディスクに置いておくと遅いので、メモリに置くことで爆速化出来るんです。つまり、どれだけ高速化できるかはメモリの量によります。メモリが多いプラン、KUSANAGI推奨の4GB以上のプランを選んでおくと安心です！正直、そこまで性能を求めないなら2GBでも十分ですけどね。

KUSANAGIが使えるサーバーを選択する

こち。。KUSANAGIを選択するメリットは、チューニングが楽になる事です。以下、様々な要素のチューニング方法を挙げていきますが、KUSANAGIを選択するとそれらがほぼ不要になります。なぜなら、KUSANAGIが勝手にチューニングをしてくれているからです。

少しずつチューニングをしたり、必要なものをインストールするのは大変ですし、トラブルの元になります。基本的には、KUSANAGIが使える環境に移行する事をおすすめします。

DB系チューニング

DBのチューニングは、影響が大きいです。なぜなら、時間がかかるディスクへのアクセスを大きく減らすこと出来るからです。ディスクにあるDBをメモリに置くことで、超高速にデータアクセスができます！特にwordpressはDBにたくさんの情報があるので効果が高いです。

改善前：ディスクにあるDBにアクセスするのに時間がかかる！

改善後：メモリにあるので瞬時にDBにアクセスできる！

MariaDBを使用する

DB系のチューニングとしては、MySQLではなくMariaDBを使う手法というのがあります。MariaDBはMySQLとほぼ互換性を保ちながら、高速化したDBらしいです。参照系がMySQLのほうが得意とか、得意不得意あるらしいですが、基本的にはMariaDBにしたほうが速いはずです。KUSANAGIでも採用されているため、自分もこれを選択しました。

[参考URL]
https://biz-server.net/function23/

InnoDB(インメモリDB)を使用する

DBアクセスはプログラム実行処理と比べると遅いです。CPUがナノとかマイクロ秒で処理しているのに対して、DBアクセスはミリ秒単位近くまで時間がかかってしまいます。なぜなら、ディスクへのIOアクセスが遅いからです！

ということで、ディスクへのアクセスを極力しないようにDBをメモリ内にできるだけのせるのがInnoDB(インメモリDB)です。innodb_buffer_pool_sizeという設定値で割当できる量を決められますので、可能な限り多く割り当てましょう！自分はDBのサイズズ以上の2GBを割り当ててます。基本的には全てメモリにのるはず？

[参考URL]
https://corporate.inter-edu.com/developper/1373

クエリキャッシュを使用する

DB系でもう一つ重要なのがクエリキャッシュです。クエリ(DBへの要求)を解釈して処理していくのには時間がかかります。いくらDBがメモリにのっていても、インデックスなどをたどって探索しなければいけないので大変なはず。ということで、このクエリキャッシュに適切なサイズのメモリを割り当てることで高速化できます。query_cache_sizeに値指定することで反映されます。

[参考URL]
https://qiita.com/ryurock/items/9f561e486bfba4221747

各種バッファの値を適切に調整する

MySQLやMariaDBにはその他にも多くのバッファやメモリサイズの指定があります。これらを適切な量に割り当てることによって、余計なディスクアクセスが減らせるはずです！

[参考URL]
http://sawara.me/mysql/1428/

apache/nginx系チューニング

Webサーバーの高速化もすごく重要です。正直、デフォルトのapacheの通信は遅いです。下図の左側のように、一回一回通信して画像などを送っており、非効率なんです。それと比べて、nginxやhttp2などといった技術をつかうと、右側のようにパラレルにデータを送ったりすることが可能になり、効率的なデータ転送が可能になります！

apache→nginxに移行する！

まず第一に、webサーバーをapacheからnginxに変えるのが良いかと思います。基本的に、apacheはシーケンシャルに一人一人リクエスト処理をしているため、スループットが低いです。それと比べ、nginixでは可能な限りリクエストを同時並行で処理しようとするため、高速になります。nginxになるデメリットもまりないため、nginxへの移行は迷わずやるべきではと思います。

SSL化して、http2を導入する！

第二に重要なのが、http2化です。http2とは、上の画像のように並行で様々なデータを送りつける技術です。今まで一つ一つデータを順番に送っていたのが、同時にデータを送れるようになります。これにより、超高速化することが可能になります。このhttp2通信を実現するためには、SSL化(https)しておく必要があります。SSLは遅いというイメージがありますが、http2化する恩恵のほうが大きいです。是非、SSL化して高速化しましょう！

SSL通信のキャッシュ期間を長くする

SSLの通信を確立するためには、お互いに暗号を送ったり、認証したりしなければいけないため、遅いです。30ms～100msはかかります。これが毎通信の最初に行われるのですから、そのオーバーヘッドは大きいですよね。これについては、SSLの認証保持時間を長くすることにより、2回目アクセス以降の認証を省略することが可能なんです。それを決めるのがssl_session_timeoutといったパラメタで、ssl_session_timeout＝5mなどとすると、5分間はSSL認証なしで通信が可能になります！長すぎると、コネクション保持量が多くなり、性能劣化しますが、ある程度長くしておくのを推奨します！このサイトは平均滞在時間が1分30秒ぐらいのため、余裕をもって5分保持にしておきました。

phpとの通信をunixソケットに変更する

追加のチューニングとして、PHPとの通信にunixソケットをつかうという方法があります。通常はTCPIPで通信するんですが、同一サーバー内の通信の場合はUNIXソケットを使ったほうが若干速いとのこと。効果は薄いかも知れませんが、やるにこしたことはありません。「fastcgi_pass　unix:/var/run/php-fpm/php-fpm.sock;」などと設定すると、phpとの通信にunixソケットが使われます。詳しくは参考URLなどを見て下さい！

[参考URL]
http://takashabe.hatenablog.com/entry/2015/08/10/220938

PHP系

次に、PHP系のチューニングです。PHPは昔から遅い言語と言われてきました。インタプリタと呼ばれる形式のプログラム実行方式であり、毎回プログラムを解読するため、ネイティブアプリと比べたらおそすぎるからです。

しかし、最近のPHPは高速化してきています。PHPのバージョンを変えるだけで2倍ぐらい速度があがるなんてザラです。影響を確認して、導入すべき高速化手段を検討しましょう！

PHP7(もしくはHHVM)を導入する！

まずはじめに。PHP5を使っているのなら、今すぐにPHP7に移行したほうが良いと思います。PHP7はネイティブアプリと同じぐらいの速度で動けるよう、動的にコンパイルしていく方式を採用しており、PHP5と比べて2倍以上の性能を誇っています。

また、PHP7.1、PHP7.2という順番でダンダンと高速化が進んできています。もはや遅いプログラム言語とは言えなくなってきています。ちなみに、HHVMという高速化のためにPHP実行環境もありますが、あまりオススメできません。既にPHP7.2のほうが高速ですし、これ以上使い続けるのはきけんだからです。詳しくはコチラのページで解説しています！

opcacheを導入する

このopcacheというのは、「PHPプログラムを毎回ディスクから取り出してコンパイルして起動できるようにする」という無駄極まりないPHPの処理を、キャッシュによって解決するものです。下図のように、PHPは毎回プログラムを読み取り、解釈して実行しています。それを改善後の図のように、コンパイル済みのプログラムをキャッシュし、メモリ内に保管しておくことで、瞬時にプログラム起動できるようになります。実際適応してみると、効果は抜群です！本サイトではレスポンス時間が200ms→80msと、半減以上の効果がありました。如何にPHPが起動に時間がかかっているかが分かりますね！

opcache.revalidate_freqというパラメタもあり、これも重要です。これは、プログラムが更新されていないかチェックしにいく頻度を設定する値です。短すぎると余計な負担がかかりますし、長すぎるとプログラムを更新しても反映されないため、運用で困ります。自分は推奨値の60秒にしています。

改善前

改善後

[参考URL]
https://qiita.com/morimorim/items/fb39ae7d673a8b88f413

PHPの子タスク(child)のチューニングをする！

PHPは子タスクの起動スケジュールなどを調整できます。PHPはシングルタスクでなく、多くの小タスクと１つの親タスクのペアで走ります。そして、この子タスクのスケジューリングが設定可能です。設定値としては、pm.max_children（子タスクの最大数）などがあります。また、小タスクの制御方法としてstatic、dynamic、ondemandの3つがあります。staticは固定タスク数で走るモードで、dynamic,ondemandはリクエスト数が多くなると自動的に小タスク数が多くなる制御方法です。

どのタスク制御方法を選ぶのか、どれぐらいのタスク数で走らせるのかを決めるのは非常に重要です。それにより、処理できるリクエスト数/メモリ使用量が大きく変わりますから。自分は、様々な考察の結果、staticで18子タスクで固定で起動させるようにしています。

[参考URL]
https://qiita.com/kite_999/items/434188f77b19c3aa4a0e

キャッシュ系対策

キャッシュ系対策は非常に効果の高い対策方法です。キャッシュをうまく使うと、リクエストがきた瞬間に、結果をすぐに返す事が可能になります。つまり、サーバーの性能に関係なく、10ms程度の恐ろしく短い時間でレスポンスが返せるようになるわけです。最強ですね。速度だけみたら、最速の手法です。でも、キャッシュにはデメリットがたくさんあります。古いデータを返す可能性もあり、整合性が失われる可能性があるわけです。ですので、どれを使うのか深く検討して採用する必要があると思います！（自分は絶対安全で制御しやすいキャッシュ手法しか採用していません）

apc,apcuを導入する

phpのメモリキュッシュ機能としてapc,apcuというものがあります。これは、プログラムがメモリに保存した値をいつでも後から瞬時に取せる機能です。ディスクでないため本当に最高速にキャッシュ参照できるんです！

これはphp間で共用の値になるので、沢山のユーザーが混在するレンタルサーバーでは使えないようです。自分はこのためＶＰＳに移行しました。

ただapc,apcuを導入するだけでは、なんの意味もありません。これをどう活用するかによって、高速化できる度合いが決まるわけです。自分はページ内の各共通要素をapcuでキャッシュしてしまい、大幅にクエリを減らしています。このあたりについては、別記事にして解説する予定です！（少々お待ち下さい）

fastccgi cache(fcache)を導入する(未実施)

キャッシュとして一番低レイヤーで動くものにfcacheがあります。これはnginxがfastcgi(php)と呼ばれる機構と連携して、ページキャッシュをデータとして返すものです。下図のように、fastccgi cacheはwordpressのレイヤーに入る前にキャッシュを返すので、超高速です。その代り、細かいキャッシュ制御ができません。例えば、「ランニングカテゴリの記事だけキャッシュしないようにする」といった細かい制御ができません。また、wordpressとの解釈の違いにより、不整合が起きやすいです（別途解説予定）

WordPressキャッシュ(bcache)を利用する(未実施)

fastccgi cacheとは別に、WordPressで制御できるキャッシュがあります。これはキャッシュプラグインなどで実現できるもので、ページ出力処理の前にキャッシュ判定を行い、キャッシュがある場合はそれを返して処理を終了します。毎回ページを１から作成しなくて良いわけです。また、wordpress側でキャッシュ利用/削除を判断するので、「このカテゴリーだけ削除する」といった細かい制御ができます。しかし、下図のように重いと言われているwordpressが起動してからキャッシュを使うかどうか判断するため、nginx自体がキャッシュ判定するfastccgi cacheと比べると遅いです。

プラグインでキャッシュ実現することが多いですが、プラグインごとでキャッシュの判断/実現方法が違います。プラグインによるキャッシュの考え方によるトラブルも多いので、利用には注意が必要です！

CDN導入(未実施)

CDNは最近流行りのキャッシュ/コンテンツ配信方法です。「ユーザーに近いサーバーから、分散してコンテンツを配信」がテーマです。まず、CDNはページのキャッシュを世界各地に分散して配置します。そして、アメリカのユーザーにはアメリカのサーバーから、日本のユーザーには日本サーバーから配信するようにするわけです。まさに、適所適材で配信サーバーを選択するわけです。

では世界に配信するコンテンツでないと意味ないかと言われると、違います。CDNは分散配信という機能があり、複数台のサーバーで手分けしてコンテンツが配信される形になってます。50の画像があって5台のサーバーがあったなら、各サーバー10ずつ配信すれば事済みます。これにより負荷分散され、詰まることなくより高速にコンテンツが配信出来るわけです！

ただし、ただでさえややこしいページキャッシュが、さらに全世界に拡散するので制御には注意が必要です。この制御を誤って、メルカリがユーザーに別ユーザーの情報を出力してしまったという事例もあります。

自分はこの方法はとりませんでした。古いプログラムと新しいプログラムが混在する可能性があり、混乱を招く危険性大です。CDNを使う場合は、こういったキャッシュが分散されるデメリットを考えておかないといけないです。

[参考URL]
https://blog.redbox.ne.jp/what-is-cdn.html

AMP導入(未実施)

最後に、AMP方式を紹介させて頂きます。AMPはグーグルが推奨するキャッシュ手法です。これは、複雑な事を排除したAMPという形式でHTMLファイルを記述することで、CDN的に一切元のサーバーにアクセスする必要がなくなる技術です。つまり、google先生がサーバーから直接コンテンツを配信してくれるようなもので、超高速です。自分のサーバーは貧弱でもいいのです！

ただし、AMPの書き方が特殊であること、最新情報が反映しにくいというデメリットがあります。

WordPress専用チューニング

上記の項目はWordPress以下のレイヤーに対してのチューニングですが、もちろんWordPress自体に対しても高速化対策が必要です。特にWordPressは非効率な処理をしていると言われているので、そのチューニング効果は絶大です。

翻訳を外す、無効化させる

まずは翻訳処理を外しましょう。WordPressは英語がベースで出来ており、日本語環境で動かすためには翻訳が必要になります。この翻訳処理、恐ろしいことにページが表示されるごとに毎回行っているのです！超非効率ですよね！ですので、WordPressの言語設定を英語にするだけで劇的に軽くなります！

オススメは言語を英語にするのではなく、翻訳を無効化する方法です。言語自体を英語にすると何かと不具合がおきそうなので、翻訳のみ切ってしまうのが一番良いかと。翻訳の切り方は、こちらのページで別途解説しています！

プラグインを外す

WordPressのプラグインは重いと言われていますよね。本当にそのとおりです。というより、想像以上にひどいです。本当にページが呼び出される度に毎回プラグインが起動処理を行っているので、無駄な処理が多いのです。色々とプラグインをON/OFFして実験しましたが、プラグインを外しただけで処理が2倍ぐらいに高速化してもおかしくはないです！

プラグインを外すことの重要性はコチラのページでも熱く語っているので、是非ご参照下さい(^^)

クエリを監視し、余計なクエリを減らす

クエリとはDBへのアクセスへのことです。クエリの数が多いほど、ディスクへのアクセスが多くなり、遅くなります。WordPressではこのクエリ発行を大量にしており、1ページ出力するのに100程度のクエリを発行していることもあるくらいです！（自分はそうでした）

これについては、functions.phpにadd_filter(‘query’,…)というフィルターをかけることで、クエリが発行するたびに監視することが可能です。このフックを使うことで、無駄なクエリが発行されていないかチェックすることをオススメします。いかにプラグインやWrodPressが無駄処理をしているかがわかります！

[参考URL]
https://www.softel.co.jp/blogs/tech/archives/3866

DNS/ネームサーバーに関する高速化

サイトにアクセスするときには、まずドメイン名⇒対象サーバーのIPアドレスに情報変換する必要があります。その解決を行うのがDNS/ネームサーバーです。効果は微妙かもしれませんが、この情報変換(ルックアップ)を高速化することもできます。

高速な日本のネームサーバーを選択する

例えば、ネームサーバーがアメリカにあると、平気で30msとか問い合わせにかかったりします。10ミリ秒単位で高速化を目指しているときに、30msもかかるのは致命的ですよね。ということで、日本でも高速にアクセスできるネームサーバーを選ぶことが重要です。

レコード保持期間TTLを長くする

ネームサーバーのアドレス解決情報にはTTLという値がついています。これは、「アドレス解決した情報を、何秒キャッシュとして保持しても大丈夫か」を示す値です。TTLを短くすると、各DNSは頻繁にネームサーバーに解決を求めてきて若干遅くなるはず。自分は、TTLを24時間と最長に設定しています。アドレスなんてサーバー移転しないと変わらないですから。こうすることで、わざわざネームサーバーに問い合わせる事を極力避けられるはずです！

[参考URL]
https://www.nic.ad.jp/ja/newsletter/No51/0800.html