フレームワークを使ってWordPressサイトをリニューアルしたら表示速度が速くなった話

当サイトをリニューアルしました。
ニュース記事にて少し記載したのですが、今回のリニューアルでは今までの制作アプローチとは異なり、勉強も兼ねて各種フレームワークを利用することでどのような制作フローの変化があるか、その結果どのようなメリット・デメリットがあるか確認するためでしたが、副産物として表示速度が以前より速くなった結果になりましたのでご紹介します。

1 リニューアルにおける前提条件
2 なんでGenesisを採用したのか？
- 2.1 WordPressのフックを使った構築とカスタマイズ
- 2.2 基本設定でSEO設定を細かく設定でき、データ構造に沿った記述
3 Foundationというレスポンシブウェブデザイン時代に欠かせないフレームワーク
4 リニューアル前後の表示速度の比較
5 体感速度はどうか？
- 5.1 Lightspeedへ変更して専用のキャッシュが利用できる
6 利用プラグイン一覧
7 まとめ

リニューアルにおける前提条件

以前のリニューアルがいつだったかとニュースを確認していたところ、2013年8月にプチリニューアルをしたという記事がありました。数年程度かなと思っていましたが、まさか約5年も経過しているとは・・・その間に技術は進化しているはずですね。

今回のリニューアルにおける前提条件です。

WordPressはリニューアル前後も最新版を利用
オリジナルテーマ開発からテーマフレームワークであるGenesisを採用
- SEOは独自開発のSEO設定を利用していたが、GenesisのSEO設定機能を利用
フロントエンドフレームワークとしてFoundationを採用
- モバイルファーストでのコーディングを最優先（ちなみにPCからのアクセスのほうが圧倒的に多いです）
サーバーをさくらインターネットからmixhostへ移転
- メールサーバーは変わらずさくらサーバーのまま
CSSはSassを採用
PHP 5.6から7.0へ変更
サーバーはApacheからLightspeedへ変更（サーバーの仕様）

今回は、上記に記載のあるWordPressのテーマフレームワークの「Genesis」と、フロントエンドフレームワークであるFoundationに焦点を当てます。

なんでGenesisを採用したのか？

今まではサイトの全体像であるワイヤーフレームを作って、その後デザインに落としていき、デザイン確定後にHTMLコーディングをした後にWordPressテーマに落とし込む、というフローでサイト制作をしていました。

しかし、各種デバイスへの細かい対応、WordPressの各テンプレート表示や記事作成時に付与されるHTMLやCSSへの対応、どんどんとアップデートされるSEOへの対応、WordPressを利用する上で常に付いて回るセキュリティ対策への対応など、とても追いついていける状態ではないことは前々から薄々感じており、どうにかしていい方法はないか？と考えていました。

確か2018年明けてすぐの頃だったと思います。WordPressのCodexにテーマフレームワーク – WordPress Codex 日本語版というページがあり、そこを眺めていると「ベース/スターターテーマ」というところに「Genesis Framework」という有償のフレームワークというのを目にしました。

最初、「単なる有料のテーマなんだろう」と思っていましたが、ウェブ上の記事を見ているとそうではないことはすぐにわかりました。

公式サイトの機能紹介にもある通り、SEOを意識した構築や、モバイルファーストを前提としたページ表示速度、そして何より、親テーマにGenesisを使って骨組みをしっかりとした上で、デザインは子テーマで基本的にフックを使って構築する、という設計思想に感銘を受けました。

これはクライアントワークにも必ずフィードバックできると思い、迷わず購入、まず第一弾として当サイトのリニューアルに取り掛かりました。

WordPressのフックを使った構築とカスタマイズ

基本的に、テーマファイルにコードは書いていかず、WordPressとGenesisが用意しているアクションフックやフィルターフックを使ってカスタマイズしています。この設計には痺れました。

通常、WordPressのテーマ開発には必須となるテンプレートファイルを始めとして、テンプレートファイル内にHTMLやphpを書いていくという手法を取ることが多いと思います。しかし、Genesisではフックを利用してカスタマイズされることを前提として設計されているため、テーマ内にテンプレートファイルがあまり増えません。WordPressデベロッパーならわかると思いますが、ヘッダー領域用のheader.phpやフッター領域のfooter.php、また必須テンプレートファイルであるindex.phpでさえ子テーマには含まれず、必要なカスタマイズは基本的にフックで行っています。

