Google PageSpeed Insightsは間違いなく、あらゆるタイプのウェブマスター、開発者、サイト所有者にとって有用なツールです。そして、このテストで100/100を獲得するために、多くの人がサイトの最適化に時間を費やしています。

しかし、これはGoogle PageSpeed Insightsの正しい使用方法ではなく、価値ある挑戦でもありません。ページ上部にある数字に翻弄されるのはやめましょう。プラットフォームの推奨事項の実装に焦点を合わせると、サイトに多くのメリットがもたらされます。

今回の記事では、Google PageSpeed Insightsを最大限に活用するための包括的なガイドをお届けします。Googleによるスコアの使い道、そしてあなたが受け取った推奨事項を活用する方法をご紹介します。

それでは参りましょう。

Google PageSpeed Insightsの基本

Google PageSpeed Insightsをご存知ない方のためにご紹介しますと、これはウェブサイトのパフォーマンスをテストするためのツールです。任意のURLを入力して分析することができます。

google pagespeed insights
Google PageSpeed Insights

すると、Googleから、いくつかのパフォーマンス最適化のベストプラクティスに基づき、テストしたWebサイトの100点満点での総合スコアが表示されます。

Google PageSpeed Insightsのスコア
Google PageSpeed Insightsのスコア

この結果に加えて、パフォーマンスを改善する方法について、Googleからの推奨事項も表示されます(そして、PageSpeed Insightsスコアも)。

Google PageSpeed Insightsによる推奨事項
Google PageSpeed Insightsによる推奨事項

2018年現在、PageSpeed Insightsのスコアは、ウェブページの全体の質を向上させるためのGoogleのオープンソース自動化ツールであるLighthouseを介して計算されます。このプラットフォームは、パフォーマンス、アクセシビリティ、プログレッシブウェブアプリなど、あらゆる種類の要因を評価できます。

Lighthouseによるサイトの包括的な評価を確認するには、 GoogleのMeasureが使用できます。

GoogleウェブマスターのMeasureを使ってサイトをチェック
GoogleウェブマスターのMeasureを使ってサイトをチェック

Google PageSpeed Insightsのようなパフォーマンスのチェックに加え、アクセシビリティ、ベストプラクティス、Search Engine Optimization (SEO)のスコアも取得できます。

Google PageSpeed Insightsでスコア100/100を獲得することの意味

冒頭で述べたように、完璧なPageSpeed Insightsスコアの達成に夢中になっているサイト所有者や開発者はたくさんいます。しかし、残念ながら、テスト結果のより重要な側面である推奨事項は見落とされがちです。

ウェブサイトの読み込み時間をできる限り改善するよう努力する必要はありますが、Google PageSpeed Insights100/100を取得することは実際にはそれほど重要ではありません。そもそも、これは、パフォーマンスについての万能なテストでもありません。

PageSpeed Insightsとは異なり、Pingdomを使用すると、さまざまな場所からサイトのパフォーマンスをテストできます。

Pingdomのスピードテストの結果
Pingdomのスピードテストの結果

GTmetrix(PageSpeed InsightsとYSlowのスコアを組み合わせて表示)やWebPageTestなどのプラットフォームでテストを実行することもできます。ほとんどの場合、このようなツールのスコアは正確には一致しないため、数値がどれほど主観的であるかがわかります。

本当に重要なのは、ウェブサイトの実際の読み込み速度です。PageSpeed Insightsで100/100というスコアを獲得していないものの、サイトの平均読み込み時間が500ミリ秒未満(これは非常に高速です!)であるサイトを実際にいくつも見たことがあります。

速度最適化へのアプローチに影響を与える他の要因として、サイトの感覚的なパフォーマンスがあります。サイト訪問者は、Google PageSpeed Insightsのスコアなど気にしません。コンテンツをできるだけ早く表示してほしいだけです。

Google PageSpeed Insightsでサイトのパフォーマンスをテストする本当の目的は、高得点を獲得することではありません。本質は、サイト上の問題箇所を見つけること。それを最適化すれば、実際の読み込み時間と感覚的な読み込み時間の両方を減らすことができます。

GoogleはPageSpeed Insightsをどのように使用しているのか

サイトのユーザーエクスペリエンス(UX)に影響を与えることに加え、サイトパフォーマンスはSEOにも影響を及ぼします。PageSpeed Insightsが世界最大かつ最も人気のある検索エンジンにより提供されているため、スコアが検索エンジンの結果ページ(SERP)のランキング(少なくともGoogleでは)に何らかの影響を与えると考えるのが自然です。

GoogleはPageSpeed Insightsを指標の一部として使用してランキングを決定しています。サイトの速度は、シンプルにランキングに影響を与える要素の一種です。そのような意味で、パフォーマンステストのスコアから、これがランキングに与える影響を推し量ることができるでしょう。

