WordPressの高速表示対策は、SEOを実施するために欠かせないことは、前回の記事でお伝えした通り検証することでわかってきました。

そこで、今回は、簡単に実施できるWordPressの高速表示対策をミスなく実装するために、都合30回ほどの検証を行いました。

検証に用いたページは、前回調査した8ページの中から、優秀なパフォーマンスを発揮した2ページとトップページの3ページと、もっともパフォーマンスの悪かった2ページの合計5ページで行いました。

検証項目
  1. 検証した項目は、サーバーの対応phpバージョンの違いで、WordPressの高速化パフォーマンスは異なるのか。
  2. エックスサーバーが提供しているサイトの表示速度を向上させる「mod_pagespeed」で、パフォーマンスは、どれだけ改善されるのか。
  3. 本サイトで採用しているWP高速表示系プラグイン「WP Fastest Cache」で、高速化対策はどれだけパフォーマンスを向上させるのか。
    「WP Fastest Cache」は、無料バージョンで、選択可能なチェックボックス全てを有効にし検証しました。
  4. 「mod_pagespeed」の有効化と「WP Fastest Cache」を有効にする順番が異なれば、パフォーマンスは変化するのか。
以上4項目を、「GTmetrix」およびGoogleの「PageSpeed Insights」を用いて検証しました。

WordPress高速表示対策を実施する際の注意事項

今回、WordPressの高速表示対策を検証するに際して、予めお断り申し上げておきたいことがあります。

ひとつは、私はプログラマーでもシステムエンジニアでもないということです。私は、プログラムに関して専門的な教育を受けた経験は一切ありません。

何が言いたいのかといえば、プログラムの専門家でなくても、インターネットを使い、信頼のおける検証ツールを使い、そして、Googleのツールを使った検証結果と比較することで、適切なプログラムを見つけることができ、アプリやツール、プラグインを採用することができるということです。

もちろん、WordPressの高速表示対策や表示速度に関するGoogleのコンテンツ評価は、WordPressのテーマやプラグインの選択、そして組み合わせ、そして、ウェブサイトに掲載するコンテンツの内容やサーバー性能によって大きく変わります。

プログラムの専門家なら、ホームページの運営方針や掲載コンテンツの内容によって、最適なWordPressサイトを開発することはできるでしょう。

いわゆる「オリジナルテーマの開発」(WordPressはテンプレートのことを「テーマ」と、呼びます)を行い、最良のパフォーマンスを得ることは可能だということです。

しかし、WordPressのオリジナルテーマは、現実的ではありません。

その理由は、WordPressのシステム自体が常にバージョンアップを行なっているため、この「WPテーマ」のバージョンアップも常に追随するようにバージョンアップし続けなければ、表示崩れをはじめとする、不具合を発生させてしまうからです。

このリスクを回避するためには、常にオリジナルテーマのバージョンアップを自社で行うか、制作会社、開発会社のサポートのもと実施し続ける必要が出てきます。結果としてコスト高を招くわけです。

このWordPressとテーマのバージョンアップ問題、そして、そこに関わってくるコスト問題を解決する最良の方法として、私たちは、市販のWordPressテーマを採用することをお勧めしています。

無料のWPテーマで優秀なものもたくさんありますが、「継続的なバージョンアップ」という意味では、不安が残ります。

そこで、比較的安価で購入でき、WPテーマのバージョンアップ頻度とバージョンアップ履歴、サポート実績などを総合的に調査し、WPテーマを選ぶようにしています。

このような過程を経ることで、プログラム的な専門知識を持っていなくても、コストをかけ、最良のパフォーマンスを発揮するウェブサイトを開発しなくても、ユーザーに好まれ、Googleからも高い評価を得られるウェブサイトを手にすることができます。

本記事は、実際にそれらの検証に、あなたの手を煩わせずに済むよう参考になればと思い公開しています。

ご質問などは、メールマガジン読者限定となりますので、本ページにも掲載しているメルマガ登録フォームよりご登録ください。

メルマガの配信は、毎週木曜日の夕方と月曜日の早朝の2回です。

Googleの「PageSpeed Insights」は、複数回チェックすべし

今回、いくつかの条件を検証するためのチェックツールとしてGTmetrixとGoogleの「PageSpeed Insights」を使いましたが、Googleの「PageSpeed Insights」は、分析するたびに評価が頻繁に変わる場合があります。ある程度分析を繰り返すと落ち着くことがありますが、この現象が、コンテンツを格納しているサーバーによる影響なのか、それとも「PageSpeed Insights」の仕様なのかは、定かではありません(おそらく、前者だと思われる)。

