PageSpeed Insightsを参考にロリポップサーバでWordPressを高速化させるまでの流れ

このページは約16分で読み終わります

後で読む

  • このエントリーをはてなブックマークに追加

こんにちは、
今回はこのWordPressサイトを高速化させた一連の流れをご紹介します。

元の構成はこんな感じ

・サーバー:ロリポップ スタンダードプラン
・CMS:WordPress
・テンプレート:独自
・プラグイン:9個
 - Admin Menu Editor
 - Advanced Custom Fields PRO
 - Duplicate Post
 - EWWW Image Optimizer
 - Google XML Sitemaps
 - SiteGuard WP Plugin
 - TinyMCE Advanced
 - WebSub/PubSubHubbub
 - WP Remove Category Base

無理のない範囲で手軽にできるところのみに絞り高速化をさせてみました。

改善後のスコア

まず最初に改善後のスコアを見ると‥

PageSpeed Insights パソコン 93 / 100

PageSpeed Insights パソコンのスコア

PageSpeed Insights モバイル 83 / 100

PageSpeed Insightsモバイル時のスコア

GTmetrix PageSpeed Score A 96%  YSlow Score D 69%

GTmetrixによるスコア

Chromeのデバッグツールで表示速度を見ると平均700msで表示されています。

Google曰くユーザーがページの表示に待てるのは2秒までとのことで収まり一安心です。(ただサイズがまだ重たいのでそぎ落とせばまだまだ改善の余地はありそうです。)

高速化のためにやったこと

サーバーはレンタルサーバーなので、調整できる範囲としては主にHTML側とCMS側になります。重い腰を上げそれぞれ順番に見ていきましょう。

1. 予めHTML側で速度に配慮する

余談ですがこのサイトのソースコード管理は無償で非公開レポジトリ管理ができるBitbucketを利用しています。Gitがあると遡れるので便利ですね。

Bitbucketの管理画面

WordPressテンプレート化の前にHTMLコーディングをする上でいくつかのことを注意しました。

JavaScriptをフッターに配置する

ブラウザでページのレンダリングを行う際にJSがhead内にあると表示のレンダリングが止まってしまうので、コーディング段階から予めフッターに配置をするようにしています。(後々プラグインでフッターに配置もできますが、強制的にフッター配置、統合等でJSが動かなくなることがあるので、予め行っておきました。)

ウェブフォントのサブセット化

Noto Sans Japanese

このサイトの文字は全てGoogleとAdobeが共同開発したNotoSansを利用しています。そのままでは気が遠くなるほど重たいのでこちらのサイトを参考に、サブセット化を行いました。

@font-face {
	font-family: 'NotoSansCJKjp';
	font-style: normal;
	font-weight: 100;
	src: url('fonts/noto-thin.eot');
	src: local('Noto Sans CJK JP Thin'),
         url('../fonts/noto-thin.eot?#iefix') format('embedded-opentype'),
         url('../fonts/noto-thin.woff') format('woff'),
         url('../fonts/noto-thin.otf') format('opentype');
}

 

のように記述しています。ただ改めて最終的に見てみると今7ウェイトあるのでこんなに要らなかった(削れる)感は否めません。ここも設計が必要ですね。

アイコン系にはFont Awesomeを利用

Font Awesomeのアイコン

個別に画像パーツ作るのも微妙&CSSスプライトも手間になるので、サイト内のパーツでは定番のアイコンフォント(Font Awesome)を利用しました。ただ数が多すぎて探すのが億劫なのでこちらのサイトからよく使われるアイコンを探しました。

SNSボタンの非同期化

サイトの表示が体感的に遅くなる原因の1つにSNSボタンの設置が挙げられます。このサイトではページのロード時に他の処理の妨げにならないようFacebook、Twitterボタンの非同期化をしています。非同期化といっても既存のコードに「js.async = true;」を足すだけで完了です。

以下は非同期化後のコードサンプルです。

// Twitter Button JS
!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.async=true;js.src=p+'://platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,fjs);}}(document, 'script', 'twitter-wjs');

// Facebook Button JS
(function(d, s, id) {
var js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) return;
js = d.createElement(s); js.id = id;js.async = true;
js.src = "//connect.facebook.net/ja_JP/sdk.js#xfbml=1&version=v2.5;
fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));

 

画像を圧縮しておく

TinyPNGの画面

画像は普通にiPhone等で撮影したものであっても、取得した画像などはMB単位で重たいですよね。画像を圧縮といっても劣化するのは避けたいのでロスレス圧縮が好ましいですが、これにはTinyPNGがとても手軽です。軽量化できる場合は90%ぐらい軽減できますのでベースの画像ファイル全てで実施しておきます。(2回実施すると劣化するので避けましょう)