ただし、Googleは、PageSpeedの結果上部に表示される丸の中の数字だけでなく、それ以上の要素を考慮します。仮に100/100を記録したとしても、SERPでトップが獲得できると保証されるわけではありません。

そうは言っても、SEO改善のために、PageSpeed Insightsの結果を活用することができます。現に2018年から、モバイルページの速度がGoogleのランキング要素となっています。パフォーマンステストには、サイトのデスクトップバージョンとモバイルバージョンの両方のデータが表示されます。

Google PageSpeed Insightsのモバイルタブ
Google PageSpeed Insightsのモバイルタブ

モバイルインターネットユーザーの73%以上が「読み込みに時間がかかりすぎるサイトに遭遇したことがある」という状況を考えると、Google PageSpeed Insightsの「モバイル」タブの情報は非常に重要です。ここでの推奨事項を使用して、スマートフォンやその他のデバイスで読み込み時間を短縮すると、競争力が高まります。

Google PageSpeed Insightsの推奨事項(パフォーマンスを改善する24の方法)

ここまで既にGoogle PageSpeed Insightsの推奨事項について多くのことをお伝えしました。これは、パフォーマンステスト結果の本質であり、数字でのスコアよりもはるかに重要です。だからこそ、ここからは全て、推奨事項を深く理解することに焦点を当てたいと思います。

ただし、個々の提案について詳しく説明する前に、「フィールドデータ」と「ラボデータ」の違いを理解する必要があります。前者は、過去30日間のChromeユーザーエクスペリエンスレポートを使い、あなたのサイトと他のサイトを比較します。

また、First Contentful Paint (FCP)初回入力遅延 (FID) の平均値を示す2つのチャートも表示されます。

Google PageSpeed Insightsのフィールドデータ
Google PageSpeed Insightsのフィールドデータ

上の画像は、サイトのFCPは75パーセンタイルのサイトの45%とほぼ同じであり、FIDは95パーセンタイルの9%とほぼ同じ、という意味になります。

ラボデータは、ページ読み込みシミュレーションをした際の特定のデータを示したものです。

Google PageSpeed Insightsのラボデータ
Google PageSpeed Insightsのラボデータ

「フィールドデータ」と「ラボデータ」が完全に一致していないことに気付くでしょう—これは正常です。「ラボデータ」は一定の条件下で作成されるもので、「フィールドデータ」は実際に収集された読み込み速度を使用します。

「フィールドデータ」と「ラボデータ」を組み合わせて見ると、サイトの実際の読み込み時間を推し量ることができます。前述のように、これはPageSpeedスコアよりも重要なので、こちらの数値に注意を払う必要があります。

この点を踏まえた上で、Google PageSpeedの推奨事項を使用してサイトのパフォーマンス改善を開始しましょう。

1. レンダリングを妨げるリソースの除外

Google PageSpeed Insightsからの最も一般的な推奨事項の1つが、「レンダリングを妨げるリソースの除外」です。

「レンダリングを妨げるリソースの除外」
「レンダリングを妨げるリソースの除外」

これは、ページのすばやい読み込みを阻害しているJavaScriptやCSSスクリプトを意味します。訪問者のブラウザは、ページの残りを表示する前にこのファイルをダウンロードし処理する必要があるため、「スクロールせずに見える範囲」に多くのファイルがあると、サイトの速度に悪影響を及ぼすことになってしまいます。

この問題の詳細については、 レンダリングを妨げるスクリプトを削除する方法をご覧ください。Googleの提示する解決策は2つあります。

  • JavaScriptやCSSがあまり多くない場合は、インライン化してこの警告を取り除くことができます。つまり、JavaScriptやCSSをHTMLファイルに組み込みます。これを行うには、Autoptimizeなどのプラグインが使用できます。ただし、これは非常に小さなサイトでのみ機能します。ほとんどのWordPressサイトには十分なJavaScriptがあり、この方法を実行することで実際に速度が低下する可能性があります。
  • もう1つのオプションは、JavaScriptの読み込みを遅らせることです。この属性は、HTML解析中にJavaScriptファイルをダウンロードしますが、解析の完了後にのみ実行します。また、この属性を持つスクリプトは、ページに表示される順に実行されます。

PageSpeedの推奨事項の下には、この問題により影響を最も受けているリソースが掲載されています。

2. クリティカルなリクエストの深さの最小化

クリティカルなリクエストの深さは、クリティカル レンダリング パス(CRP)の最適化、ブラウザによるページの読み込み方に関係しています。上で説明したJavaScriptやCSSなどの特定の要素は、ページが表示される前に完全に読み込まれる必要があります。

この提案の一環として、Google PageSpeed Insightsは分析ページにリクエストチェーンを表示してくれます。

「クリティカルなリクエストの深さの最小化」
「クリティカルなリクエストの深さの最小化」

この図は、ページ表示前に実行されなければならない一連のリクエストを表しています。また、各リソースのサイズもわかります。理想的には、リクエストの数とサイズを最小限に抑えたいところです。

