本記事ではWordPressの高速化の原理を解説すると共にその構造と高速化の原理について調べた事をサーバーの仕組みとか分からない人でも分かるようにまとめてみました。
サイトの表示速度については昨今GoogleSpeedInsightを発表したり検索結果にもページの表示速度が考慮された結果が反映されると言われておりますし、ユーザーはクリックして3秒以内に次のページが見れなければ高い確率で離脱するとも言われています。
逆にページの表示速度が早ければ早い程ユーザービリティの向上に繋がり滞在時間が長くなると言う結果が報告されております。
Googleさん：読み込み時間が 500ms 遅くなることで、検索件数が 20％ 減少した。
Yahoo(日本)さん：読み込み時間が 400ms 遅くなることで、ページが読み込まれる前に「戻る」をクリックした人の数が 5～9％ 増加した。
上記の事からわかる事は ミリセコンドの単位でページの高速化が求められていると言う事ではないでしょうか。
高速化の結論をまとめ
この記事は長いので興味がある項目だけをじっくり読んで頂ければそれで良いかと思います。
恐らくWordPress高速化に興味がある人なら、既に知っている項目も多いと思います。
それでは今回調べてまとめた事を超ざっくり一覧にします。
以下がこの記事に書かれている内容です。
- PHP5.3→7に変更するだけで約3倍速くなる
- mod_pagespeedはWordPressの表示速度を約2.8倍早くする
- サーバーキャッシュは2回目以降のアクセスを早くする
- ブラウザキャッシュはユーザーが2回目の訪問以降で早くなる
- Apache2系→Nginxに変更すると約18.2倍速くなる
- 画像圧縮とスクリプト圧縮は場合によってはファイルサイズを60％以上も軽減する
- 非同期処理を行うと表示が先に来て後からJS機能を読み込む
- URLの記述の仕方に気を付けるだけでリダイレクトが減らせる
WordPressがページを表示するまでの流れをざっくり説明
WordPressやWebサイトの高速化を実現する為には、【どうやってページがブラウザで表示されるのか？】と言う仕組みと構造をざっくりとでも良いので理解しておく必要があります。
どんな経路を辿って我々のブラウザで見れるようになっているのか？と言う事を理解しましょう
上記のように、ユーザーがサーバーに対してURLのリクエストを出した時にサーバーがファイルを処理して、ユーザーのリクエストに答えると言う超ざっくりした解説です。
サーバーはリクエストを受けた時に、ファイルを探してプログラムだった場合は、プログラムモジュールにそのファイルを渡して解析させて居ます。
例えばWPの場合はPHPと言うプログラム言語で出来ていますからPHPモジュールにリクエストのあったファイルを投げつけてPHPがプログラム処理をして、その解析結果を受け取ります。
PHPファイルの中にはデータベースでデータを指定しているものがあると、データベースにアクセスしてデータを取得して来て解析結果を出します。
サーバーの役割はそれらを最終的にHTMLファイルに変換してユーザーにデータを渡すと言う作業を日夜行っているわけです。
キャッシュ処理が高速化に対して有効な理由
上記の図を見て頂いた方は既に理解出来たかも知れませんが、サーバーはリクエストに対してPHPにファイルを渡したり、他の関連するファイルを読み込みに行ったりデータベースのデータを取ってきたりと大忙しなわけです。
キャッシュ化の構造があれば、同じファイル(URL)のリクエストがあった場合は、以前リクエストがあったかどうかを判断して、あればキャッシュされたHTMLファイルを『ぽいっ！』と返すだけですから、CPU負荷を掛ける事も無くリクエストをスムーズに処理する事が出来ます。
例えばindex.phpと言うファイルのリクエストがあり、更に1秒後に同じファイルのリクエストがあった場合どうでしょう？
通常ならまたまた同じファイルのリクエストの処理をするためにPHPにファイルを渡したりと言う作業をしなければならず、サーバーのCPU負荷とディスクアクセスはどんどん加算されて行きます。
今初めて出てきた単語、ディスクアクセスとは普段、私達がPCを触っている時に『ジジジジジ・・・』とハードディスクが動いてる音がしてますよね？SSDの場合は無音なのですが、何が言いたいかと言うと、CPUの負荷だけではなく、データを取りに行くだけでもハードディスクに負荷を掛けてページが生成されていると言う事を、今後の高速化の知識を理解する為に軽く覚えておいて下さい。
ちなみにサーバーの記憶領域がHDDの場合は
このように、超高密度のDVDのようなディスクが格納されており、丁度アナログレコードの様な針がデータを読みに行ってるのです。ですから、針が動いて該当データの位置に針が到達するまでの間の時間(コンマ数秒)ではありますが時間のロスタイムがあるわけです。
一方SSDの場合は
上記のような構造になっておりシリコンドライブと言う方式が採用されており、データを読みに行くのに針を使わずダイレクトにデータアクセスする事が可能になってますから、HDDよりも数段アクセスが早くデータの読み込み速度が増していると言うわけです。
WordPress高速化を実現するための要素
かなりざっくりではありましたが、前章でWebページが表示される仕組みは理解して頂けたかと思います。更に前章を踏まえた上でサイトの高速化には大きくわけで4種類の高速化の手法があります。
- キャッシュによる高速化
- サーバー実行速度による高速化(例 PHP5.6→PHP7)
- ファイル数を減らす高速化
- 読み込み量を減らす高速化
上記を以下の章を追いながら１つずつ解説して行きたいと思います。
ちなみに上記部分の大半は通常のワードプレスで出来る高速化の手法ですからKUSANAGIユーザーでなくとも実施する事が出来ます。
極論としては静的HTMLが最速である
実はワードプレスは普通に手作業でファイルを作って作りあげるサイトよりも、かなり重いです。
汎用性に特化してるCMSだからアレもコレも全てに対応出来るように作られていますから、ユーザーAが必要な機能でもユーザーBにとっては不要な機能かも知れません。
しかし、不要だとしても全てを踏まえてWPですから、Webサイトの表示の時には一応不要なモジュールも読み込みされているものもあるわけです。
プラグインにしても、テーマと重複するCSSや元のテーマのCSSを無視するCSSが後から追加された場合、不要なCSSのコードが重複するが、それもサーバーリクエストがあった際には読み込まれていると言う汎用性特化のデメリットが出ていると言えるでしょう。
本当に極限まで高速化するには、不要なものを全て読み込ませないのが一番です。
例え半角スペース1個でも不要な文字列なら読み込ませないぐらいの極限は恐らく無理です。
出来たとしても、WPのメリットである『お手軽さ』が著しく損なわれてしまいますし、記事を書く事に集中する事すら出来なくなってしまい本末転倒になってしまいますから、更新不要か頻度の極めて少ないのコーポレートサイトなら、そう言った極限チューンもありだと思います。
もっと言うなら、WPでサイトを作ってテーマを導入して記事を完成させた時点で、WPで表示されるページのソースコードを全てコピーしてWPを削除し、コピーしたHTMLだけを設置し直しコードの不要な部分を削除すると究極に早いWebサイトが出来るかと思います。
しかし、本記事ではそこまでは求めず、極限とは言っていますが、『利便性を損なわない範囲での高速化』を目指して高速化を解説して行こうと思います。
キャッシュによる高速化の方法
上記でもキャッシュの仕組みをざっくりと説明しましたが、この章ではキャッシュの仕組みを更に詳しく理解するべく解説して行きます。
キャッシュには更に大きく分けて2種類の方法があります。
- ブラウザキャッシュ
- サーバーキャッシュ
上記2点がキャッシュの高速化の手法です。
ブラウザキャッシュの解説
ブラウザキャッシュとは、ユーザーそれぞれのブラウザ(Chrome/Firefox/safari)などの、それぞれのユーザーが使用するインターネットブラウザのキャッシュに覚え込ませようと言うのがブラウザキャッシュの仕組みです。
上記のように一口にデータを読み込むと言っても沢山の種類のデータがあります。
JSやCSS・JPEGなどの画像ファイルなども読み込みますから、画像が多ければ多い程サーバーの通信頻度は上がりますし、サーバーとブラウザの間でやり取りされるデータ容量も増えます。
ブラウザキャッシュはそれらを極力少なくする事で『表示の高速化』を図ろうと言うものです。
一度読みこんだJSやCSSや画像は2回も読み込まなくても、前に読んだファイルがPCやモバイル端末のキャッシュと言うフォルダに保存されており、2回目からのアクセスではそこで保存されている画像が表示されているのです。
しかし、デフォルトの設定ではブラウザキャッシュが読み込まれなかったり読み込んだりと動作がバラバラになる事もあります。
それらを.htaccessを使って明確に設定する事で2回目以降のアクセスを必ず早くすると言う事が出来ます。
その設定は以下の通りです。
# BEGIN Browser Cache <ifModule mod_expires.c> ExpiresActive On ExpiresByType image/png "access plus 1 months" ExpiresByType image/jpeg "access plus 1 months" ExpiresByType image/gif "access plus 1 months" ExpiresByType text/css "access plus 1 months" ExpiresByType text/js "access plus 1 years" </ifModule> # END Browser Cache
上記はファイル『.htaccess』を編集してCacheの動作を明確に記載するものです。
基本的には英語で書かれていますから、サーバーの設定なんて分からないと言う人もなんとなく理解は出来るのでは無いでしょうか。
この設定では、画像・CSS(png,jpeg,gif,css)のファイルは最初にアクセスした日から、1か月間はキャッシュしてね！と言う設定です。
ブラウザキャッシュのデメリット
ブラウザキャッシュのデメリットとして知っておくべき事は、更新してもすぐには更新が反映されないかも知れない。と言う事です。
例えばユーザーがCSSを編集する前のタイミングでアクセスし、その後、管理者がCSSに修正を加えた直後に、再びユーザーが同じページにアクセスしてきた場合などは、ユーザーがブラウザのキャッシュをクリアしない限り【前回読み込まれたCSSが採用されている】からです。
前章の設定でCSSのキャッシュ期間は1か月ですから、キャッシュをクリアしない限り1か月はCSSの変更が反映されない事になります。
そのような場合に気を使うべきことは、style.css?20180410 などとして変数を付けてファイル名を別名に変更してやる事で解消する事も出来ますがWPではそんな簡単には出来ません。
キャッシュの有効期間を適度な期間に調整する事が利便性を保つカギとなるでしょう。
リダイレクトを減らして高速化
読み込み速度を極限まで高速化すると宣言していますので、ちょっとそれ細かいよ！と言われるかもしれませんが、ボディーブローのように効いてくる小技ですけど、地道に実践していく事で最終的には大幅な高速化が見込めます。
ワードプレスのサーバーリダイレクトを減らす
Aの記述方法 https://yahoo.co.jp/category/ Bの記述方法 https://yahoo.co.jp/category
ん？同じじゃん！と思うかも知れませんがワードプレスではリライトモジュールと言われるリダイレクトが発生しています。
細かいよ！って思ったと思います。
しかし、Bの記述法だとリダイレクトが発生してしまうんですよ！
これ1回で済む所をあえて2度手間になってしまっている事に気付いて下さい。
小さな事ですが、大きなロスに成り得ます。
アナリティクスのリアルタイムアクセスが50人居たとしたら、それだけで2回ずつアクセスさせる事になるので2倍の負荷がサーバーに掛かってくるわけですから、同時処理100人処理できるサーバーだとしてその半分しかサーバーの性能を出しきれない事になってしまうのです。
もっと言いますと、
訪問者A：『ごめんくださーい』
サーバー：『はーい！』
訪問者A：『ごめんくださーい』
サーバー：『いや、さっき返事しましたやん！』
と言う状況になっていると言う事です。
こんな事を50人もの人に同時にヤラれたら、あなたはイライラしませんか？
ファイルの圧縮で高速化
GoogleSpeedInsightでも推奨されている方法ですが、画像の最適化は良いとして画像ファイルの圧縮は少々CPUを圧迫する事になります。
多くの画像ファイルが表示されるようなサイトでDEFLATEを使うと、しょぼいレンタルサーバーや1つのサーバーアカウントに複数のWPを設置しているような環境では逆に表示速度が遅くなる事もありますので、サーバースペックを確認しながら使用するようにして下さい。
ファイル圧縮とは何か？
ファイルの圧縮と言われても良く分からないと言う方も多くいらっしゃると思います。
ファイルの圧縮とはズバリMinifyです(ミニファイ)って聞いたことはあるけど、良く分かりませんよね・・・説明します！
上記は未圧縮状態のCSSです。ちなみにサイズは 107kbです。
上記が圧縮済のCSSファイルとなりサイズは72kbで約30％も圧縮されています。
このように、たかがスペースと改行を除くだけでも、ファイルサイズは大きく圧縮され、通信容量もこのCSS単体で考えれば30％も節約されているのです。
たかが30kbの通信量ではありますが、これがWPとなると1ページ表示する際に読み込むファイルの数は膨大で、テーマファイルにも寄りますが、約20ファイル程も読み込まれるのです。
更にアイコンや細かい画像のファイルも含めると数百ファイルにも及び、合計の通信容量は1M２Mと節約出来る事になった結果が1秒2秒の高速化に繋がるわけです。
上記のファイル圧縮を設定する場合は以下の通りです。
<ifModule mod_deflate.c> <IfModule mod_filter.c> AddOutputFilterByType DEFLATE text/html text/xml text/css text/plain AddOutputFilterByType DEFLATE image/svg+xml application/xhtml+xml application/xml AddOutputFilterByType DEFLATE application/rdf+xml application/rss+xml application/atom+xml AddOutputFilterByType DEFLATE text/javascript application/javascript application/x-javascript application/json AddOutputFilterByType DEFLATE application/x-httpd-php application/x-httpd-fastphp AddOutputFilterByType DEFLATE application/x-font-ttf application/x-font-otf AddOutputFilterByType DEFLATE font/truetype font/opentype </IfModule> </ifModule>
上記は【.htaccess】のファイルに記述する事で画像やJSなどのテキストドキュメントを圧縮(minifyではない)する事によって高速化を狙うと言う設定の例です。
GoogleSpeedInsightで提案される画像最適化済みのファイルとの違いは、Googleで提案される最適化画像は画像を物理的に最適化された後の画像です。
上記で行っている画像の圧縮は、gzipなどの普段みなさんがPCのデスクトップなどでファイルを圧縮する時に使っている圧縮方法だと解釈して頂ければと思います。
画像圧縮と言えばWPのプラグインで有名なEWWW Image Optimizerがあると思いますが、あれは画像の最適化であり、JPGなどの画像で使用していない色を省略して簡素化した結果、画像のサイズを軽量化すると言うものですので、上記のファイル圧縮とは別物になります。
CSSスプライトによる高速化の方法
CSSスプライトとはサーバー上に沢山ある画像を1枚の画像にまとめてしまいサーバーリクエストを受けた時にファイルアクセスの回数を減らす事によって高速化すると言う手法です。
イメージとしては上記のような感じになり、どのようにして使用するかと言うとCSSで画像の位置をを決めて表示すると言う手法を使います。
具体的には
.sprite{
background:url("sprite.jpg");
width:90px;
height:90px;
background-position: 180px 0;
}と言う風に画像の一部分を切り取るようにして使う手法がCSSスプライトです。
Webページを表示するだけでも、1ページ中に沢山のファイルが含まれています。
その中の画像ファイルだけでも10や20は軽く超えます。
その画像ファイルを1つにまとめる事でファイルへのアクセスが20回ある所を1回で済ませてしまおうと言うのがCSSスプライトの極意です。
最近ではアイコンやフォントファイルを一括で読み込めるAwesomeFontと言うCSSフレームワークではSVGと言うイラストファイルを使う事でこれを実現しています。
※上記画像はLopan.jpさんからの引用です。
このようにCSSスプライトの技法を使って表示する画像3倍近くも表示速度が向上しますので、CSSスプライトは絶大な効果が期待出来る非常に有効な手法です。
CSSスプライトのデメリット
CSSスプライトはWPでも実装する事は可能です。
ただ更新が非常に手間が掛り面倒くさいのです。
私に言わせれば相当面倒くさいから嫌いです。でも、1ミリでもページ表示の速さを求めるのなら是非にとも利用したい手段であります。
mod_pagespeedを利用した高速化
天下のGoogleさんが開発したmod_pagespeedと言うサーバモジュールがあります。
この技術は前章のCSSスプライトの原理を利用した手法でページを表示するのに必要なファイルを自動で合体させて高速化してしまおうと言う手法を用いています。
mod_pagespeedをOnにして利用した場合は上記のようなイメージになり、ページを表示するのに必要なファイルを合体させてファイルアクセスの回数を劇的に減らして高速化するモジュールです。
ちなみに共用レンタルサーバーで使えるのはエックスサーバー
だけになります。
しかし、VPSや専用サーバーではSSHが使えてRoot権限のあるサーバーであれば意外と簡単にインストールする事が出来ます。
GMOクラウドVPSでもmod_pagespeedをインストール可能です。
エックスサーバーは共用レンタルサーバーで標準装備されているだけあり、管理パネルから簡単にOnOff出来るメリットがあり、インストールすら不要で利用出来る点がお手軽です。
サーバーモジュールの選択による高速化
前章までがソフトウェアによる高速化の手法を解説してきましたが、以降はサーバーによる高速化の手法について解説したいと思います。
ハードウェア的な高速化です。
ハードウェアによる高速化とは、普通のレンタルサーバーでは変更する事が出来ないような選択肢も含まれて来る領域です。
この領域までくると、さすがに共用レンタルサーバーでは限界を感じてくるレベルではないかと思います。
PHPのバージョン変更だけで処理速度が3倍早くなる！
最近の共用レンタルサーバーでは多くの場合はPHPバージョンの選択が出来るようになっていると思います。
このPHPのバージョン選択の違いだけでもページ表示速度にも大きな変化があります。
例えば、PHPモジュールの選択では、PHP5.6を利用するよりもPHP7系を選択した方がメモリ消費量を考えてもCPU負荷率を考えても両方の面でPHP7系を使う方が有利になります。
特にPHPのOPcacheの効果は絶大でかなりの高速化が体感出来るレベルで変化があります。
上記画像はQiitaさんよりお借りしております。
PHP5.3~7のバージョンとパフォーマンスを比較した速度計測の平均値です。
PHP5.6と7を比べた場合でも単純に実行速度に3倍もの差が生まれています。
メモリ消費量ではPHP5.3と比べれば良い方ですが5.6と比べた場合はメモリの消費が増えています。
それでも実行時間の3倍の開きはメモリ消費をしてでも手に入れたい数値ではないでしょうか。
PHPはCGI版とモジュール版どっちが早い？
PHPは7系が早いのは理解したけど、レンタルサーバーやVPSの管理パネルではCGI(Fast-CGI)版とモジュール版が選択できるようになっている所が殆どです。
多くの共用レンタルサーバーではFast-CGI固定と言う所が多いですが、これはセキュリティ面の問題が共用サーバーでは発生する可能性がある為にFast-CGIが選択されています。
一方フルマネージドのレンタルサーバーではモジュール版と選択可能なサーバーがありますが、両者を選ぶなら迷わずモジュール版を選択する方が早いです。
Fast-CGI版は共用サーバーで多く使われる為にセキュリティ面を優先された結果、【Webサーバーと切り離されたプロセスで実行されるPHP】と言う意味です。
レンタルサーバーの殆どはApacheかApache2系を利用している事が多く、本来ならばApacheが持つモジュールの中の一つとしてPHPが実行され動作しますが、Fast-CGI版ではその実行が切り離されて動作している為にメモリのロードではモジュール版と比べて小さく小回りが利くような動作をしますが、実行速度としてはApacheと別で動作する為にロスタイムが生じてモジュール版と比べると若干動作が遅くなります。
分かりやすく言うと、Fast-CGI版は二人三脚で動作するのに対し、モジュール版はアパッチ君が単体で動作していると言う状態ですから、これは誰が見ても1人で走る方が早いでしょ！と言うイメージで問題無いかと思います。
パフォーマンス面やCPU負荷の面で圧倒的にモジュール版の方が優れています。
ただし、メモリのロードについてはモジュール版の方が少し不利になります。
HTMLの記述は上から下へ読まれている
当たり前の事かも知れませんが上から下へ順番に読まれていると言う事は、上の方にJSなどの読み込みファイルを置いておくとJSを読み込みしないとダメな分、表示速度が遅くなります。
ですから、JSは出来ればCSSを読み込みHTMLが全て読み込み終わった後でJSが読み込まれる状態が好ましいのです。
最近のWPのテーマ(Cocoonやその他の高速化重視のテーマ)では既に対策されていますので気にする必要が無いかも知れませんがチェックはしておくべきです。
ApacheとNginxのメリットとデメリット(18.2倍速くなる)
結論から言うとどちらのサーバーも一長一短です。自分が運営するサイトの特徴を捉えてサイトの特徴に合ったエンジンを選ぶのが正解だと思います。
ApacheやNginxと言う言葉は聞いたことあるけどイマイチ分かって無い方の為に説明しますと、両社はWebページを表示するためのエンジンの事です。
ApacheサーバーとNginxサーバーの違いはリクエストの処理の方式に違いがあります。
Apacheはマルチスレッド処理でユーザーからのリクエストを全て並列にリアルタイムで処理します。
Apacheはマルチスレッド方式でリアルタイムでスムーズな処理が行われるように見えるが、同時に大量のアクセスが流れて来た場合CPUにガツンと負荷が掛かる為に、そうなった時に大きくオーバーヘッドが発生します。
簡単に説明すると、短期間に大量のリクエストが来た場合にCPUの負荷が大きく掛かる為に処理能力が一時的に大きく落ちます。
また、DDOS攻撃を喰らった場合サーバーダウンしやすいデメリットもあります。
DDOS攻撃は1秒間に5万リクエストや10万リクエストを送ったりと、物凄いリクエストを短時間に送る事でサーバーを攻撃する手法です。
Nginxはシングルスレッド方式を採用しており、どれだけのリクエストが来てもキューに一度リクエストを貯めて置いて順番に処理を行っていきます。
デフォルト設定ではCPUコア数と同じスレッドだけ処理しますので、サーバーが４コアのサーバーであればNginxでは４スレッドのシングル方式で処理しますから、契約するサーバーのCPUコア数によって処理能力に大きく依存します。
また、Nginxの最大のデメリットは処理が長くなるような重い処理をNginxにさせる場合は、シングルスレッド方式なので、処理の重さがボトルネックとなり、糞詰まり状態になります。
またNginxはApacheと違い前章で解説したような.htaccessで設定出来るようにはなっていません。
どんな場合が重い処理か？
一番はWebクローラーをNginxのサーバーで運用するには向かないでしょう。
クローラーとは無人でネットサーフィンを行い、ネット上の情報を自動で集めてくるような定期実行型のプログラムの事を言います。
Nginxはこんな処理が得意
アクセス数を稼いで収益を上げるようなWebサイト、例えばアドセンス狙いのサイトであればNginxの方が大量のアクセスが来ても安定してリクエストを捌く事が可能になります。
アクセス数を望まずに、それでいて同時処理で0.001秒でも早くリクエストを処理したい場合はApacheを選択するべきでしょう。
単純処理性能ではNginxはApacheよりも1.47倍の処理能力が高いと評価されています。
※Nginxユーザー会より
ここまでのまとめ
本当はKUSANAGIの高速化の仕組みを書こうと思って必死でKUSANAGIについて調べたのですが、ワードプレスの高速化(標準手法)を解説しているうちに1万文字を超えてしまったので、次回の記事に続きを書こうと思います。
ここまで解説した説明でも十分にワードプレスの高速化は可能だと思いますが、更に次回はMySQLのDBチューニングの件に触れてから、いよいよKUSANAGIの高速化の秘密について書いてみたいと思います。
最後までおつきあいくださりまして有難う御座いました。
コメント