そのため、新たに作成したWPテンプレートファイルは5,6程度のみです。

また驚いたのが、親テーマで参照しているindex.phpには

genesis();

の1行のみしか記載されていません。これも上記同様、フックをベースに設計されている思想のためです。

日本語の情報もまだあまりないため手探りで最初は戸惑いましたが、なれてくるとフックをベースに開発する楽しさと効率の良さが理解できました。

基本設定でSEO設定を細かく設定でき、データ構造に沿った記述

まだリニューアル後の流入は測定できていないため要確認ですが、SEO設計のアドバンテージという点も大きかったです。

上記参考ブログ等でも紹介されていますが、GenesisはSEO設計が考えられたテーマです。例えばSchema.org に準拠したHTML構造化データにて記述されている点や、SEOのプロフェッショナルによってサポートされている点、デフォルトでSEO設定を細かく設定できる点など。

このようにGenesisを利用すると各ページのSEO設定をプラグイン利用せずに設定できるようになる

また、今後のアップデートはサポート内のため、例えば今後SEOの評価が変わったからHTMLを書き直さないといけないといったことがあった場合でも、Genesisを利用しているかぎり、SEOの専門家による最新の構造化データを常に利用できる点も非常に魅力です。

このように、Genesisテーマフレームワークはただの単なるデザインテーマではなく、強力な基礎をであり、しっかりとした土台をベースに組んだ上に、デザインを子テーマとして適用していくという、理にかなったWordPressテーマの構築方法だと感じます。

Foundationというレスポンシブウェブデザイン時代に欠かせないフレームワーク

「なんて古いワークフローだ！」とお叱りを受けてしまいそうな気もしますが、オリジナルデザインでの開発が多かったため、ある程度スニペットは用意していたとしても基本的にはHTML, CSS, JavaScriptを毎回一からコーディングしているフローでした。そのため都度時間がかかるのと、デバイスでの再現性の確認が大変で、何かしら穴がありその都度修正をしていて、非常に時間と手間がかかっていました。

以前、Twitter Bootstrapが確かまだVer2の時代に一度フレームワークを使っていましたが、どうしても「あ、このサイトBootstrapで作ったよね」というのが出てしまうのが受け入れられず、それ以来フレームワークを避けて通っていました。まだ当時はフレームワークから抜け出したコーディングができていなかったんだと思います。

また、ここ数年はコーディングをするよりもディレクションをすることのほうが多く、実践現場の技術からも疎くなってしまっていました。

「いい加減このままではまずい！」と思い、2017年後半くらいにようやくフレームワークを勉強しなおしました。

まずは敷居の低いUIKitからスタート

フレームワークの選定ですが、いろいろと調べていると以下の3つの選択肢に絞れました。

Bootstrap Ver4
Foundation Ver6
UIKit Ver3

Bootstrapは昔の記憶が強く残っていたため、残るFoundationとUIKitでしたが、簡単に始めれそうな敷居の低いUIKitを選択しました。FoundationはSassでのインストールが選択できますが、まだその頃はCSSでのコーディングがメインでSassを使いこなせていなかったためというのもありました。

UIKitを使ってみて感動したのは、ほぼHTMLだけでサイトの全体ができ、あとの装飾をCSSで付け足すという効率の良い構築方法でした。

実際にクライアントワークにも落とし込み開発工数を落としつつ、レスポンシブデザインでの制作効率を上げることにも繋がり、設計者のことが考えられた非常に優れたフレームワークです。

基本が押さえられたところでFoundationへ

ある程度UIKitが理解できたため、次にFoundationを使いはじめました。

UIKitもそうですが、英語圏での開発のため基本的にはドキュメントがすべて英語です。日本語の情報もありますが、本家の情報にはかないません。英語は得意ではないですが、なんとかしてドキュメントやstack overflow等を参照しつつ、ローカル環境でのインストールや初期設定を行いました。

