Google PageSpeed Insightsスコアを向上させるWordPress改善チェックリスト｜90点超えを目指そう | WPセンターブログ

WordPressサイトのパフォーマンスは、ユーザー体験やSEOに直結する重要な要素です。特にPageSpeed Insightsのスコアが90点以上を獲得できれば、サイト表示速度で訪問者の離脱を防ぎ、検索順位にも良い影響を与えます。本記事では、Lighthouseの監査項目を元に、WordPressに特化した実践的チェックリストを具体的な手順やプラグイン例とともに解説。競合の概念論を超え、今すぐ改善できるアクションを網羅しています。

PageSpeed Insights概要とLighthouse評価基準
1. スコア算出の仕組み（フィールドデータ vs ラボデータ）
2. Performance→Accessibilityなど評価カテゴリの概要
画像フォーマットの次世代化でスコア向上
未使用CSS/JSの削減とCritical CSS活用
レンダリングブロッキングリソース排除
フォント表示を最適化する先行読み込み設定
サーバー応答時間短縮（TTFB改善）
その他のLighthouseパフォーマンス項目
まとめ

PageSpeed Insights概要とLighthouse評価基準

結論： PageSpeed Insightsは、ラボデータ（Lighthouse）とフィールドデータ（実ユーザー計測）の双方を評価し、スコア化します。高スコア獲得には双方の最適化が不可欠です。

スコア算出の仕組み（フィールドデータ vs ラボデータ）

フィールドデータ（CrUX）:

実際のユーザー体験をもとに計測
Largest Contentful Paint（LCP）、First Input Delay（FID）、Cumulative Layout Shift（CLS）を中心に評価

ラボデータ（Lighthouse）:

制御された環境下でのシミュレーション結果
Performanceカテゴリでスコア化され、診断結果に具体的な改善提案を表示

具体例：あるECサイトでLCPが3.5秒の場合、ラボデータでは「遅い」と判定される一方、フィールドデータで改善傾向が見られれば総合スコアは70〜80点にとどまるケースがあります。両者のギャップを埋めることが、90点以上達成への第一歩です。

Performance→Accessibilityなど評価カテゴリの概要

Performance：読み込み速度やレンダリング効率をチェック
Accessibility：ARIA属性やコントラスト比を評価
Best Practices：HTTPS適用や画像サイズ最適化など基本設定
SEO：メタタグの適切性や構造化データの実装
PWA：オフライン機能やService Workerの設定状況

各カテゴリのうち、本記事では特にPerformanceにフォーカスし、主にLighthouseでのスコア改善につながる以下の章で深掘りします。

画像フォーマットの次世代化でスコア向上

結論： 画像をWebPやJPEG2000など次世代フォーマットに変換することで、ファイルサイズを大幅に削減でき、LCPの改善に直結します。

理由：

従来のJPEG/PNGと比べ、WebPは最大30～40％、JPEG2000はさらに最適化率が高く、同品質でより小さな容量を実現。
ブラウザが大きな画像ファイルを読み込む際、ネットワーク帯域を圧迫し、レンダリング待ち時間が増加。

具体例：

プラグイン導入
– 「EWWW Image Optimizer」：画像アップロード時に自動でWebP変換し、元ファイルと同時に出力可能。
– 「WebP Converter for Media」：既存画像にも一括変換機能を提供。

functions.phpを使った手動リダイレクト設定

add_filter('wp_get_attachment_url', function($url) {
  if(strpos($_SERVER['HTTP_ACCEPT'], 'image/webp') !== false) {
    return str_replace(['.jpg','.png'], ['.webp','.webp'], $url);
  }
  return $url;
});

画質とサイズバランス
– TinyPNGやImageOptimなどの外部ツールを使い、画質劣化を感じさせない最適化を実施。
– 大きすぎる画像は表示領域に合わせてレスポンシブ画像（srcset属性）を活用し、無駄な帯域浪費を防止。

注意点：

一部の古いブラウザではWebPに非対応なため、元のJPEG/PNGも併存させるフォールバック設定が必要。
CDN経由で配信する場合、フォーマットごとのキャッシュ設定を正確に行い、古いバージョンが残らないようPurging戦略を明確化。

未使用CSS/JSの削減とCritical CSS活用

結論： 不要なスタイルやスクリプトを削除し、Critical CSSをページヘッダーに埋め込むことで、初回ペイントを高速化し、Performanceスコアを大きく改善できます。

理由：

ページ読み込み時にブラウザは全CSS/JSの下載完了を待ってからレンダリングを開始。未使用のコードが多いほど待機時間が増大。
Critical CSSは「最初に画面に表示される部分」の最低限のスタイルを抽出し、先読みする手法。

具体例：

不要コードの抽出＆除去
– Chrome DevTools→Coverageパネルで使用率の低いCSS/JSを特定し、テーマやプラグイン側で排除。
– 子テーマのstyle.cssに直接コピペされている未使用スタイルは、整理して別ファイルに分離。
Critical CSS生成
```
npx critical https://example.com --width 1300 --height 900 --inline --minify --extract
```
– 生成されたCSSを<head>内に<style>タグで埋め込み、残りのCSSはmedia="print"やdefer属性で後回し読み込み。
自動挿入プラグイン
– 「Autoptimize」：Critical CSS抽出機能を有効化し、自動インライン化。
– 「WP Rocket」：Advanced RulesでCritical CSSを登録することで、プラグインが自動処理。

注意点：

ページごとに異なるレイアウトの場合、Critical CSSは都度生成・管理が必要。共通部分だけでは十分な効果が得られない可能性あり。
自動生成ツールは抽出ミスでレイアウト崩れを起こすケースがあるため、本番適用前に必ずデザイン確認を実施。

