Google PageSpeed Insights—100点満点を獲得することの真実

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

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

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

Google PageSpeed Insightsの基本

Google PageSpeed Insightsは、ウェブサイトのパフォーマンスを測定するためのツールです。ウェブサイトに任意のURLを入力して分析することができます。

URLを貼り付けて「分析」をクリックすると、パフォーマンス最適化のベストプラクティスに基づいたスコアが100点満点で表示されます。

スコアとともに、パフォーマンスの改善方法に関するGoogleからの推奨事項も表示されます。

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

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

Google PageSpeed Insightsのようなパフォーマンスのチェックに加え、アクセシビリティ、ベストプラクティス、検索エンジン最適化（SEO）のスコアも取得できます。

Google PageSpeed Insightsで100点満点を取ることの意味

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

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

PageSpeed Insightsとは異なり、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のランキング要素となっています。パフォーマンステストには、サイトのデスクトップバージョンとモバイルバージョンの両方のデータが表示されます。

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

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

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

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

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

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

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

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

「フィールドデータ」と「ラボデータ」を組み合わせて見ると、サイトの実際の読み込み時間を推し量ることができます。前述のように、これは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はこの方法を推奨しています。

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

5. JavaScriptの最小化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

メインスレッドの作業を減らすために上でご紹介した方法は、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 Load、Lazy Load by WP Rocketなど、遅延読み込み専用に開発されたWordPressプラグインはいくつもあります。Autoptimizeなどのさまざまな画像・パフォーマンス最適化プラグインにも、遅延読み込み機能があります。WordPressでの画像と動画の遅延読み込みに関する詳細ガイドもあわせてご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サイトにとって最適な選択を行ったら、次はファイル形式の変換です。コマンドラインを使用するのが一番でしょう。まずは、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などのツールが使用できます。

これにより、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などのプラグインを使用すると実装できます。詳しくはこちらをご覧ください。

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サイトに組み込む方法はこちらをご覧ください。

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

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

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

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

まとめ

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

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

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

Brian Jackson

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

【共用サーバーを超える】WordPress専用マネージドホスティング

YEG Digital、サイト管理のストレス低減で手にしたのは心安らぐ休日

ウィルオブ・ワーク、Kinstaへの切り替えがコンバージョン率の改善に直結

Google PageSpeed Insightsで100点満点を取る意味