今回の記事で扱う他の推奨事項をクリアすることで、複数の面からこれを達成することができます。

  • レンダリングを妨げるリソースの除外
  • オフスクリーン画像の遅延読み込み
  • CSSとJavaScriptの最小化

さらに、CRPを短縮するために、アセット読み込みの順序を最適化できます。つまり、スクロールせずに見える範囲のコンテンツの、、HTMLファイル先頭への移動です。CRP最適化の詳細については、WordPressのクリティカルレンダリングパスを最適化する方法をご覧ください。

大事な点として、クリティカルなリクエストの深さに絶対的な答えはありません。Google PageSpeed Insightsは、他の多くの推奨事項とは異なり、この監査を「合格」または「不合格」として判断しません。この情報は、読み込み時間を改善するために利用できるようになっています。

3. リクエスト数を少なく、転送サイズを小さく維持する

ブラウザがページを読み込むために多くのリクエストを行う必要があり、サーバーが応答で返すリソースが大きいほど、Webサイトの読み込みにかかる時間が長くなります。したがって、Googleが、必要なリクエストの数を最小限に抑えリソースのサイズを小さくすることを推奨するのは、理にかなっています。

推奨事項「クリティカルなリクエストの深さの最小化」と同じように、これも「合格」または「不合格」では判断されません。代わりに、リクエストの数とサイズが一覧で表示されます。

「リクエスト数を少なく、転送サイズを小さく維持」
「リクエスト数を少なく、転送サイズを小さく維持」

基準となるリクエスト数や最大サイズはありません。Googleは代わりに、パフォーマンスバジェットを設けることで基準を用意することを推奨しています。具体的には、以下のような側面を考慮するようにしましょう。

  • 最大画像サイズ
  • 使用するウェブフォントの数
  • 呼び出す外部リソースの数
  • スクリプトとフレームワークのサイズ

パフォーマンスバジェット(注釈:パフォーマンスについての指標の上限)を作成すると、日々の行動の基準が得られます。バジェットを超えたら、リソースを削除するか最適化するかを決めて、事前に決めたガイドラインに従うようにしましょう。Google独自のガイドから、作成方法の詳細をご覧ください。

4. CSSの最小化

CSSファイルは、人間の読みやすさのために、必要以上に大きくなっていることがよくあります。そして、コンピューターがその内容を理解するために必要ではないさまざまなキャリッジリターンとスペースが含まれることもあります。

CSSの最小化とは、不要な文字、スペース、重複を排除してファイルを圧縮するプロセスです。CSSファイルのサイズが小さくなり、読み込み速度が向上するため、Googleはこの方法を推奨しています。

「CSSの最小化」
「CSSの最小化」

AutoptimizeやWP Rocketなどのプラグインを使用して、CSSファイルを縮小することをお勧めします。

5. JavaScriptの最小化

縮小によってCSSファイルのサイズを縮小できるように、JavaScriptファイルにも同じことが言えます。

「JavaScriptの最小化」
「JavaScriptの最小化」

AutoptimizeやWP Rocketは、WordPressサイトでこのタスクも処理できます。

6. 使用していないCSSを削除

スタイルシートのコードは全て、ページをユーザーに表示するために読み込まれるものです。サイトの役に立たないCSSがある場合、無駄な場所に労力を投じていることになります。

だからこそ、Googleは使用していないCSSを削除することを推奨しています。

「使用していないCSSを削除」
「使用していないCSSを削除」

ここでの考え方は、本質的に、レンダリングを妨げるCSSの除外と同じです。ページのためになる方法で、スタイルをインライン化または遅延できます。また、Chrome DevToolsなどのツールを使用して、最適化が必要な使われていないCSSを見つけることもできます。

7. メインスレッド処理の最小化

「メインスレッド」は、ユーザーのブラウザの主要な要素であり、コードを(訪問者が操作することのできる)Webページに変える役割を果たします。HTML、CSS、JavaScriptを解析、実行します。さらに、ユーザーインタラクションの処理も担います。

つまり、メインスレッドがサイトのコードを処理する時には、ユーザーリクエストを処理できなくなります。サイトのメインスレッドの作業に時間がかかりすぎると、UXが低下し、ページの読み込み時間が遅くなる可能性があります。

Google PageSpeedは、メインスレッドの作業を完了し、利用可能な状態のWebページを表示するのに4秒以上かかるページにフラグを付けます。

メインスレッド処理の最小化
メインスレッド処理の最小化

メインスレッドの作業を軽減する方法の一部は、この記事の他のセクションでご紹介しています。

  • コードの最小化
  • 使用していないコードの削除
  • キャッシュの実施

加えて、コードの分割を検討することもできます。つまり、ブラウザにすべてを読み込ませてページをインタラクティブにする代わりに、JavaScriptが必要とされるときにだけ実行できるバンドルへと分割します。