WordPressテーマでFoundationを使う

当たり前ですが、WordPressは構成するphpやcss, js等のファイルをテーマファイルとして用意・設定しないといけません。最初、GenesisテーマにFoundationをどう落とし込めばいいかが全然わからず、テーマとして利用するのにに苦労しました。

SassではなくCSSとしてのスタートすることも頭をよぎりましたが、それでは開発効率も落ち今回のフレームワークを用いている意味がないため、ウェブの情報を参考にしながらなんとかSassバージョンにてテーマ環境を構築しました。

Sassは今ではなくてはならない記法となりました。なんで今まで使ってこなかったのか・・・

Foundationのインストールに加え、CLIツールもインストールしました。gulpが立ち上がると、Sassを保存するタイミングで自動でコンパイルしてくれる環境も構築でき、開発効率が上がりました。初期設定は必要ですが、一度やってしまえばFoundation側でよしなにやってくれるのでそこまで難しくはありませんでした。

gulp監視をFoundationで実行すると監視がスタートし、scssファイルを保存のタイミングでsassファイルをコンパイルしてくれ、cssファイルを自動で生成してくれる

Genesisテーマに合わせてスマホの各breakpointの設定やベーシックのフォントサイズ、フォントファミリー等の設定も細かく設定できます。もちろん強力なFoundationの機能を使いつつ、Foundation側でのカスタマイズも反映されます。結果、Foundationを利用したWordPress子テーマが出来上がりました。

Foundationで生成しているCSSと合わせると130KB程度の大きさとなりましたが、以前はie7用のCSSだけで200KB以上もあり、合計で300KB近いCSSファイルだったため、結果的には大きく縮小させることができました。CSSのminifiedもGulp側で自動的にビルドしてくれます。

今回採用のGenesisテーマに限らず、その他WordPressテーマやオリジナルテーマでもFoundationを利用するメリットは非常に大きいと感じました。

もちろんその他のフレームワークであるBootstrapやUIKitも十分メリットを享受できると思います。

リニューアル前後の表示速度の比較

前置きがかなり長くなってしまいましたが、表示速度の比較表です。ビフォーのデータはありませんが、信憑性比較のためPingdomのデータも記載します。

利用測定ツール	対象ページ/デバイス	項目名	リニューアル前スコア	リニューアル後スコア	比較数値
GTmetrix	トップページ	ページスピード	C判定 77%	B判定 85%	1.17倍アップ
		YSlowスコア	D判定 68%	C判定 78%	1.14倍アップ
		ロードタイム	4.7秒	3.7秒	1秒改善
		ページサイズ	711KB	527KB	1.34倍ダウン
		リクエスト数	50	36	1.38倍ダウン
	ブログページ	ページスピード	D判定 64%	B判定 88%	1.37倍アップ
		YSlowスコア	E判定 56%	C判定 79%	1.41倍アップ
		ロードタイム	6.8秒	2.3秒	4.5秒改善
		ページサイズ	1.3MB	245KB	5.3倍ダウン
		リクエスト数	84	31	2.7倍ダウン
PageSeed Insights	トップページ – モバイル	最適化(100点満点中)	Low 36点	Medium 71点	35点アップ
PageSeed Insights	トップページ – パソコン	最適化(100点満点中)	Medium 67点	Medium 78点	11点アップ
Pingdom Website Speed Test	トップページ	グレード	–	B判定 80点	–
		ロードタイム	–	2.63秒	–
		その他サイトとの比較	–	58%早い	–
		ページサイズ	–	661KB	–
		リクエスト数	–	42	–

上記表をみていただければおわかりかと思いますが、すべての項目において改善が見られました。トップページで1秒、ブログ一覧ページにおいては4.5秒も早くなりました。（以前どんだけ遅かったんだ…）なお、リニューアル前のトップページはWordPressページではなく、htmlページとなります。ということは、HTMLページよりもCMSであるWordPressページの方が表示速度が早くなったということになります。

また、モバイル表示においての採点も35点アップと大幅に上昇しています。

以下、データ元となるリニューアル前後の各画像です。（クリックで拡大）