Googleの「PageSpeed Insights」は、コンテンツのパフォーマンスを「Low(〜64)」「Medium(65〜79)」「Good(80以上)」で評価されます。ただし、検証を行う中で、分析ボタンをクリックするタイミングによって最大38ポイントの差が生じることを今回の検証で確認できました。

この分析ボタンをクリックするタイミングでポイントが大幅に変動する原因の多くは「サーバーの応答時間」であることが多く、このサーバーの応答時間改善は、サーバー会社でなければ実施できません。

この辺りは、優秀なホームページ制作会社やウェブサイトプログラム開発会社でも手出しができない領域だとも言えるでしょう。

そこで、私がエックスサーバーを気に入っている理由が、この「サーバー側で手出しができない領域」を改善するためのツールを、わかりやすい説明文とともに、使えるようにしてくれている点です。

そのひとつが、今回の検証でも取り上げている「mod_pagespeed」です。以下、エックスサーバー内にあった解説文を引用します。

「mod_pagespeed」とは

Google社により開発された拡張モジュール「mod_pagespeed」を使用して、Webサイトの表示速度を向上させる機能です。「mod_pagespeed設定」を有効にすると、ファイルを圧縮してデータ転送量を削減する、同種のファイルを一まとめにして無駄な通信を削減するなどの最適化処理を実施します。この最適化処理により、Webサイトにアクセスしたブラウザはデータ転送量が減少し、また、ページのロード時間を短縮できるため、Webサイトの表示速度改善を期待することができます。