コードの分割の実装にはWebpackがよく使用されます。これはかなり高度な手法ですのでご注意ください。通常、初心者は単独で行わない方がいいでしょう。

8. JavaScriptの実行にかかる時間の低減

JavaScriptの実行は、多くの場合、メインスレッドの中でも最も顕著な作業になりがちです。PageSpeed Insightsには、このタスクがサイトのパフォーマンスに大きな影響を与えている場合に警告するための個別の推奨事項があります。

「JavaScriptの実行にかかる時間の低減」
「JavaScriptの実行にかかる時間の低減」

メインスレッドの作業を減らすために上でご紹介した方法は、PageSpeedのこの警告の解決にもつながるはずです。

9. サーバーの応答時間を減らす

「Time to First Byte」(TTFB)とは、リクエストを行った後、ブラウザがサイトのサーバーからデータの最初の1バイトを受信するまでにかかる時間です。これはサイトの全体的な速度とは異なりますが、TTFBを低くすると、サイトのパフォーマンスを向上させることができます。

だからこそ、サーバーの応答時間を短縮することが、Google PageSpeed Insightsの推奨事項の1つとして含まれています。TTFBを短くすることに成功すると、合格した監査の項目に次のメッセージが表示されます。

「サーバーの応答時間が遅い」の解消
「サーバーの応答時間が遅い」の解消

TTFBに影響を及ぼす要因はいくつかあります。これを下げるための戦略は以下の通りです。

  • 質の高いWebホスティングプロバイダーを選ぶ
  • 軽量のテーマとプラグインを使用する
  • インストールするプラグインの数を減らす
  • コンテンツデリバリネットワーク(CDN)の利用
  • ブラウザキャッシュの実装
  • 信頼できるドメインネームシステム(DNS)プロバイダーを選択する

この分野での最適化をもっと詳しく理解したい方は、TTFBに関するこちらの記事をご覧ください。

10. 適切なサイズの画像

画像などのメディアファイルは、サイトのパフォーマンスに大きな影響を及ぼす可能性があります。これを適切なサイズにすることで読み込み時間を短縮できます。

「適切なサイズの画像」
「適切なサイズの画像」

ページに必要以上に大きい画像が含まれている場合、CSSを使用して適切なサイズに変更されます。これは、最初から画像を適切なサイズで読み込むだけの場合よりも時間がかかるため、ページのパフォーマンスに影響します。

これを修正するには、適切なサイズで画像をアップロードするか、「レスポンシブ画像」を使用しましょう。例えば、さまざまなデバイス毎に異なるサイズの画像を作成することが考えられます。

これの実装には、srcset属性が使用できます。これを<img>タグに追加することで、さまざまなサイズの代替画像ファイルが指定できます。ブラウザはこのリストを読み、画面に最適なオプションを判断し、そのバージョンの画像を配信する仕組みです。

たとえば、ヘッダー画像があり、それをレスポンシブにしたいとします。800、480、320ピクセルという3つのバージョンをアップロードします。次に、次のようにsrcset属性を適用します

<img srcset="header-image-800w.jpg 880w,
		Header-image-480w.jpg 480w,
		Header-image-320w.jpg 320w"
	sizes="(max-width: 320px) 280px,
		(max-width: 480px) 440px,
		800px"
	src="header-image-800w.jpg">

srcset属性は、使用できるさまざまなファイルを指定し、sizes属性は、画面サイズに基づいて使用するファイルをブラウザに指示します。

11. オフスクリーン画像の遅延読み込み

オフスクリーン画像を遅延させるプロセスは、一般的に「lazy loading / 遅延読み込み」として知られています。これは、ページ上のすべての画像をまとめてブラウザに読み込ませる代わりに、スクロールせずに見える画面の画像のみを読み込むようにする手法です。

ページ表示のための読み込みが少なくなり、パフォーマンスが向上するため、Googleはこの方法を推奨しています。

「オフスクリーン画像の遅延読み込み」
「オフスクリーン画像の遅延読み込み」

a3 Lazy LoadLazy Load by WP Rocketなど、遅延読み込み専用に開発されたWordPressプラグインはいくつもあります。Autoptimizeなどのさまざまな画像・パフォーマンス最適化プラグインにも、遅延読み込み機能があります。WordPressでの画像と動画の遅延読み込みに関する詳細ガイドもあわせてご覧ください。

12. 効率的な画像フォーマット

前述のように、画像はサイトのパフォーマンスに大きな影響を与えます。最も基本的な最適化のベストプラクティスの1つは、圧縮です。ファイルサイズを小さくして読み込みの高速化を助けます。また、Googleの推奨事項「効率的な画像フォーマット」に従う主要な方法でもあります。

「効率的な画像フォーマット」
「効率的な画像フォーマット」

重要なのは、画像自体の質を犠牲にすることなく、可能な限り小さいファイルサイズを実現すること。ImagifySmushなどのプラグインが便利です。詳細については、 画像最適化ガイドをご覧ください。

