Cloudflare を辞めたので、別の方法で WordPress ブログのページ表示を高速化【目標未達成】
前回 CDN Cloudflare の利用を辞めて爆遅(というか評価がとても悪い状態)になったので、改善していきたいと思います。
まずは改善前のページスピード等調査
下記測定ツールを使って、改善の示唆を得つつ、改善度合いを測っていきたいと思います。
GTmetrix PageSpeed Score / YSlow Score Page Load Time / Total Page Size |
PageSpeed Insights PC / SP |
|
---|---|---|
作業前 | E / E 5.7s / 6.31MB |
76 / 60 |
※計測対象ページは以降同一のものを対象に計測。
目標は、B もしくは C 、3s台、80 以上といったところでしょうか。
ロリポップなら「モジュール版PHP」の利用で WordPress を高速化できる(と思った)
このブログは、ロリポップ スタンダードプランでサーバーを借りて運用しているのですが、エンタープライズプラン、またはスタンダードプランでは高速化出来るみたいです。
WordPressなどPHPで実行するプログラムを高速化できる「モジュール版PHP」をリリースしました。
「モジュール版PHP」を利用するとCGI版PHPに比べ大幅な速度改善が見込めます。
WordPressなどを高速化できる「モジュール版PHP」をリリースしました – 2015年10月20日 / 新着情報 / お知らせ – レンタルサーバーならロリポップ!
そもそもモジュール版PHPを使用していたらアレですが、私の場合は2013年だか2014年くらいに契約したので、現在のバージョンが 5.3(CGI版) になってました。
変更にあたり、幾つか注意事項がありますが、私が気にしたのは
- PHP5.6(モジュール版)ではphp.iniの設定変更はできません。
- 現在PHP5.2、PHP5.3、PHP5.4をご利用の場合、バージョンを変更すると、元のバージョンへ戻すことはできません。
という点でしょうか。
バージョン変更すると元に戻せないってことは、何かあった時にバックアップ取っておいてもすぐに復旧できないと思われますが、一応バックアップも忘れずに。
–>ロリポップ!ユーザー専用ページ – PHP設定
GTmetrix PageSpeed Score / YSlow Score Page Load Time / Total Page Size |
PageSpeed Insights PC / SP |
|
---|---|---|
作業前 | E / E 5.7s / 6.31MB |
76 / 60 |
PHPver変更 | D / E 5.2s / 6.12MB |
76 / 60 |
ま、ページ側の改善を実施していないのでスコアが改善するわけもなく、計測するタイミング次第で Page Load Time が 10s になることもありました。
管理画面の切り替えなどは、早くなった気がしなくもない。
高速化のためのプラグイン追加・削除・設定
Head Cleaner の追加
GTmetrix PageSpeed Score / YSlow Score Page Load Time / Total Page Size |
PageSpeed Insights PC / SP |
|
---|---|---|
作業前 | E / E 5.7s / 6.31MB |
76 / 60 |
PHPver変更 | D / E 5.2s / 6.12MB |
76 / 60 |
Head Cleaner | D / E 5.5s / 6.07MB |
76 / 60 |
特に改善されたという感じはしませんが、何回か計測しても 5s台 で読み込み完了することが多くなったように思います。
数日後気付いたのだけれども、Head Cleaner を有効にすると SyntaxHighlighter Evolved を使っているページ(スタイルが適用されるページ)がフリーズしてブラウザが死ぬという・・・
- Head CleanerでWordPress(ブログ)の最適化?相性悪く導入を断念。 | HCZ BLOG
- SyntaxHighlighterとHead Cleanerを併用するときの注意点 – ひなログ
ということで、Head Cleaner は無効にしました。
導入済み W3 Total Cache の設定見直し
殆ど設定変更がなかったので、計測せず。
んー、他のキャッシュ系プラグインも合わせて導入した方がいいような記事を見るけども、いくつもプラグインを導入するのに抵抗が。
Plugin Performance Profiler でプラグインのパフォーマンス測定
とりあえず、読み込みに影響してそうなプラグインを探してみる。
- P3 (Plugin Performance Profiler) — WordPress Plugins
- WordPressで負荷の要因となっているプラグインを計測できるP3(Plugin Performance Profiler) | ニトなび
その結果がこちら。
上位を占めるものの中で削除してもいいもの、、Broken Link Checker くらいかな、、。
でもこのプラグインは都度走らせるものじゃない設定(168時間毎)になってるんだけど、止めて効果あるんだろうか。
とりあえず止めた。
ついでに、Browser Shots という使っていないプラグインも止めた。
GTmetrix PageSpeed Score / YSlow Score Page Load Time / Total Page Size |
PageSpeed Insights PC / SP |
|
---|---|---|
作業前 | E / E 5.7s / 6.31MB |
76 / 60 |
PHPver変更 | D / E 5.2s / 6.12MB |
76 / 60 |
Head Cleaner | D / E 5.5s / 6.07MB |
76 / 60 |
W3 Total Cache / プラグイン削除 | D / E 4.9s / 6.00MB |
未計測 |
何回か計測していると、4s台が出るようになったけど、時間帯による誤差だよねこれ。
そろそろめんどくさがらずに、テーマの方に手をいれないと。
Contact From 7 の JS , CSS の読み込み調整
WordPress を使ってる方は、Contact From 7 をインストールしている方も多いのではないかと思いますが、GTMetrix Waterfall を見ていると、Contact From 7 の JS , CSS が全てのページで読み込まれているのを確認しました。(多くの人は「お問い合わせページ」というページを作って、そこにフォームを置いているのではないでしょうか。)
functions.php に追記するだけで、読み込みを分岐させることができるようです。
function my_contact_enqueue_scripts(){ wp_deregister_script('contact-form-7'); wp_deregister_style('contact-form-7'); if (is_page('contact')) { if (function_exists( 'wpcf7_enqueue_scripts')) { wpcf7_enqueue_scripts(); } if ( function_exists( 'wpcf7_enqueue_styles' ) ) { wpcf7_enqueue_styles(); } } } add_action( 'wp_enqueue_scripts', 'my_contact_enqueue_scripts');
【WordPress】プラグイン[Contact Form 7]で必要なときだけスクリプトとスタイルシートを読み込む方法。 – ONZE
Table of Contents Plus のスタイルシートを読み込まないようにする
Table of Contents Plus をインストールしている方も多そうですね。
TOC+ の設定ページに「プラグインのCSSを読み込まない場合チェックを入れてください。」というものがあるので、チェックを入れて、必要な分だけ CSS を styele.css に。
不要な解析タグを削除
GTMetrix Waterfall タブを開いてみて、気になったものの1つに、Juicer と言うものがあリます。皆さん導入している訳ではないと思いますので、あまり参考にならないかもしれませんが、何回かリクエストがある上に、ひとつひとつがそれなりに時間がかかっています。
–>無料A/Bテスト Juicer(ジューサー) DMPとA/Bテストで効果的なPDCAを
お試しで入れてみましたが、活用してないのでテンプレートからコードを削除。
Preconnect というおまじない
Adsense、Googleフォント向けに Preconnect を実装
次に気になったものに、
- pagead2.googlesyndication.com , fonts.gstatic.com , googleads.g.doubleclick.net などの Google AdSense 系っぽいURLのもの
- fonts.gstatic.com , fonts.googleapis.com などの Googleフォント 系っぽいもの
があります。この辺のサービス利用を辞めることは考えられないので、諦めようと思いましたが、高速化に役立つ可能性のある Preconnect を実装してみることにしました。
<link rel="preconnect" href="https://pagead2.googlesyndication.com" crossorigin> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> <link rel="preconnect" href="https://fonts.googleapis.com" crossorigin> <link rel="preconnect" href="https://googleads.g.doubleclick.net" crossorigin> <link rel="preconnect" href="https://stats.g.doubleclick.net" crossorigin>
私のブログの場合はスラッシュから始めるように書き換えて追記しています。
楽天モーションウィジェット向けにも Preconnect を実装【失敗】
前述の Philosophy Guides さんのサイトでは、こちらも紹介されていました。
<link rel="preconnect" href="https://static.affiliate.rakuten.co.jp"> <link rel="preconnect" href="https://mtwidget01.affiliate.rakuten.co.jp"> <link rel="preconnect" href="https://log.affiliate.rakuten.co.jp"> <link rel="preconnect" href="https://imp.pt.afl.rakuten.co.jp"> <link rel="preconnect" href="https://thumbnail.image.rakuten.co.jp">
ついでに、モーションウィジェットの JavaScript がレンダリングブロックしているらしかったので、非同期読み込みに。
<script async="async" type="text/javascript" src="http://xml.affiliate.rakuten.co.jp/widget/js/rakuten_widget.js"></script>
ってしたら、表示されなくなりました。。。
楽天モーションウィジェットは、スコアにも結構悪影響を及ぼしているように見えます。
楽天 API を利用した方法があるとかないとかいう噂があるので、後日試してみたいと思います。
Google の日本語フォント Noto Sans は JP / Japanese の2種類あるみたい!
現在 Noto Sans Japanese を使っているのですが、Noto Sans JP の方が、ウェイトが1種類少ないということで、「これは軽いはず!」と思って試してみたけど、CSS は JP の方が軽いですが、トータルで JP の方が重かったです。ウェブフォントとして使う場合に限る話かもしれませんが。
0.1MB の差なので、微々たる物といったらそこまでではありますが、Japanese に戻しました。
残念。
SNSの公式シェア数カウントボタンなどが重い
SNS 関連 JavaScript の非同期化等読み込み調整【失敗】
SNS 関連は軒並み時間が掛かっています。特に Facebook・・・。
JavaScript を非同期化して読み込むことで改善できるようです。
こちらが参考になります。
–>SNSボタンのJavascript非同期通信化などでページ読み込み時間2割削減
で、試してみたのですが、
- Facebook 関連 js の非同期化
は出来たのですが、
- Twitter 関連js の非同期化(カウント数取得に widgetoon.js を利用)
- LINE 関連 js の非同期化
の2つは async=”async” とするとボタン画像が表示されなくなりました。(HTML的には async って書くだけでOK?)
なんだか全然うまくいかなくて、ジリジリします。・・・覚悟して全て jQuery の Ajax でオリジナルボタンにすることにしました。
SNS ボタンをオリジナルのものにして高速化を目指す
参考にさせていただいたのはこちら
–>サイトの高速化に!SNS関連をJavaScriptで非同期に取得する方法まとめ
そのままだと上手くいかなかったので2箇所ほど調整しました。
Twitter のカウント数の取得は株式会社ディジティ・ミニミさんの count.jsoon のものに。
url:'http://jsoon.digitiminimi.com/twitter/count.json?',
Facebook のカウント数取得部分のスクリプトは下記に。
–>【仕様変更】ブログのFacebookシェアボタンのカウント数が取得出来ない – 時期尚早
シェア数が0カウントの時に、表示されないという不具合があったため Facebook のカウント数取得部分のスクリプトは下記に。
Facebookシェアボタンのカウント数が取れない!?対処方法は簡単
//Facebookのシェア数を取得
function get_social_count_facebook(url, selcter) {
jQuery.ajax({
url:'https://graph.facebook.com/',
dataType:'jsonp',
timeout: 10000, //10sec
data:{
id:url
},
success:function(res){
if (res.share !== undefined) {
jQuery( selcter ).text(res.share.share_count);
}
else {
jQuery( selcter ).text('0');
}
},
error:function(){
jQuery( selcter ).text('0');
}
});
}
GTmetrix PageSpeed Score / YSlow Score Page Load Time / Total Page Size |
PageSpeed Insights PC / SP |
|
---|---|---|
作業前 | E / E 5.7s / 6.31MB |
76 / 60 |
PHPver変更 | D / E 5.2s / 6.12MB |
76 / 60 |
W3 Total Cache / プラグイン削除 | D / E 4.9s / 6.00MB |
未計測 |
読み込みファイル調整 / SNS Ajax 等 | D / E 3.7s / 5.63MB |
78 / 61 |
何回か計測してみると、3秒台がたまーに出るようになりましたが、概ね5秒台くらいが多い。全然安定しない。
ブラウザからページにアクセスする分には、表示がスムーズになった(SNSボタンの調整の影響が大きいかな?)気がしなくもありませんが、計測値は全然ですねぇ。広告の影響でしょうかね。
スコアについては上記の対応では全然改善しませんでした。いくつかサービスの利用を辞めればスコアが改善されると思われるものもありますが、一旦ここまでで。
GTMetrix のページスピードスコアで B が出ました。
WordPress ページ表示高速化。CDN に頼らないチューニングで【PageSpeed B 達成】