(参照元:https://www.xserver.ne.jp/manual/man_server_mod_pagespeed.php

WP高速化施策は、条件によって異なるので注意が必要

繰り返しになりますが、WordPressの表示高速化対策は、下記の条件によってパフォーマンス改善の是非が異なりますので、注意が必要です。

  1. WordPressのテーマ
  2. 有効にしているプラグイン
  3. レンタルサーバーの性質

WPテーマによっては、今回本サイトで採用している「WP Fastest Cache」無料版で選択できる項目をすべて有効にした場合、表示に不具合が出たり、スクロールが出来ないなどの、表示速度の改善よりも致命的な不具合を起こしてしまう場合があります。

この「WP Fastest Cache」は、俗に「キャッシュ系プラグイン」と言うのですが、この「キャッシュ系プラグイン」には、「wp super cache」や「W3 Total Cache」などがあります。

ともに、「WP Fastest Cache」無料版よりも多機能なキャッシュ系プラグインではありますが、キャッシュ系プログラムに関して詳しくない人は、手を出さないことをお勧めします。

サイトが適切に表示されなくなりますので、注意してください。

「WP Fastest Cache」に関してもWPテーマや設定によっては、コンテンツの表示に不具合を起こしますが、チェックボックスのオンとオフを切り替えるだけで、簡単に元に戻せるので、取り扱いやすいプラグインだと思います。

あなたのサイトに最適な組み合わせを見つけやすいプラグインではないでしょうか。

WordPress表示高速化対策における注意事項まとめ

  • パフォーマンスの改善をチェックする際は、1つのページを検証する際でも、複数回実施し、分析結果の違いを確認する。
  • サイトの表示速度を改善する目的を明確にし、無駄な時間やコストをかけないように注意する。
    サイトの表示高速化は、ユーザビリティを向上させるもので、ユーザビリティの向上の結果、検索ランキングにおいて高評価を得られる可能性を引き上げるだけです。
  • ページを表示させるのに、10秒以上必要な場合は、表示速度の改善は必須だと言えますが、0.1秒の差にこだわったり、Google「PageSpeed Insights」で、100点を取ることに固執する必要はないと考えています。

この理由などは、本サイトでもご紹介している、「サイトの運営目的」や「サイトの運営方針」に沿った施策を選択するように心がけてください。

WordPress表示高速化の検証結果と検証方法

今回の調査結果では、エックスサーバーの表示速度改善ツール「mod_pagespeed」のみを設定した場合を除き、「WP Fastest Cache」のみ、「mod_pagespeed」と「WP Fastest Cache」の両方を設定した場合、また、設定する順番を入れ替えた場合で、顕著な違いを見つけることはできませんでした。

下記に、今回、それぞれの条件で繰り返し調査した結果の内、平均的なパフォーマンス結果を列挙していますが、本サイトでは、わずか数ポイント差ではありますが、繰り返し分析するなかで、好パフォーマンスを発揮するのは、次の設定手順という結論に行き着きました。

 エックスサーバーを使っている場合は、phpのバージョンを推奨される最新版にアップデートし「mod_pagespeed」を設定したのちに、WordPressのプラグイン「WP Fastest Cache」を有効するのが、もっとも最良なパフォーマンスを発揮する。

ただ、最終的に少しおマヌケなことも発見することができました。

今回は、いくつかの表示速度を改善する仕組みを使う中で、その設定順序がパフォーマンスに影響を与えるか!ということも検証したのですが、エックスサーバーの「mod_pagespeed」の設定手順に関しては、「WP Fastest Cache」のキャッシュ情報が更新されるとき、そして、新たなコンテンツを追加した場合は常に「mod_pagespeedを設定したのちに…」という状況になります。

この結果、「mod_pagespeed」を「WP Fastest Cache」を有効化したのちに、有効にするという状況は、現実的に生まれないということです。

仮に、「WP Fastest Cache」を有効化したのちに「mod_pagespeed」を有効化した場合に、圧倒的な高パフォーマンスを発揮したとしても、キャッシュの更新タイミングやブログ記事を書き足したタイミングに合わせて、毎回設定のやり直しをしなければ、この状態を維持できないというわけです。

結果、今回の検証は「WP Fastest Cache」などのキャッシュ系プラグインを使い、「mod_pagespeed」を有効にするか否か。もしくは、「mod_pagespeed」を使い「WP Fastest Cache」などのキャッシュ系プラグインを使うか否かだけの検証で良かったというわけで、「設定の手順」に関する調査は必要なかったというわけです。

システム系の専門家なら、こんなことはあらかじめ分かっていることだったかもしれませんね(汗)

WordPress表示高速化検証手順

検証ツール

  1. Google「PageSpeed Insights」
  2. GTmetrix

検証ページと選択理由

検証ページは、前回の記事で調査したページの中から、パフォーマンスの高かった記事2つに、トップページを加えた3ページと、パフォーマンスの悪かった2ページを加えた、合計5ページで検証。

検証手順

  1. サーバーphpバージョン5および7にて、「mod_pagespeed」およびプラグイン「WP Fastest Cache」を無効化し上記2つのツールを使用し、5ページを検証。
  2. 次に、php5、およびphp7にて、「mod_pagespeed」のみを有効にした場合、プラグイン「WP Fastest Cache」のみを有効にした場合で分析。
  3. 第3の手順として、「mod_pagespeed」をまずは有効化し、浸透時間を確保したのちに「WP Fastest Cache」を有効化し浸透時間を確保し分析。次に、それぞれの機能を無効化し時間をおいて、逆の手順(「WP Fastest Cache」の浸透後に「mod_pagespeed」)で、有効化した状態で分析。

検証内容は、都合10種となりますが、それぞれ2回以上同様の条件で分析を行いました。その理由は、分析のタイミングによって、どう条件のもと分析した場合でも、異なる分析結果が出たため、2回以上、同一条件のもと同一分析結果が出るまで繰り返し検証を行いました。

検証結果

php5:高速化ツール使用なし

php5:表示時間短縮ツール未使用

php5:表示時間短縮ツール未使用:GTmetrix

php5:表示時間短縮ツール未使用:GTmetrix:基本デザインページ

php5:表示速度短縮ツールなし:ポイント概要

php7:高速化ツール使用なし

php7:表示速度短施策なし
php7:表示速度短縮ツールなし:ポイント概要

php7:表示速度短施策なし:GTmetrix

php7:表示速度短施策なし:GTmetrix:基本デザインページ

php5:エクスサーバーツール「mod_pagespeed」のみ有効化

php5:エクスサーバーツール「mod_pagespeed」のみ有効化:Google PageSpeed Insights
php7:表示速度短縮ツールなし:ポイント概要

php5:エクスサーバーツール「mod_pagespeed」のみ有効化:GTmetrix

php5:エクスサーバーツール「mod_pagespeed」のみ有効化:GTmetrix:基本デザインページ

php7:エクスサーバーツール「mod_pagespeed」のみ有効化

php7:エクスサーバーツール「mod_pagespeed」のみ有効化:Google PageSpeed Insights
php7:エクスサーバーツール「mod_pagespeed」のみ有効化:ポイント表

php7:エクスサーバーツール「mod_pagespeed」のみ有効化:GTmetrix

php7:エクスサーバーツール「mod_pagespeed」のみ有効化:GTmetrix:基本デザインページ

php5:WordPress高速化プラグイン「WP Fastest Cache」のみ有効化

php5:WordPress高速化プラグイン「WP Fastest Cache」のみ有効化:Google PageSpeed Insights
php5:WordPress高速化プラグイン「WP Fastest Cache」のみ有効化:ポイント表

php5:WordPress高速化プラグイン「WP Fastest Cache」のみ有効化:GTmetrix

php5:WordPress高速化プラグイン「WP Fastest Cache」のみ有効化:GTmetrix

php7:WordPress高速化プラグイン「WP Fastest Cache」のみ有効化

php7:WordPress高速化プラグイン「WP Fastest Cache」のみ有効化:Google PageSpeed Insights
php7:WordPress高速化プラグイン「WP Fastest Cache」のみ有効化:ポイント表

php7:WordPress高速化プラグイン「WP Fastest Cache」のみ有効化:GTmetrix

php7:WordPress高速化プラグイン「WP Fastest Cache」のみ有効化:GTmetrix:基本デザインページ

php5:「mod_pagespeed」設定後に「WP Fastest Cache」を設定

php5:「mod_pagespeed」設定後に「WP Fastest Cache」を設定:Google PageSpeed Insights
php5:「mod_pagespeed」設定後に「WP Fastest Cache」を設定:ポイント表

php5:「mod_pagespeed」設定後に「WP Fastest Cache」を設定:GTmetrix

php5:「mod_pagespeed」設定後に「WP Fastest Cache」を設定:GTmetrix:基本デザインページ

php7:「mod_pagespeed」設定後に「WP Fastest Cache」を設定

php7:「mod_pagespeed」設定後に「WP Fastest Cache」を設定:Google PageSpeed Insights
php7:「mod_pagespeed」設定後に「WP Fastest Cache」を設定:ポイント表

php7:「mod_pagespeed」設定後に「WP Fastest Cache」を設定:GTmetrix

php7:「mod_pagespeed」設定後に「WP Fastest Cache」を設定:GTmetrix:基本デザインページ

php5:「WP Fastest Cache」」設定後に「mod_pagespeedを設定

php5:「WP Fastest Cache」」設定後に「mod_pagespeedを設定:Google PageSpeed Insights
php5:「WP Fastest Cache」」設定後に「mod_pagespeedを設定:ポイント表

php5:「WP Fastest Cache」」設定後に「mod_pagespeedを設定:GTmetrix

php5:「WP Fastest Cache」」設定後に「mod_pagespeedを設定:GTmetrix:基本デザインページ

php7:「WP Fastest Cache」」設定後に「mod_pagespeedを設定

php7:「WP Fastest Cache」」設定後に「mod_pagespeedを設定:Google PageSpeed Insights
php7:「WP Fastest Cache」」設定後に「mod_pagespeedを設定:ポイント表

php7:「WP Fastest Cache」」設定後に「mod_pagespeedを設定:GTmetrix

php7:「WP Fastest Cache」」設定後に「mod_pagespeedを設定:GTmetrix:基本デザインページ

プログラムの都合上、php5にて、5条件で分析したのちにphp7にアップデートし同様の5条件で分析を行いました。

モバイル ファースト インデックスに備える

Googleは、去る2018年3月27日にモバイル・ファーズトインデックス(MFI)に移行することを正式に発表しました。

実質的なモバイル・ファーストインデックスへの移行はサーチコンソールにて通知されるようです。

参照記事:https://webmaster-ja.googleblog.com/2018/03/rolling-out-mobile-first-indexing.html

この記事の中で、Googleは下記のように通達しています。

「コンテンツを高速に読み込むことは、モバイルとデスクトップ両方のユーザーにとってより良い成果を上げる方法を検討しているウェブマスターにとっては、依然として役立ちます。」

また、次のようにも言っています。

「いつものように、ランキングには多くの要素を使用します。 他の多くの信号が最も関連性の高いコンテンツであると判断した場合は、モバイルフレンドリーでないコンテンツや、読み込みが遅いコンテンツをユーザーに表示することがあります。」

AMPについても、以下のように発表しています。

「レスポンシブ ウェブデザインやダイナミック サービングを使用しているサイトでは、一般的にモバイル ファースト インデックスが設定されています。AMP ページと非 AMP ページを持つサイトの場合、モバイル版の非 AMP ページをインデックスします。」

AMP「ダイナミックサービング」に関しては後述)