「効率的な画像フォーマット」の「合格」または「不合格」に影響を与えるその他の推奨事項には、以下のようなものがあります。

  • 適切なサイズの画像
  • 遅延読み込み(オフスクリーン画像の遅延)
  • WebPなど次世代フォーマットでの画像の配信
  • アニメーションコンテンツにビデオを使用(GIFなど)

画像の圧縮に加えて、当記事の随所にある手順に従うことで、これらの推奨事項をクリアできます。

13. 次世代フォーマットでの画像の配信

高速に読み込むことのできる画像ファイル形式があります。それは、残念ながら、一般的なPNGやJPEGではありません。WebP形式の画像は新しい標準になりつつあり、画像がそれに準拠していない場合には、Google PageSpeedが教えてくれます。

「次世代フォーマットでの画像の配信」
「次世代フォーマットでの画像の配信」

WordPressサイトに既に十分な画像がある場合には、これを満たすのは簡単ではないように思えるでしょう。しかし、プラグインを使えば、簡単にこれをクリアできます。たとえば、ImagifyとSmushのどちらにもWebP変換機能が搭載されています。

14. アニメーション コンテンツでの動画フォーマットの使用

GIFは、さまざまな状況で使える、視覚的なコンテンツを効果的に届ける形式です。使用方法の説明、機能のレビュー、さらにはユーモラスなアニメーションなどなど…記事にアクセントを加え、楽しく価値のあるコンテンツの作成に活用できます。

残念ながら、そんなメリットは犠牲を伴います。GIFの読み込みには「手がかかる」ため、PageSpeed Insightsは代わりに動画コンテンツの配信を推奨しています。

「アニメーション コンテンツでの動画フォーマットの使用」
「アニメーション コンテンツでの動画フォーマットの使用」

残念ながら、GIFをビデオ形式に変換するのは簡単ではありません。まず、使用するビデオのタイプを決定する必要があります。

  • MP4:生成されるファイルはわずかに大きめになりますが、ほとんどの主要なブラウザと互換性があります。
  • WebM:最も高度に最適化されたビデオ形式ですが、ブラウザとの互換性は限られています。

サイトにとって最適な選択を行ったら、次はファイル形式の変換です。コマンドラインを使用するのが一番でしょう。まずは、FFmpegをインストールしてください。ファイル形式を変換するためのオープンソースツールです。

ビデオ・オーディオファイル用形式変換ツール「FFmpeg」
ビデオ・オーディオファイル用形式変換ツール「FFmpeg」

次に、コマンドラインインターフェースを開き、次のコマンドを実行します。

ffmpeg -i input.gif output.mp4

これにより、ファイル名「input.gif」のGIFがファイル名「output.mp4」のMP4ビデオに変換されます。ただし、形式の変更は、プロセス全体のほんの序章に過ぎません。アニメーションGIFのように見えるように、出来上がったビデオをWordPressサイトに埋め込む必要があります。

アニメーション用ビデオコンテンツを埋め込む

これまでにGIFを見たことがある方はこれが通常の動画とは少し異なることをご存知でしょう。通常、自動再生され、ループで実行され、音は鳴りません。新しいMP4またはWebMファイルをWordPressサイトに埋め込んでも、これらの機能は自動で実装されません。

ただし、難しいことはありません。簡単なコードを加えるだけで、この問題を解消できます。ビデオをメディアライブラリにアップロードしてから、次のコードをGIFを表示したい固定ページや投稿に貼り付けます。

<video autoplay loop muted playsinline>
<source src="output.mp4" type="video/mp4">
</video>

これにより、指定した属性が動画に適用され、より「GIFに似た」外観になります。実際のリソースに合わせて、ファイル名とタイプを調整するだけでOKです。詳細については、GoogleによるGIFを動画に変換する方法についてのガイドに目を通すことをお勧めします。

15. ウェブフォント読み込み中のテキストの表示

画像と同様に、フォントは読み込みに時間がかかる大きなファイルとなる傾向があります。場合によっては、使用しているフォントが完全に読み込まれるまでブラウザがテキストを非表示にすることも。このような理由から、Google PageSpeed Insightsからの推奨事項が表示されます。

「ウェブフォント読み込み中のテキストの表示」
「ウェブフォント読み込み中のテキストの表示」

Googleは、@font-faceでフォントディスプレイAPI「swap」を適用することで、この問題を解決することを推奨しています。これを行うには、スタイルシート(style.css)を開き、@font-face内、src属性の後に以下を追加します。

font-display: swap

ウェブフォント最適化の詳細については、 WordPressでフォントを変更する方法ローカルフォントをホストするための詳細ガイドをご覧ください。

16. テキスト圧縮の有効化

Google PageSpeed Insightsの「テキスト圧縮の有効化」は、GZIP圧縮の使用を意味します。

「テキスト圧縮の有効化」
「テキスト圧縮の有効化」

