いつも気にしてるわけじゃないのに、
気になりだすとハマるのがWordPressの高速化、ではないだろうか。
GTMetrix他計測と分析を行ってくれるサービスがあって、
点数評価と改善点まで教えてくれるし、
巷にはA評価（90点以上？）の高速化を果たしたハウツー記事が溢れている。
そりゃわずかな手間で早くなればそれに越したことはない。
が、数個のWordPressで試してみた感触を言えば、そんなに簡単にいくものか？という疑問が拭えない。成功譚ばかりじゃなくて失敗譚とか（これはないことはない。キャッシュ系プラグインとかで）、変わらん譚とかも書いて欲しいなあ。それとも、ホントに皆すんなり成功しているのであろうか…。
「私はこれで早くなりました」的なサイトにアクセスしてみると、案外読み込みに時間がかかって、ふ～ん、とGTMetrixで計測してみる。と…、タイムオーバー？的なエラーになって、ちょっと記事の信ぴょう性疑ったりするのは、ただ私が意地が悪いだけか？
なんてことをやる前に、もちろん信じてあれこれやってみたりはしたのよね。でも、改善は微々たるもの。不思議なのは一瞬スコアが高くなったのがやればやるほど悪化したこと。最初 Page Speed Grade/YSlow Grade がB83/D68、WP Super Cache を有効化（入れてはあった）した後だったか、一瞬だけA90/C73 をカウントしたものの、以後 必要があって他のプラグインを入れたのが悪かったのかスコアはまた下がり、Autoptimize 入れたり、画像圧縮プラグイン入れたりあれこれやってもやってもB80～83/D69（一切変化せず）のまま。
まず、高速化にはサーバーの能力というハードルがある。海外記事の翻訳に、月5ドル程度のレンタルサーバーで高速化を望むなんて100年早い、とまでは書いてなかったけど、そりゃ限界はあるさ、という痛いところをつく声もあり。
おまけに今回つくづく思ったのは、Windowsサーバーは.htaccessが使えず、サーバーキャッシュの利用やファイルのgzip圧縮の設定が（できないわけではないだろうが）簡単ではないこと。なので、.htaccessが必要だったり自動生成するプラグインは使えないのが基本。Autoptimize がこれで、エラーにはならなかったものの、自動圧縮してくれてるはずのファイルが改善余地大の項目に出てくるので、結局停止させた。
それでも、不要な画像は削除したり、トップページに出てくるのや最近の画像だけでも圧縮しようとWP Smush でスマッシュしてみたりした。ちなみにEWWW Image Optimizer という高圧縮率高人気のプラグインは、ExpressWeb では必要なモジュールだかがないため利用できない。
あとはサーバーキャッシュの設定を以下を参考にweb.configに書いてみた。
・.htaccessファイルをweb.configに変換する際の注意事項
（URLの書き換えなども web.config で行うが、そのあたりはExpressWebのマニュアルにもあったと思う。）
これがどれくらいの効果があったのか、GTMetrixの計測は時間によって、サーバーアクセス数の多寡によっても変わってくるので、その都度計測しなおしてもよくわからない。それでもプラグインと違って（もし効けば）確実だろうとそのままにしてある。キャッシュは画像系ファイル、.css .js など。
あとはCSSやJavascriptをminifyしろ、というサジェスチョンが出る。あるいはCSSを一つにまとめろと。minifyはウェッブで出来るので試しに子テーマのCSSから一切の視認性を取り払ったたった二行のCSSファイルを作って差し替えてみた。ただし、自動でミニファイすると冒頭にあるコメントまで削除されてしまう。子テーマの頭に必要なコメントと親テーマの＠importは記述しなくてはいけない（この作業のためには、web.config のCSSキャッシュは一旦はずさないといけない）。
・Online JavaScript/CSS Compressor
が、このあたりまでやはりほとんどスコアの数値は変わらず。
自己解決のハードルでもうひとつ高いのがテーマの構造である。マガジン風当テーマは画像のサムネールがトップページに多用されている。この画像をサイズ指定しろと言われても、画像表示とサイズの設定がfunction.phpその他いくつかのテーマファイルに分かれていて、これのどこをどうすればサイズ指定ができるのかが皆目わからない。たぶん出来ないんじゃないだろうか。おかげでRecommendationトップのSpecify image dimensionsのスコアは常にF（0）のままである。
もう一つ、画像関連でどうしようもできないのは、Twitterの読み込み画像。アカウントアイコンの画像や添付画像が75％圧縮できるよ～と言われてもどうしようもない。いっそ外してまおう、とTwitter表示をやめてみた。
また、当テーマのMH Magazine Liteはウィジェットの多用が特徴でもあり、魅力でもある。で、どこかで紹介されていた WP Widget Cache を入れてみた。これはウィジェットの各項目それぞれで設定し保存しなおす必要がある。
さらに、WP File Cache とMO Cacheも有効化。このあたりに来ると、なんというか、プラグインを入れることによって重くなるのと、そのプラグインの高速化効果と、もしかして相殺されてない？という気もする。
なので、ほとんど反応のない拍手用プラグインMaroyaka WebClap for WordPress は停止した。
さて、ここまでで、、、、
スコアはB85/D69。
Aなんて夢のまた夢といったところである。ふんっ。
ただし、多少は改善もされた。
Page Load Time は5～7秒だったのが3.9とかろうじて4秒を切った。これというのも、Total Size が1.7Mから0.99Mに、Requests も 113から88と減ったからだろう。
この上CSSを統合しろと言われても、プラグインのCSSは更新の度に手直しするのか？と疑問だし。
あ、そうだ、画像に関してはクラウド化という手があった。JetpackのPhotonが楽で有効化しているけれど、これを上回る効果があるのかどうか。
それから WP Super Cache、.htaccessが使えないので推奨の［mod_rewrite を利用する］ではなくPHP利用としている。これがためか、キャッシュをテストで ページがマッチしません ! タイムスタンプが違うか見つかりません ! となる。htmlファイル自体は生成されるんだけれど。これでキャッシュされるんだろうか…。疑問である。［レガシーなページキャッシング］にチェックしても変わらず。［ キャッシュファイルの提供に mod_rewrite を利用する］にすれば解消されるという記事が多いけれど、それが出来ないから苦労してんだってば。
といったWindowsサーバーゆえの四苦八苦もあってふと検索したら、最近はWordPress専用のレンタルサーバーというのがあるんだね、知らなかったよ。もちろん割高だけど（最低1,000円/月位～）、高速化にこだわるならそっちを検討しろってことか。で、当ブログに関しては、そんなにアクセスあるわけじゃないし、検索からダイレクトに来る個別記事の表示は（たぶん）それほど遅くないと思うので、このあたりで作業やめようと思ったのではあった。
Googleの PageSpeed Insights でも真っ赤だったのが黄色になったし（モバイル65、PC72）。
記事投稿で心掛けることと検討課題
★画像はアップする際極力最小化すること、＆ アイキャッチ画像は表示サイズに整形すること。
★画像のクラウド化 ➾ CloudFlare を検討（でもたぶんしないような気が…）
・WordPress のパフォーマンスチューニング、CloudFlare活用、ExpressWeb
★不要なプラグインの削除
★ファイルパーミッション関連 ➾ ExpressWebではファイルマネージャーの鍵マークから設定。これでいいのか？セキュリティー…。
★web.config のキャッシング時間の設定（1週間て長くないか？）
★SNSカウンター用プラグイン WP Social Bookmarking Light を止め、SNS Count Cache を導入。SNSボタン+カウント取得はけっこう読み込みに時間がかかるとのことで、それをキャッシュして表示するというもの。表示にはコード挿入とCSS作業が必要で少しハードルが高い。
コメント