HTMLのタイミングではまとめると以下のようなソースコードとなりました。

<!DOCTYPE html>
<html lang="ja">
<head prefix="og: http://ogp.me/ns# article: http://ogp.me/ns/article#">
<meta charset="UTF-8">
<title>ahalog TOP</title>
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="robots" content="noindex,nofollow">
<meta name="keywords" content="">
<meta name="description" content="">
<meta property="fb:app_id" content="xxxxxxxxxxxxxxxx">
<meta property="og:type" content="article">
<meta property="og:url" content="">
<meta property="og:title" content="">
<meta property="og:image" content="">
<meta property="og:description" content="">
<link rel="stylesheet" href="css/style.css">
<link rel="stylesheet" href="css/fonts.css">
<link rel="stylesheet" href="css/font-awesome.min.css">
<link rel="stylesheet" href="css/hopscotch.css">
<link rel="shortcut icon" href="favicon.ico" type="image/vnd.microsoft.icon">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="apple-touch-icon" sizes="57x57" href="/apple-touch-icon-57x57.png">
<link rel="apple-touch-icon" sizes="72x72" href="/apple-touch-icon-72x72.png">
<link rel="apple-touch-icon" sizes="76x76" href="/apple-touch-icon-76x76.png">
<link rel="apple-touch-icon" sizes="114x114" href="/apple-touch-icon-114x114.png">
<link rel="apple-touch-icon" sizes="120x120" href="/apple-touch-icon-120x120.png">
<link rel="apple-touch-icon" sizes="144x144" href="/apple-touch-icon-144x144.png">
<link rel="apple-touch-icon" sizes="152x152" href="/apple-touch-icon-152x152.png">
<!--[if lt IE 9]>
<script src="//cdn.jsdelivr.net/html5shiv/3.7.2/html5shiv.min.js"></script>
<script src="//cdnjs.cloudflare.com/ajax/libs/respond.js/1.4.2/respond.min.js"></script>
<![endif]-->
</head>
<body>
<div>
~省略~
</div>

<!-- JS - hatena bookmark Button-->
<script src="https://b.st-hatena.com/js/bookmark_button.js" charset="utf-8" async="async"></script>
<!-- JS - Facebook Button-->
<div id="fb-root"></div>
<script src="js/sns.js"></script>
<script src="js/jquery-1.12.3.min.js"></script>
<script src="js/library.js"></script>
<script src="js/common.js"></script>
</body>
</html>

2. WPテンプレートのチューニング

画像ではサムネイルを利用

ahalog内の回遊動線のサムネイル

縮小表示をすると本来不要なサイズの画像を読み込むことになるのでWordPress側でトリミング処理を実施しました。このサイトではAdvanced Custom Fieldsをベースにしているので、以下のような感じで指定しています。

 if ( $nextpost ) { //次の記事が存在しているとき
  echo '<a href="' . get_permalink($nextpost->ID) . '">  
        <figure>
   			  <p>' . wp_get_attachment_image( $next_thumb, $next_size ) . '</p>
		</figure>
		<div>
        ' . get_the_post_thumbnail($nextpost->ID, array(100,100)) . '
        <p><time datetime="'. get_the_date("Y-n-j",$nextpost->ID).'">'. get_the_date("Y.n.j",$nextpost->ID).'</time></p>
        <p>' . get_the_title($nextpost->ID) . '</p>
        </div></a>';
 }

PageSpeed Insightsで速度をチェック

ここまででどれぐらいの速度か恐る恐るチェックしてみます。

PageSpeed Insights パソコン 70 / 100

PageSpeed Insightの途中スコア

PageSpeed Insights モバイル 60 / 100

PageSpeed Insightモバイルの途中スコア

GTmetrix PageSpeed Score A 76%  YSlow Score D 64%

GTmetrixの途中スコア

一見そこまでは悪くなさそう‥! ただ、

Chromeのデバッグツールで表示速度を見ると平均3.95sと4秒も表示にかかっていました。これだと正直表示にはキツい印象を受けます。

3. WordPressでキャッシュを導入

WP Fastest Cacheキャッシュの利用

いよいよキャッシュの導入をしてみます。WordPressは動的CMSなので、都度データベースにアクセスし情報を取得するにはタイムラグが生まれてしまいます。案件の性質上可能な場合はやはりキャッシュの導入はしておきたいところです。

このサイトはマルチサイトではないので、WP Fastest Cacheの利用ができます。(マルチサイトでは非対応)

他にもキャッシュ系のプラグインがありますが、最も手軽に導入ができON/OFFも手軽にできることから比較的1択で普段選んでいます。