場合によっては(上の画像でわかるように)、サーバーでテキスト圧縮が自動的に有効になります。これがあなたのサイトに当てはまらない場合は、いくつかの手段を用いて推奨に従うことができます。

1つ目は、GZIP圧縮機能を備えたプラグインをインストールすること。WP Rocketは、支払いを厭わない場合には、便利なソリューションです。

テキストを手動で圧縮することもできます。この際には.htaccessファイルの編集が必要となります。リスクが介在するため、最新のバックアップを手元に用意してから着手するようにしましょう。

ほとんどのWordPressサイトはApacheサーバーで実行されます。GZIP圧縮を有効にするためのコードは次のようになります。

<IfModule mod_deflate.c>
  # Compress HTML, CSS, JavaScript, Text, XML and fonts
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/rss+xml
  AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
  AddOutputFilterByType DEFLATE application/x-font
  AddOutputFilterByType DEFLATE application/x-font-opentype
  AddOutputFilterByType DEFLATE application/x-font-otf
  AddOutputFilterByType DEFLATE application/x-font-truetype
  AddOutputFilterByType DEFLATE application/x-font-ttf
  AddOutputFilterByType DEFLATE application/x-javascript
  AddOutputFilterByType DEFLATE application/xhtml+xml
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE font/opentype
  AddOutputFilterByType DEFLATE font/otf
  AddOutputFilterByType DEFLATE font/ttf
  AddOutputFilterByType DEFLATE image/svg+xml
  AddOutputFilterByType DEFLATE image/x-icon
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/javascript
  AddOutputFilterByType DEFLATE text/plain
  AddOutputFilterByType DEFLATE text/xml

  # Remove browser bugs (only needed for really old browsers)
  BrowserMatch ^Mozilla/4 gzip-only-text/html
  BrowserMatch ^Mozilla/4\.0[678] no-gzip
  BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
  Header append Vary User-Agent
</IfModule>

これを.htaccessファイルの#ENDの後に追加してください。NginxサーバーにWordPressサイトがある場合には、代わりに次のコードをnginx.confファイルに追加します。

36 gzip on;
37 gzip_disable "MSIE [1-6]\.(?!.*SV1)";
38 gzip_vary on;
39 gzip_types text/plain text/css text/javascript application/javascript application/x-javascript;

サイトのテキスト圧縮を確認するには、GiftOfSpeedなどのツールが使用できます。

GiftOfSpeedを用いたGZIP圧縮のチェック
GiftOfSpeedを用いたGZIP圧縮のチェック

これにより、GZIP圧縮が正常に実装されたかどうか、サイトで使用しているサーバーの種類、そして、その他の重要な詳細情報がわかります。

17. 必須のドメインへの事前接続

おそらく、あなたのサイトにも少なくとも1つのサードパーティリソースがあるはず。代表的なものがGoogleアナリティクスです。ブラウザがこのようなリソースへの接続を確立するのに時間がかかり、読み込み速度が低下します。

preconnect属性は、ページに読み込む必要のあるサードパーティのスクリプトがあることをブラウザにすぐに伝えます。そして、それを要求するプロセスをできるだけ早く開始し、パフォーマンスを向上させることができます。

あなたのページがこの手法を用いて改善できるとGoogleが判断した場合、「必須のドメインへの事前接続」の提案が表示されます。

「必須のドメインへの事前接続」
「必須のドメインへの事前接続」

この最適化を実装するには、いくつかの方法があります。WordPressテーマファイルの編集に慣れている場合は、header.phpファイルにリンクタグを追加することができます。以下に例を示します。

<link rel=“preconnect” href=“example.com”>

ここでは、タグはブラウザに対して「example.com」への接続をできるだけ早く確立する必要があることを伝えています。Google PageSpeed Insightsには、 preconnect属性を追加する必要があるリソースが表示されます。

もう一つの方法として、プラグインを使用することもできます。Perfmattersには事前接続機能が搭載されています(ちなみに…告白しますと、私はPerfmatters創設に関わった1人です)。WP RocketとPre* Party Resource Hintsにも、同様の機能があります。

18. キー リクエストのプリロード

「必須のドメインへの事前接続」と同様に、この提案に従うと、ブラウザがサイトのサーバーに対して行う必要のあるリクエスト数を最小限に抑えることができます。ただし、サードパーティのリソースに接続する訳ではなく、「キー リクエストのプリロード」とは、重要なアセットを自分のサーバーで読み込むことを意味します。

「キー リクエストのプリロード」
「キー リクエストのプリロード」

この実装方法は、一つ前の推奨事項のものと非常によく似ています。リソース(PageSpeed Insightsに掲載される)を指定したリンクタグをheader.phpファイルに追加します。

<link rel=“preload” href=“example.com”>

これについても、Perfmatters、WP Rocket、またはPre* Party Resource Hintsを使用して、このタグを組み込むこともできます。

19. 複数のページ リダイレクトの回避