「コンテンツを高速に読み込むこと」と「コンテンツの表示に必要な時間」は、似て非なるもの

前回の記事で、私は『通信速度が5Gになっても(改善されても)、別のアナウンスでGoogleはデザインを指摘してくる?』と、言いました。

この前回の記事でも指摘しているように、「コンテンツを高速に読み込むこと」と「コンテンツを表示させるのに必要な時間」は、似て非なるものなのです。

その理由は、実際にコンテンツを閲覧する私たちにとって、「コンテンツを高速に読み込むこと」と「コンテンツを表示させるのに必要な時間」は、常に「通信規格」や「通信環境」に依存しますから、この2文が示す内容を同じものだと判断してしまいます。

しかし、Googleの場合、コンテンツ内容を収集するためのロボットは「通信規格」や「通信環境」に依存するのではなく「ロボットの性能」に依存します。

また、収集したデータは、Googleが蓄積し検索ランキングを表示するためのデータとして保存します。

そのため、(前回の記事と繰り返しになりますが)通信速度がより高速になったとしても、コンテンツのデータ量を軽減するようGoogleは指摘を続けると言うわけです。

上記の調査結果からも分かる通り、「コンテンツを読み込むのに必要だった時間(Fully Loaded time)」は、サーバーの応答時間に大きく影響を受けます。

