ネイルブログ HP再生請負人～Vol.2 – サイト表示高速化せよ！～

まずは検索エンジンにインデックスクロールを許可したネイルブログですが。。。次はブログのデザインや構成などを修正しました。

今まで通りのブログ活動を行ってもらいながら、バックヤードでは様々な改変を行いました。

サイトの表示速度徹底改善

今の検索エンジン（主にGoogleさんですが）は、記事のクオリティだけではなく、サーバーの反応速度もチェックしています。
より早い方がいいのですが、これがまた、そう簡単に行かないのです。

キャッシュとレスポンシブデザインと。

まずはサイト高速化の第一歩はキャッシュです。
幸いにもネイルブログのS社さまはブログはWordPressで作成しておられたので、キャッシュプラグインを導入することで容易にキャッシュを持つことができます。
最初は著名なキャッシュプラグインを入れたのですが、これがどうにもうまく動きません。

レスポンシブデザインの場合、キャッシュがPCのデザインでキャッシュを持つと、スマホで見てもPCのデザインのままになってしまう
ログインしている状態でサイトにアクセスすると、WordPressの上部の管理バーごとキャッシュしてしまうことがある

など、おそらく詳細設定をすれば解決するのかもしれませんが、どうにもうまくいきません。
また、この先画像のWebP化も計画していたのでやはり、ただのキャッシュプラグインではダメだな。。と。
そこで、キャッシュプラグインではなく、キャッシュ、画像の遅延読み込みなど一括で最適化設定ができるプラグインを導入。そちらのWebキャッシュ機能でキャッシュを持たせました。
こちらはレスポンシブデザインにも、ログイン時はキャッシュ除外などの機能が標準だったので、それこそ【素人】でも扱えるように設計されていたので扱いやすかったです。
他にもCSSの最適化（該当ページで利用されていないクラスやIDのスタイル記載を削除したり遅延読み込みにしたり）とJavascriptの最適化（JSファイルの遅延読み込みや利用していない処理部分の削除など）も同時に行うことで読み込み量を減らすことに成功しました。
このプラグインだけでも体感速度は3倍以上向上しました。

サーバーが重い。。。けどサーバーの移動できないワケ。。。

本当はもっと高速なサーバに移転すれば済むことでもあるのですが、これが簡単にできないのです。
なぜなら、ショッピングカートシステムをレンタルしていて当ドメインはこのレンタルカートで運用しています。
そして、ブログはそのドメインの下階層。/blog/というディレクトリにオマケオプションとして展開されていて、ドメインを移転する＝レンタルカートを辞めることにつながります。
ブログのためにショッピングカートを切り替えるのは本末転倒ですから。ブログの高速化のためだけにサーバーの移転は検討できません。
そして、すでにある程度のアクセスが集まってしまっているためドメインを分けて別のサーバーで運営するにしても、ワンクリックでハイ切り替え！終わり!!!みたいな感じにもいきません。
301リダイレクトを利用してGoogleの評価を引っ越す必要があります。
なので、もう少し落ち着いてからやろうねと言うことにしています。
それにしても、このレンタルカートシステム内のブログは重い。。。
カートは重くないんですが、WordPress用のWebサーバかDBが重いのでしょう。これについてはVol３でお話ししますが。

画像のリサイズとWebP化と。

次は本丸ともいえる画像の処理に手を付けました。
基本的に、こちらのお客様もHP運営のプロではなく、ネイル商品の販売のプロです。
だから、WEBのことについては門外漢です。
ほとんどの場合、誰しもがそのような立場ですよね。
だって、WEBサイトで食ってるんじゃなくて、WEBサイト経由でお客さんがネイル商品を買ってくれるから食えているんですもの。

だから、画像のサイズがでかいw

最近のスマホは設定をいじらずとも大きなサイズの写真を撮ります。
たぶん長辺4000pxを超えます。
WordPressでアップした際は設定されているサイズにリサイズした画像も作ってくれますが、元の大きな画像もそのまま保持しています。
記事などで画像を使う時に設定されているサイズを指定して画像を使えば大きな画像を使うことはありませんが、デザインテーマの背景やスライド画像などで設定する画像の場合、元画像ををのまま使い単に最適なサイズに縮めて使っているケースが多く、そうなると、1000pxに縮めているけど画像サイズは実は4000pxという、無駄なパケット通信量を使っていることも多いのです。
必要以上に大きな画像をWordPressにアップしておく必要は全くありませんので、まずは最大サイズを決めてそれ以上に大きなサイズの画像は設定したサイズに元画像をリサイズするプラグインを導入しました。
導入時点は、一括でリサイズの処理をしますが、今後はS社長は意識しなくても勝ってにリサイズします。
本当の元画像はスマホやPCに保存されていますので、WordPressの画像をリサイズしても他（チラシやほかのWebサイトで利用する際）には影響しません。
まずは画像をリサイズするだけでディスク容量は30%近く削減できました。これは、最終的には見に来たお客さんのパケット通信量の削減につながります。

WebP画像でさらに省力化

つぎに、画像をWebP形式の画像を作ってWEBサイト内の画像を可能な限りWebP化してくれるプラグインを導入しました。
外部サイトでWebP化する機能は最初に説明した一括最適化プラグインにあったのですが、それは外部サイトとの通信が発生するので、内部だけで収めることができるこのプラグインを入れて内部でWebP画像を持つようにしました。
重いサイトなので、画像だけでも高速なサーバーに流すのも考えましたが、将来ブログだけでも高速なサーバーに引っ越すという流れになったときこれまた大変になりそうなので、内部完結型で構築しました。
こちらも1発目は一括コンバート処理が必要ですが、次からは画像をアップした時点で自動的にwebp画像も作ってくれて、更に記事を書く際も何も気にせず今まで通りで勝手にwebp化されます。

ざっくりでWebp画像を採用することでパケット通信量にして、30~50%の削減に成功しました。

cronとアップデートと。

WordPressは、wp-cronという疑似的なcronシステムが採用されています。
これは、WEBサイトに誰かアクセスしてくるたびにwp-cronというシステムが裏で動き、定期実行のタイミングをチェックして定期実行をするべき時間になったら実行してくれます。
そして、WordPressは最近プラグインやコアシステムが自動アップデートが可能なようになりました。
これにより、WP-Cronへの負担が増大し、潤沢なリソースを持たない、いわゆる重いサーバーの場合、アクセス不能になるほどのレベルで重くなります。
この時点ではアクセス不能レベルにはありませんでしたが、たまたま私はこの記事を書いているブログでアクセス不能になる事態を経験しており、1日5000PV程度になると、1秒の間に2人以上がアクセスしている、同時アクセスになってしまう可能性がかなり増えてきて、同時アクセスが2~3人程度でアクセス不能になる可能性があることがわかりました。
だから、まず、標準設定のアクセス毎にwp-cronの発動をやめ、本当のcronシステムを利用して定期実行を促すようにしました。
そもそもwp-cronをアクセスから外すだけで、cronチェックが実行されなくなりますから体感でも20%以上の高速化が測れます。
また、定期的にLinuxcronで、定期実行が発動しますから、予約投稿やプラグインなどの自動アップデートも従来どおり実行が可能になります。

これで、バックヤードでの高速化設定はひと段落です。

Vol.3へ続く。。。