リダイレクトは、あるURLが別のURLを指すように指定したいときに使用されます。サイトのページを移動または削除するときにお馴染みです。一般的にリダイレクトを使用すること自体、何も問題はありませんが、これは読み込み時に遅延を引き起こす要因となり得ます。

サイトのリダイレクトが多すぎると、Google PageSpeed Insightsに次の推奨事項が表示されることがあります。

「複数のページ リダイレクトの回避」
「複数のページ リダイレクトの回避」

解決策はこちら。どうしても必要な場合にのみリダイレクトを使用すること。具体的なプロセスについては、WordPressリダイレクト—パフォーマンス向上のためのベストプラクティスをご覧ください。

20. 静的なアセットと効率的なキャッシュ ポリシーの配信

Google PageSpeed Insightsを以前から使用している方は、「ブラウザのキャッシュを活用する」として、この推奨事項に馴染みがあるかもしれません。バージョン5では、「静的なアセットと効率的なキャッシュ ポリシーの配信」という名前になっています。

「静的なアセットと効率的なキャッシュ ポリシーの配信」
「静的なアセットと効率的なキャッシュ ポリシーの配信」

この提案には、いくつかのレイヤーがあります。1つ目は、「キャッシュ」です。これはブラウザがページのコピーを保存することを意味し、将来的なアクセスの際にはより速く読み込むことが可能になります。

WordPressサイトでキャッシュを実装する最も一般的な方法は、プラグインを使用することでしょう。中でも、WP RocketやW3 Total Cacheといったプラグインが人気です。ただし、一部のホスティングプロバイダー(Kinstaなど)は、サーバー経由でのキャッシュを有効にしています。キャッシュプラグインをインストールする前に、お使いのホスティングサービスの状況を確認してください。

サイトのキャッシュを有効にしたら、この推奨事項の2番目の部分、つまりキャッシュポリシーの「効率」について検討しましょう。ブラウザは定期的にキャッシュをクリアして、その情報を最新のものへと更新します。

理想的には、この期間を長くしたいところです。数時間ごとにブラウザのキャッシュからサイトをクリアすると、そもそもこの手法を使用する目的に反します。「Cache-Control」と「Expires」ヘッダーを使用して、キャッシュの有効期限を最適化できます。

Cache-Controlヘッダーの追加

次のコードを使用して、NginxにCache-Controlヘッダーを追加することができます。

location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
 expires 30d;
 add_header Cache-Control "public, no-transform";
}

これをサーバーの構成ファイルに追加します。上記の例では、指定したファイルタイプは30日後に期限切れになるように設定されています。

Apacheサーバーを使用している場合には、代わりに.htaccessファイルでこのスニペットを使用してください。

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"
</filesMatch>

このコードを、#BEGIN WordPressの前、または、#END WordPressの後に追加します。この例では、キャッシュの有効期限は84,600秒に設定しています。

Expiresヘッダーの追加

現在、Cache-Controlヘッダーの方が業界標準となっています。とは言え、Expiresヘッダーをチェックするツール(GTMetrixなど)も存在します。

これをNginxサーバーに追加するには、以下をサーバーブロックに組み込んでください。

location ~*  \.(jpg|jpeg|gif|png|svg)$ {
        expires 365d;
    }

    location ~*  \.(pdf|css|html|js|swf)$ {
        expires 2d;
    }

ファイルタイプに基づいて異なる有効期限を設定する必要があります。このコードを.htaccessファイルに追加すると、Apacheサーバーで同じ結果が得られます。

## EXPIRES HEADER CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/svg "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"
</IfModule>
## EXPIRES HEADER CACHING ##

先と同じように、 #BEGIN WordPressの前、または、#END WordPressの後にこのコードを追加します。

Google Analyticsの効率的なキャッシュ

皮肉なことに、ユーザーの行動を追跡するためにページのヘッダーに追加するGoogleアナリティクススクリプトのキャッシュ有効期限はわずか2時間。これは、プラットフォームが更新された場合であっても、ユーザーが変更内容にすばやくアクセスできるようにするための仕様です。

このスクリプトは、「静的なアセットと効率的なキャッシュ ポリシーの配信」項目で注意が必要なリソースの一覧に表示されます。サードパーティに属しているため、Cache-ControlまたはExpiresヘッダーで有効期限を変更することはできません。

これが同項目で表示されていても(表示される唯一のスクリプトであるとき)監査には合格できます。

効率的なキャッシュポリシーの監査に合格
効率的なキャッシュポリシーの監査に合格

ただし、今回の記事全体で強調しているように、PageSpeedのスコアは実際のパフォーマンスや感覚的なパフォーマンスよりも重要ではありません。このリソースを効率的に配信するために、Googleアナリティクスをローカルでホストすることも検討できるでしょう。

Complete Analytics Optimization Suite (CAOS)やPerfmattersなどのプラグインを使用すると、これを実装できます。詳細については、PageSpeedの提案完全ガイドをご覧ください。