レンダリングブロッキングリソース排除

結論： CSS・JavaScriptを非同期または遅延読み込みに設定し、ページの初期レンダリングを妨げるリソースを排除することで、First Contentful Paint（FCP）とTime to Interactive（TTI）を大幅に短縮できます。

理由：

ブラウザはデフォルトで<head>内のCSSと同期的な<script>タグを検出すると、下載完了まで描画を一時停止。
レンダリング後に必要なスクリプト・スタイル以外を後回しにすることで、主要コンテンツが素早く表示され、ユーザー体験が向上。

具体例：

CSS の非同期読み込み

<link rel="preload" as="style" href="style.css" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="style.css"></noscript>

JavaScript の遅延読み込み

<script src="script.js" defer></script>
<script src="script.js" async></script>

プラグインによる制御
– Autoptimize：JS/CSSを結合し、オプションでdeferやasyncを指定可能。
– WP Rocket：「レンダリングブロッキングファイルの排除」機能をオンにすると、自動で属性を付与。

注意点： async属性は実行順序を保証しないため、依存関係があるスクリプトには向かない。Critical CSS と組み合わせ、主要なスタイルのみ先読みし、残りを遅延読み込みする設計が効果的。

フォント表示を最適化する先行読み込み設定

結論： Webフォントをプリロードし、font-displayプロパティを適切に設定することで、FOIT（Flash of Invisible Text）やFOUT（Flash of Unstyled Text）を防ぎ、CLSの改善につながります。

理由：

フォント読み込みの遅延により、テキストが不自然に非表示または別フォントでレンダリングされ、視覚的なレイアウトシフトが発生。
font-display: swapなどを使うと、標準フォントで一旦表示→Webフォントに切り替わるため、無駄な空白を防止。

具体例：

プリロード設定

<link rel="preload" href="/fonts/your-font.woff2" as="font" type="font/woff2" crossorigin>

CSSでのfont-display指定

@font-face {
  font-family: 'YourFont';
  src: url('/fonts/your-font.woff2') format('woff2');
  font-display: swap;
}

プラグイン紹介
– OMGF：Google Fontsをホストし直し、プリロードタグを自動生成。
– Pre* Party Resource Hints：任意リソースを簡単にプリロード／プリフェッチ可能。

注意点：

フォントファイルを自前サーバーでホスティングする場合、crossorigin属性を忘れずに設定。
プリロードしすぎるとネットワーク帯域を圧迫するため、主要文字セットのみ対象にする。

サーバー応答時間短縮（TTFB改善）

結論： サーバーの初期応答時間（Time To First Byte, TTFB）を短縮することで、Lighthouseの「Server Response Times (TTFB)」項目のスコアが向上し、全体的なパフォーマンス改善に大きく寄与します。

理由：

TTFBが遅いと、ブラウザはコンテンツ受信開始まで長時間待機し、その後のレンダリングやスクリプト実行が全て後ろ倒しに。
高速なサーバー応答は、Critical CSSやDeferred JSの効果を最大化し、レンダリング全体を加速する。

具体例：

サーバーキャッシュの活用
– RedisやMemcachedでObject Cacheを構築。
– WP Super CacheやWP RocketでPage Cacheを有効化し、静的HTMLを配信。

OPcache設定

opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.revalidate_freq=2

CDN導入
– CloudflareやAmazon CloudFrontを利用し、静的リソースをエッジで配信。
– TLS 1.3対応、OCSPステープリング設定でSSLハンドシェイクを最適化。

注意点：

キャッシュのTTLを適切に設定し、更新時に自動クリアを行う。
CDNとオリジンサーバー間のヘルスチェックやOrigin Shieldを活用し、オリジン負荷を軽減。

その他のLighthouseパフォーマンス項目

結論： HTTP/2やTLS最適化、圧縮設定などの細かいチューニングを積み重ねることで、パフォーマンススコア全体を押し上げることが可能です。

理由： Lighthouseは多数のチェック項目を評価しているため、個別改善を積み重ねることが総合スコア向上につながります。

具体例：

HTTP/2 有効化
– Apacheのmod_http2、Nginxのhttp2設定でプロトコルを切り替え。
– マルチプレクスにより同一コネクションで複数リクエストを並列処理。
TLS最適化
– OpenSSL 1.1.1以降でTLS 1.3有効化。
– OCSPステープリングおよびSession Resumptionでハンドシェイク時間を短縮。
GZIP/Brotli圧縮
– NginxのbrotliモジュールまたはApacheのmod_brotliで圧縮を適用。
– テキスト系リソースをBrotli、その他をGZIPで圧縮。
キャッシュヘッダー設定
– 静的リソースにCache-Control: public, max-age=31536000, immutable。
– HTMLにはCache-Control: no-cacheを設定し、常に最新配信を維持。
リソースの最小化
– CSS/JSのMinify、HTMLのWhitespace Removalを自動化（Autoptimizeなど）。
– 本番環境ではソースマップを無効化。

注意点： 圧縮率とCPU負荷のバランス調整を行い、サーバー負荷を監視しながら最適値を設定してください。

まとめ

本記事で紹介した画像の次世代化、未使用コード削減＆Critical CSS、レンダリングブロック排除、フォント最適化、TTFB改善、HTTP/2・TLS・圧縮の各施策を体系的に実施すれば、PageSpeed Insightsで90点以上の獲得が可能です。ユーザー体験を向上させ、検索エンジンでの評価を高めるため、ぜひ今すぐ取り組んでみてください。