リニューアル前

リニューアル後

2018/06/12追記：アナリティクスでも比較してみたがやっぱりすごい

リニューアル前後のとある1週間を抜き出し、アナリティクスでも比較。

Googleアナリティクスで比較した図。特に読み込み時間、サーバー応答時間、ダウンロード時間が大きく改善！

画像をみてもらって分かる通り、読み込み時間は平均5秒以上、サーバー応答時間は3秒以上、ページダウンロード時間は約2分の1と、大きく改善されました。

また、オレンジの色のグラフを見ると以前は日によって大きくムラがあったが、サーバー移転後は安定しているのがわかります。

体感速度はどうか？

実際触ってみて感じたのは、管理画面も含めてサイト全体の速度は肌感覚でも大きく改善されました。以前はページ表示に少し時間がかかっていましたが、今はほぼ待つことなく表示されます。

また、管理画面もサクサク使えることによって、画像アップロードやプラグイン等の更新作業、記事作成も快適になりました。

これはphp5.6から7.0へアップデートしたのが大きいと思います。この部分は以前のさくらサーバーでも7.0に変更すれば大きく改善できたと思います。ただ、さくらサーバーの場合はphpのバージョンを変更すると全ドメインに影響します。ドメインごとに別々のPHPのバージョンを適用させるには、.htaccessファイルを直接編集する必要があります。今回は管理している他のドメインがあったというのと、メールサーバーとウェブサーバーを別々にしたかったというのもあったためmixhostを利用することにしました。

Lightspeedへ変更して専用のキャッシュが利用できる

サーバーがApacheからLightspeedに変更となりました。これにより、WordPressプラグインで提供されているLiteSpeed Cacheプラグインが利用でき、キャッシュ利用による速度向上が見込めます。

また、mixhostではドメイン認証型の無料SSLであるLet’s Encryptが利用できるためSSL利用料金が抑えれます。SSL対応することでhttp/2が利用できページ表示速度に影響します。今後リニューアルの際には必ずSSL対応されることをおすすめします。Googleもhttpsに対応していないサイトは警告するようになると明記しています。

Chrome 68 では、すべての HTTP ページのオムニボックスに「保護されていません」と表示されます。
参照：Google ウェブマスター向け公式ブログ: 保護されたウェブの普及を目指して

ある程度の規模の会社であればSSLのブランドは注意すべきかと思いますが、個人や小さい組織であればLet’s Encrypt等の無料SSLで十分でしょう。

利用プラグイン一覧

今回リニューアルにあたって、記事公開時にて利用中のプラグインを明記します。

Advanced Custom Fields PRO
Custom Post Type UI
Google Authenticator
Google XML Sitemaps
LiteSpeed Cache
MW WP Form
Table of Contents Plus
WP Mail SMTP
WP Multibyte Patch

全部で9つでした。なんでもかんでもプラグインで実現させるのは個人的にあまりしたくなくて、なるべく必要のない機能はいれないというのと、できるならばWordPressのテーマに記載するか独自プラグインとして導入するという信条です。以前はなんでもかんでもfunction.phpに記載していたときもあったのですが、それだとテーマを変えるとサイトとして成り立たなくなる等の不具合もあり、いろいろな方の方法を参考にさせていただきながら、現在はテーマに記載する機能とプラグインで導入する機能を分けるようになりました。例えばカスタム投稿タイプの作成なんかは以前記述していましたが、現在はプラグインで対応している等ですね。

まとめ

GenesisフレームワークとFoundationフレームワーク採用によるリニューアルによって、どの程度ページ速度が改善されたかのまとめでした。

もちろんフレームワークだけでなく、PHPのバージョンやサーバーのスペック、同居している他ユーザーの影響等もあるかもしれません。

ページ速度が改善できたことは嬉しかったですが、通常業務の合間のため、なかなか作業がとれず半年以上かかってしまいましたが、なんとかリニューアルができたことがそれ以上に嬉しかったです。

時代や技術に合わせてチューニングしていかないとと痛烈に感じたのと同時に、今までのワークフローを根底から考えさせられる、実りあるリニューアルとなりました。