21. 第三者コードの影響を抑える

サードパーティのスクリプトがパフォーマンスに悪影響を及ぼし、PageSpeed Insightsからの監査に失敗する可能性をもたらすことについては、ここまででご紹介した通りです。悪影響を防ぐために、そのようなツールへの依存を制限することが理想的です。

とは言え、サードパーティのスクリプトを組み込むことでサイトに必要とされる機能を実装することが避けられない場合もあるでしょう。Googleアナリティクスが好例です。その他には以下のような可能性が考えられます。

  • SNSシェアボタンやフィード
  • YouTubeビデオの埋め込み
  • 広告やその他コンテンツ用のiFrame
  • JavaScript、フォントなどの要素

サードパーティスクリプトの使用が必要と思われる場合でも、(PageSpeedの分析結果から次のようなメッセージが表示されることを考えると)サイトパフォーマンスへの影響を減らすことが重要です。

第三者コードの影響を抑える
第三者コードの影響を抑える

サードパーティのコードをより効率的に読み込むためには、今回の記事で既に触れたテクニックが利用できます。

  • JavaScriptの読み込みを遅らせる
  • preconnect属性のリンクタグを使う
  • サードパーティスクリプトを自己ホスティングする(上のGoogleアナリティクスの例で説明したとおり)

これらの方法で、サイトパフォーマンスへの影響を最小限に抑えることができます。

22. 過大なネットワーク ペイロードの回避

この推奨事項は、特にモバイル端末を使った訪問者に関連しています。ペイロードが大きいと、より多くのセルラーデータを使用する必要があるため、ユーザーの費用がかさみます。ページ到達に必要なネットワークのリクエスト数を最小限に抑えると、これを防ぐことができます。

「過大なネットワーク ペイロードの回避」
「過大なネットワーク ペイロードの回避」

Googleは、合計バイトサイズを1,600 KB以下にすることをお勧めしています。これを達成するために一般的に使用される方法は、以下の通りです(今回の記事の各所で扱っています)。

  • スクロールせずに見える範囲外にあるCSS、JavaScript、画像の読み込み遅延
  • コードの最小化
  • 画像ファイルの圧縮
  • 画像にWebP形式を使用する
  • キャッシュの実装

関連する手法を実行するだけで、その他に特別な労力をかけずにこの監査に合格することができます。

23. カスタム速度の記録と計測

この推奨事項は、 User Timing API/ユーザータイミングAPIを使用している場合にのみ該当します。このツールはタイムスタンプを作成して、JavaScriptのパフォーマンスを評価する役割を果たします。サイトにAPIを設定している場合、PageSpeed Insightsのこの見出しの下に記録と計測に関するデータが表示されます。

「カスタム速度の記録と計測」
「カスタム速度の記録と計測」

ご覧のとおり、これは「合格」または「不合格」では判断されないGoogleからの情報提供です。 PageSpeed Insightsに表示されるこの情報は、最適化が必要となる可能性のある領域を評価するために使用できます。

User Timing APIをWordPressサイトに組み込むことに関心のある方は、これに関するMozilla提供のガイドをご覧ください。

24. 過大な DOM サイズの回避

簡単に言えば、DOMとは、ブラウザがHTMLをオブジェクトに変換する手法です。これは、オブジェクトを表す個々のノードで構成される階層構造を用います。当然、ページのDOMが大きいほど、読み込みに時間がかかります。

ページがDOMサイズに関する特定の基準を超えている場合、ノードの数とCSSスタイルの複雑さを軽減することをお勧めします。

「過大な DOM サイズの回避」
「過大な DOM サイズの回避」

PageSpeed Insightsでこの監査に「不合格」となった場合の一般的な原因は、WordPressのテーマです。重いテーマは、多くの場合、DOMに大量の要素を追加します。また、サイトの速度を低下させる複雑なスタイル設定が含まれることもあります。そんな場合には、テーマを他のものに切り替える必要があるでしょう。

まとめ

Google PageSpeed Insightsは、ウェブサイト所有者にとっての必需品。ただし、スコアに固執しすぎて、100/100に到達することに全力を注ぐのは賢い時間の使い方とは言えません。より重要なメリットをもたらしてくれる重要なタスクを見落としてしまう危険性があります。

今回の記事では、Google PageSpeedスコアそのものよりも重要なポイントをご紹介しました。また、パフォーマンスを向上させるために、推奨事項をWordPressサイトにどのように活かすことができるのか、についても扱いました。

Google PageSpeed Insightsまたはサイトのパフォーマンス最適化についてご質問はございますか?下のコメント欄からお気軽にお寄せください!

Brian Jackson

Brianの最大の情熱の一つは10年以上使用してきたWordPressです。複数のプレミアムプラグインさえ開発しています。Brianの趣味はブログや映画やハイキングなどです。TwitterでBrianとつながりましょう。