当サイトのWEBサーバーはAWS（AmazonWebService）を利用してサーバーを構築しておりますが、なにぶん個人しようということもあるので、非常に低いスペックで運用しています。
もちろん、今後、もっともっとアクセスが増えてきたらAWSはリソース増量が可能なクラウドサービスですからサーバーのスペックアップによってパフォーマンス向上は見込めますが、限界までパフォーマンスを引き出すのは私の仕事です。
私はF1がすきなので、F1を例に説明いたします。
メルセデスパワーユニットが最強ですが。。。
２０２０年、パワーユニットとしてはメルセデス製のパワーユニットはほかの追随を許さないレベルに高いと言われています。
現にパワーユニットの親玉たるチームメルセデスは圧倒的で、２番手と思われるレッドブル・ホンダを予選で１秒近く引き離すレベルです。
ここが重要なポイントなのですが、だからと言ってメルセデスパワーユニット勢が上位を独占しているわけではないのです。
ピンクメルセデスと言われるレーシングポイント
２０１９年度製のメルセデスシャシーやボディーワークのクロンではないか、ピンク色したメルセデスと言われるレーシングポイントチーム。
ほぼ丸コピーに近いと言われていますがそれでもやはりレッドブルの後塵をはいしていますし、現状のポジションとしてはワークスルノーもしくはアルファタウリ・ホンダやマクラーレン・ルノーと肩を並べると言ったところでしょうか。予選はかなり早いですが本番レースとなるといまいちです。
ウィリアムズは、どん尻ではなくなったがそれまで
こちらが一番いい例でしょう。
最強のパワーユニットであるメルセデスパワーユニットを獲得しているのでかなりパワーがあり早くはなりました。が、シャシーやボディーワークがやはり一枚も二枚も他チームに劣るため下位に沈んでいます。
とはいえ、昨年まで１９位、２０位のどん尻確定だったウィリアムズが、今年はパワーユニット開発大失敗と言われているフェラーリ勢の下位クラスより上、でもそこまでという位置取りです。
フェラーリのセカンドチームと言われるアルファロメオが現在どん尻確定の位置取りで、ウィリアムズはこちらもセカンドチームと言われているハースと、コース形態に合わせて勝ち負けといったレベルです。
こうなってくると上位勢のリタイヤ状況によってはポイントも視野に入るレベルですが、そのほとんどがパワーユニットと言われるレベルです。
サーバーのスペックとチューニング
サーバーというのはF1で言えばパワーユニットのようなものです。
そのパフォーマンスの大勢を決めるものになります。先述の通り、どんなにいいパワーユニットを得ていても、周辺の空力パーツ、また、パワーユニットの調整が上手くできなければ最大パフォーマンスを発揮できません。優勝からどん尻争いまで可能性があります。
それは、人より良いスペックのマシンを使っていれば何もしなくても高パフォーマンスはもちろん出せます。
しかしながら、チューニング次第ではどんなに高価なハイパフォーマンスのサーバーを使っていてもそのパフォーマンスを発揮できずに終わる可能性もあります。
逆を言えば低スペックだったとしても、用途を考えそれに沿ったチューニングを施してあげることで、何もしていないハイパフォーマンスマシンにレスポンスで勝てる可能性が出てきます。
なので、チューニングは将来ハイスペックマシンに切り替えたときにも活きてくるのです。
F1で言えばレッドブルとホンダの関係ですね。
決して最強のパワーユニットではないが安定性と小型化に賭けては自身があり、その与えられたスペックを最大限に生かそうとするレッドブルチーム。
パワーだけだとメルセデスに勝てませんが総合力では上回るときもあります。
予選では圧倒的な差がつけられることが多いですが重要な本番レースでは迫る勢いです。
現状のWEBサーバーはnginx
現在、WordPress（PHP・MySQL）で相性がいいとされているWEBサーバーがnginx。
一昔前まではLinuxのWEBサーバーといえばApacheで、ほぼ選択肢がなかったのですが、nginxは、大変いいWEBサーバーでかつ、高パフォーマンスを出せるWEBサーバーです。
なので、nginxで構築しています。
しかし、最近はapacheもバージョンが上がり、http2という規格になり大変パフォーマンスが上がりました。
こちらも選択肢だったのですが、.htaccessをあまり使いたくないなという判断からnginxを採用しています。
DBは、MariaDB5.6
当方はサーバーの管理ツールとしてPleskというコントロールパネルを基本的に採用しています。
現在のPleskの場合、5.5がインストールされることから手動で5.6へとアップデート。
WordPressではパフォーマンスが全然違うということなのでこちらも対応しました。
WordPressチューニング
GoogleSearchConsoleで、WEBに関する主な指標で、少しずつ【注意】が増えてきていました。
これは、アクセスが伸びていくと同時に、同時接続者も増えてきて、その分サーバーの反応が鈍るからです。
また、もともとギリギリのスペックだったものがちょっとアクセスが増えたことでレスポンスが悪くなり注意信号になったということですね。
まずは、基本的なパフォーマンスチューニングを行えばギリギリのラインまで良好状態を保てるはずだという思考から、まずはWordPressのパフォーマンスチューニングを行うこととしました。
jsやcssの読み込みによるパフォーマンスの低下
最近のデザインテーマはレスポンシブデザインに対応するためやスライドショーなどの採用から大きな量のJavascriptファイルやデザインを設定しているcssファイルを大量に使います。
デザインを構成する要素ですから普通にテンプレートを作ると、<head>内で読み込もうとするのが普通です。
また、Javascriptについては既存のライブラリみたいなものを採用しているケースが多く、そうなると現デザインで使っていない処理なども含まれていたりします。
これを、コンテンツ描画を始める前に読み込めばそれだけ表示するのに時間がかかるため、できるだけ後で読み込みさせるようにしたいと思います。
手動でやれないことも無い
プラグインを利用せずに、手動でコツコツロードの場所を変更したりPreloadプロパティを入れたりすることでロードの順番を変えたりすることもできます。
プラグインでの対応
今回私は【Autoptimize】というプラグインで対応しました。
こちらは必要なファイル形式を必要な設定にすることができて、GoogleSearchConsoleとの相性はよく、これを使って最適な状態を作り上げます。
テーマのjsやcssの使用状況によって設定は変わりますし、Autoptimizeで設定したことでむしろパフォーマンスを落とす可能性もありますので一つ一つチェックしながらハイパフォーマンスが出る位置を設定されるのが良いと思います。
まずこの処理を行うことでかなりのパフォーマンス改善が見込めます。
画像をWebP（ウェッピー）形式へ
これはもともと考えていました。
しかし問題なのは
- 大量に画像をすでに利用している
- 一気にwebpに画像の参照も変更してほしい
- さらに、nginxなので、.htaccessで、rewriteはできない。
- 外部URLから読み込んでいる画像もたくさんある
と、問題があります。
その中でも外部URLからの画像のロードについては頭が痛い問題です。
それを解決に導いてくれたのは【WebP Express】というプラグインです。
こちらのプラグインにはCDNを利用してwebp化するという対応があります。
ようは、webp化するためのシステムがあり、それを利用して自前でUPしたjpg画像などをCDNを通すことでwebp化してくれるシステムを利用してやってくれます。
これであればCDN先のURLに、画像のURLを付け足すだけなので、逆に言えば外部URLの画像もCDNを通せば同じ形でwebp化できます。
今回、パフォーマンスとしてはこの処理により最大のパフォーマンスを出せるようになりました。
画像自身はたくさん使っているサイトではないのですが、外部参照が多いことで、相手サーバーのパフォーマンスに引きずられるケースが多かったのですが画像はCDN経由としたことで参照先ドメインは統一され、かつ画像を処理する専用のCDNですからパフォーマンスもいいのです。
これによって画像のレスポンスは高安定でハイパフォーマンス化され、結果スピードアップにつながりました。
キャッシュプラグインは不採用
つぎによく言われるのはキャッシュを持つことで、レスポンスタイムを向上させようという手法です。
SuperCashやTotalCashなどは有名で、誰しもが使っている可能性もあります。
なぜ不採用にしたのかというと、詳細な設定を施さないと、キャッシュデータが変なことになるからです。
例えば、とあるページを最初に見た方が、スマホ端末からだった場合、スマホの表示をキャッシュします。
そのうえでその後PCで接続すると、PCのデザインではなくスマホの表示のキャッシュをロードしてしまうケースが多いのです。
これは、デザインテーマがレスポンシブデザインではあるのですが、CSSのロードの部分でスマホ用のCSS、PC用のCSSなどを分けていた場合によくおきます。
また、設定をうまくしてやらないと、管理者がログインしている状態でトップページを開いてキャッシュされた場合、WordPressの上部に出てくるメニューバーが一般ユーザにも見えてしまう時もあります。
キャッシュプラグインは現状主流のデザインテーマにはあまり合わないのでプラグインの採用は見送ることにしました。
nginxWEBサーバー側でキャッシュを持つ
しかし、やはりキャッシュを持つようにするのは、パフォーマンス改善の初歩的な一歩です。
なので、nginxがわでやれることはやることにしました。
これは、当サイトで採用しているサーバーにはPleskを導入しており、Pleskのばあい、ドメイン単位でサーバーの設定をすべて変えることができますから、当サイトのためにチューニングしたとしてもほかのサイトには何ら影響しません。
なので、各ドメインサイトに合わせてチューニングすればいいのです。
PleskであればnginxのキャッシュのON/OFFもワンクリックです。
またキャッシュ最大サイズ、タイムアウト設定404エラーの場合などの設定もGUI上からできますので、最適だと思われる設定を入れてONとしました。
これで、サーバーキャッシュが設定されます。
これで、よく接続されるページは、DBやPHPに触れることなく表示されるケースが増えます。それだけパフォーマンス向上に寄与します。
圧縮処理もWEBサーバーで
おそらくプグインもあるのでしょうが、nginxで直接対応する歩ぐア早いのでgzip圧縮の設定を追加。
jpgや、jsなど圧縮したい拡張子を入れながら圧縮処理を行いました。これによりファイスサイズの減少が認められ、クライアントのペイロード値が下がることになります。
クライアントキャッシュ（ブラウザキャッシュ）
こちらの設定もnginxで行いました。
こちらもプラグインはあるっぽいのですがうまく作動させることができなかったことと、nginxに直接書く方が楽なので、nginx側で調整。
特に大容量になりそうなWebフォントやjs、css、画像関係等をブラウザキャッシュ化しました。
これによりずいぶん楽になったはずです。
最終パフォーマンスはいかに？？
Googleのパフォーマンスチェックツールでチェックをしています。
こちらはちょっとの反応で点数が変わってしまうのでなかなか難しいのですが、赤色→黄色程度は改善できています。
サーバーのスペックがかなり低いので緑はなかなか難しいのですがそれでもちらほら出始めました。
そして、注意項目は改善できる項目は、サーバーのスペックアップ推奨のみとなり、診断項目もほぼなくなりました。
https://www.webpagetest.org/
こちらでパフォーマンステストをした結果、圧縮以外はAクラスと、上々のパフォーマンスまで向上しました。
体感では、従来の2倍程度読み込み速度が向上したと思います。
今まではもっさりしていた感じでしたが、チューニング後はとりあえずテキストデータは先に出てきて画像はちょっと遅れてやってきますが、ストレスが溜まるほどのものではないです。
Webサイトには3秒の法則というのがあり、WEBページに接続して、最初の3秒で何を伝えられるかでその後の閲覧者の行動が変わると言われています。
Webサイトはやっぱり最後まで読んでもらって意味があるわけですから、最初の3秒で、【あー遅い。。。こんなサイトダメだ。。。】と思わせてはいけないわけです。少なくともこれはクリアしたかなと思っています。