WordPressプラグインディレクトリ内のWP Fastest Cacheプラグイン

WP Fastest Cacheには無償版、有償版があり、以下が無償版の場合の設定画面です。

WP Fastest Cacheの設定画面

これだけでもキャッシュが生成され早くなり、

・PageSpeed Insights パソコン 86 / 100
・PageSpeed Insights モバイル 63 / 100
・GTMetrix PageSpeedScore 86% / YSlow 65%
・Chromeの検証ツールでは読み込み完了までに1.02sとなりました。

Premium版を有効化してみます。

・PageSpeed Insights パソコン 92 / 100
・PageSpeed Insights モバイル 81 / 100
・GTMetrix PageSpeedScore 88% / YSlow 66%
・Chromeの検証ツールでは読み込み完了までに920msとなりました。

あまり表示速度は変わりませんでしたが‥、PageSpeed Insightsには若干の効果が見られました。

画像の遅延表示をさせる

画像を全て読み込みと時間を無駄にしてしまうので、表示されていない画像は読み込みされないようにします。このサイトではLazy Loadプラグインを入れています。

Jetpackを利用する

WordPressプラグインディレクトリ内のJetpackプラグイン

続いてJetpackを利用して、画像をCDN化します。Jetpackは複合機能がありますが、その中の1つ「Photon」を利用することで、サイト内の画像を全てCDNから参照することができるようになります。

画像のパスは

https://i2.wp.com/ahalog.tdesignworks.net/wp-content/uploads/google.com_.png?resize=240%2C140

のように「i2.wp.com」というWPサーバからの配信に切り替わります。

詳細については以下に公式ドキュメントがあります。

https://jetpack.com/support/photon/

ただこの環境においては速度には特に改善が見られませんでした。

4.サーバの調節をする

レンタルサーバーなので調節にも限界がありますが、実は少しチューニングできる余地があります。PHPのバージョン変更が行えます。

ユーザー専用ページにログイン後、サーバーの管理・設定 > PHP設定に移動。

以下ロリポップより表を拝借していますが、CGI版よりモジュール版の方が高速に動作をします。

ロリポップのPHPの仕様

そこで5.6 (CGI版) → 5.6 (モジュール版)に変更をしました。これにより200msぐらい表示速度を高速化できています。

Before Afterを比べてみる

・PageSpeed Insights パソコン 70 / 100 → 93 / 100
・PageSpeed Insights モバイル 60 / 100  → 83 / 100
・GTMetrix PageSpeedScore 76% → 96% / YSlow 64% → 69%
・Chromeの検証ツールでは読み込み完了までに3.95s → 700ms

となりました。

ネットの接続環境であったり、計測タイミングによって数値に差が出るので一概に正しいスコアといえない側面もありますが、ロリポップのレンタルサーバーでもある程度の評価や速度を得られる結果となりました。

主に表示速度に大きく影響を与えたのはキャッシュプラグイン「WP Fastest Cache」でスコアを改善させたのは地道な作業の積み重ねですが、有償の「WP Fastest Cache Premium」を利用するとPageSpeed Insightsにも改善が見られました。

現状のボトルネック

スコアを下げている要因はPageSpeed Insightsを見るとわかりやすいですが、SNSボタンによる外部JS、及びGoogle Analyticsタグ、Yahoo!アクセス解析タグがそれぞれ

✕ JavaScriptを圧縮する(Facebook / Twitter / GAタグ / Yahoo!タグ / はてな)
✕ ブラウザのキャッシュを利用する(Pocket / はてな)
✕ 圧縮を有効にする(Pocket)

という結果となっています。ただいずれも利用はしたいサービスではあるので、ここを削ればスコアはより上昇しますが諦めるポイントとなっています。

PageSpeed Insightsのスコア面で改善の余地というところでいえば、必要なCSSをインラインで読み込ませるぐらいになりそうです。他には表示速度ではNotoSansフォントがやはり重たいのでここを試しに削ると600ms程度となりました。

表面上の話ではデザインをとるか、機能を取るか‥であったり、そもそもJQueryは重たいので利用しないなど悩ましいですが、チューニングにはやり甲斐がありそうです。

また英語では「Above the fold」日本語ではファーストビューなどと言ったりしますが、ニールセン調べでは「訪問者の77%はページをスクロールしない」とも言われておりファーストビューに如何に注力するかといった視点も大事になりそうです。

少しでも参考になるところがあれば幸いです。

最後までお読み頂きありがとうございます!

  • このエントリーをはてなブックマークに追加
bitFlyer ビットコインを始めるなら安心・安全な取引所で