また、サーバーの応答時間には、Googleが「PageSpeed Insights」の分析結果でも指摘する通り、「Total # of requests」の影響を受けます。

「Total # of requests」とは
ブラウザとサーバーのやり取りの回数。「PageSpeed Insights」の分析結果でも指摘している箇所としては、「ラウンド トリップ」の回数を減らすことに関連します。しかし、今回の分析結果では、「Total # of requests」回数が2ポイント程度改善されただけでは、顕著なGoogleの評価改善を得ることはできませんでした。
「ランウンドトリップ」とは
語弊が多少ありますが、簡潔に解説すると、コンテンツを表示するために、サーバーに問い合わせる回数を意味します。

PageSpeed Insightsで80点以上でもGTmetrixの「PageSpeed Score」で「F」判定になることがある

この調査後に、クライアントからの希望で、他社が作成したコンテンツの分析依頼があったので分析してみると、Googleの「PageSpeed Insights」のモバイル評価でGood評価の86点を得ているコンテンツでGTmetrix「PageSpeed Score」でF評価の33%、YSlow ScoreでD評価(68%)と言う判定が出ました。

少し気になって、モバイルフレンドリーテストも実施したのですが、案の定、そのコンテンツはモバイルフレンドリーではないと判定されました。

加えて、CSSを使わずJSも使わない、画像だけで構成されたページなら、「Fully Loaded time(コンテンツの読み込み時間)」が、10秒以上かかろうと「Total page size(コンテンツのデータ量)」が、どれだけ大きかろうとGoogleの「PageSpeed Insights」で、モバイル評価、パソコン評価ともに100点を獲得し、GTmetrixの「PageSpeed Score」「YSlow Score」ともにA判定の99%を獲得でき、さらに「モバイルフレンドリーテスト」においても合格できると言うことが判明しました。

もちろん、画像のみのページですので、検索ランキングに顔を出すことは、まず考えにくいページであることは言うまでもありませんが…。

また、「PageSpeed Insights」でも、GTmetrixでも、表示速度や各ツールの評価を下げているファイルに関して、最適化されたファイルを提供してくれる機能がついています。

キャッシュ系プラグインを使用している場合、これらのツールで最適化されたJSファイルやCSSファイルをダウンロードし直接head.phpに直書きし呼び出すことはかないません。

そのため、単純に改善できることは「画像の最適化のみ」と言うことになります。

本サイトでも順次「PageSpeed Insights」とGTmetrixで指摘されている画像をそれぞれのツールからダウンロードし最適化していますが、手始めにトップページで行なったところ、次のように改善されました。

「PageSpeed Insights」のモバイル評価のみ1ポイント悪化していますが、最適化に関する提案事項に変化がなかったため、その原因を追求することはできませんでした。

以上のことから、WordPressの高速表示を簡単に行なって、モバイルファーストインデックスに対応するための施策は以下の通りになると、私たちは考えます。

  1. WordPressを利用する場合は、土台となるWPテーマでは、見た目のデザインだけではなく、付随するプラグインとの兼ね合いや演出プログラム(アプリ)など、総合的にWordPress高速表示に対応したテーマを採用する。
  2. キャッシュ系プラグインはテーマとの相性を検証し、最適なものを使用する。
  3. エックスサーバーを利用している場合は、mod_pagespeedを有効にする。
  4. 画像は、各種ツールを使って最適なものを掲載する。
  5. テーマやプラグインは、随時アップデートが行われるため、直接的な書き換えは行わない。