ページスピードインサイトで高得点を目指す際のポイントを見ていこう

どうも、職業エンジニアです。今日はページスピードインサイトで遊ぼう！的なことを書いて行こうと思います。

ページスピードインサイトとは？

Googleが提供してるWEBページの性能測定ツールです。調べたいページのURLを入力するだけで、モバイルとPCそれぞれの表示速度を100点満点のスコア形式で評価することができます。

評価項目について

PageSpeed Insightsでスコア（0〜100点）を算出する際に使われている主要な評価項目（ラボデータ）は、主に以下の5つです。

それぞれの項目に「スコアへの重み（配分比率）」があり、合計100点満点で採点されます。

FCP、CLS、TBTあたりは工夫することで対処しやすい部分なのかなって思います。たぶん。

項目ごとの改善方法

次に各項目の改善方法についてみていきましょう。

1. FCPの改善

ブラウザがHTMLやCSSを読み込み始めてから、最初の要素を描画するまでのブロック要因を削ります。

• レンダリングをブロックするリソースの排除: ファーストビューに不要なCSSやJavaScriptは後回し（async / defer）にし、最重要CSS（Critical CSS）のみインライン化します。非同期読み込みってやつですね。Googleアナリティクスなどの描画に影響しない外部リソース、ページ下部に置きがちなコメントエリアやシェアボタンなどは遅らせても良いでしょう。

• サーバー応答時間（TTFB）の短縮: サーバーサイドキャッシュの導入や、CDN（Cloudflare等）のエッジキャッシュを活用してHTMLの初期返却を高速化します。ただ、サーバーキャッシュは正しく設定しないと様々なリスクがあります。特に会員制サイトとの相性は良くない（難しい！）ので注意。

• フォント表示の高速化: Webフォントに font-display: swap; を設定し、フォント読み込み待ちによるテキスト非表示（FOIT）を防ぎます。日本語フォントは特に文字数が多くファイルサイズが大きくなるので、気になるようであればシステムフォントにしてしまった方が良いです。

2. LCPの改善

ファーストビューで最も面積を占めるヒーロー画像やタイトルテキストを最速で描画させます。

• 主役画像の最適化と形式変換: 次世代フォーマット（WebP / AVIF）の採用や、適切なリサイズ・圧縮を行います。圧縮用のウェブツールが多く存在するので、やや面倒ですが簡単にできます。

• メイン要素の優先読み込み: LCPとなるヒーロー画像には loading="lazy" を絶対に付けず、<link rel="preload"> や fetchpriority="high" を指定して最優先でリクエストさせます。これはちょっと難しいので、後回しでいいと思います。

• CDN配信とアセットキャッシュ: 画像やメディアファイルをCDNから配信し、HTTP/2またはHTTP/3で並列転送します。Cloudflareを導入しよう！

3. TBT（操作不能時間）の改善

メインスレッドを長時間専有（Long Task: 50ms以上）するJavaScriptの負荷を分散・削減します。

• 不要なコードの削除とコードスニペット: 未使用のJSライブラリを削除し、ページごとに必要なスクリプトだけを動的インポート（Dynamic Import）で分割読み込みします。事故りやすいので基本的には後回し推奨です。

• サードパーティスクリプトの遅延・整理: タグマネージャー、アナリティクス、広告タグ、SNS埋め込みなどの読み込みをユーザー操作後まで遅延させるか、Web Worker（Partytown等）へオフロードします。「そもそもこのコンテンツ必要かな？」という視点で見るのがラクだと思います。

• 重い処理の分割: 長い処理ループを requestIdleCallback や setTimeout 等で細切れにしてメインスレッドを開放します。これも事故りやすいので基本的には後回し推奨です。

4. CLS（画面のガタつき）の改善

後から非同期で読み込まれる要素によってコンテンツが押し出される現象をゼロにします。特にファーストビューは気にした方がいいかなって感じです。

• 画像・動画へのアスペクト比指定: すべての <img> や <video> に width / height 属性、またはCSSで aspect-ratio を明示し、ロード前の領域を確保します。

• 動的コンテンツ・広告枠のサイズ事前確保: 広告バナーや動的ウィジェットの親要素に min-height を設定し、読み込み完了時のレイアウト跳ね上がりを防ぎます。

• フォント切り替え時のズレ抑制: Webフォントと代替システムフォントのサイズ比率をCSSの size-adjust 等で合わせ、切り替わり時の文字幅変化による段落ズレを最小化します。

ここで大きく減点されることはあまりないのかなあ、という所感。

5. SI（視覚的な完成の早さ）の改善

ファーストビュー全体のコンテンツが段階的・安定的にレンダリングされていく速度を高めます。ここまでのポイントを踏まえて的な感じ。

• FCPとLCPの改善を徹底する: SIは画面全体の視覚的進行度を積分した指標のため、FCP・LCP対策を行うことで自然とスコアが連動して向上します。

• Above the Fold（スクロール不要領域）の無駄を省く: ファーストビュー外の画像やコンポーネントには徹底して loading="lazy" や遅延ハイドレーションを適用します。これもFCPでやったやつですね。

完璧を求めすぎるのは止めた方がいい！

ここまで対策方法なんかを書いていきましたが、完璧を求めるのはあまりおすすめしないよっていうのが本音です。

というのも、画像の圧縮やCDNの利用などは比較的表示に影響ない範囲で実施できるので安全ですが、遅延読み込みなんかは遅延する要素をミスるとページ操作が上手いことできなかったり、ファーストビューで表示すべき要素が表示されなかったりみたいな事が起こりうるからです。

手っ取り早く安全にやりたいのであれば、コンテンツを整理して不要なリソースをまるっと削除するのが良いでしょう。

このブログのスコア

このブログは結構外部リソースの読み込みが多く、そこがボトルネックになりがちです。

• Googleアドセンス
• コメント欄（cusdisセルフホスト）
• いいね数の取得&更新API（Cloudflare workersで実装）
• 人気記事ランキング（Cloudflare workersで実装）
• WEBフォント

なのでこの辺りを遅延読み込みしたり、キャッシュしたりする工夫をしています。

スコアはこんな感じになっています。

一時期めちゃめちゃスコアにこだわって、ページスピードインサイトで「修正した方がいい！」って言われた箇所を片っ端から対応していったので、かなり高スコアとなっています！

なお、これでも妥協している部分は妥協しています。たとえば、以下のように「自サイトの設定だけではどうしようもないもの」なんかもあったりします（外部リソース）。

一応スクリプトをセルフホストしてキャッシュTTLを自前で設定すれば改善はするんですが、そうなるとスクリプトのアップデートを常に自分で追わなければならなくなります。

それはさすがに運用負荷的にダルいので、目を瞑ろうみたいな感じ。他にも画像サイズをもっと改善できるよ！みたいな項目も残ってたりしますが、ここをガチろうとすると恐らく条件分岐が大変なことになるので、スルーしています。

パフォーマンスの目標的にはトップページ、記事ページ、一覧ページなどがそれぞれ70点くらい取れていれば充分だと思うので、まずはそこを目指してチューニングしていくのが良いのかなと思っています。100点は基本無理なので止めときましょう。90点から100点になったところで、正直ユーザー体験はあんまり変わりません。どっちも早いので。

他にできることがあるとすれば

実はいうとクライアント側のコードがボトルネックになることはあんまりないと思っています。実務で性能を意識するのはだいたいの場合バックエンド側なんですよね。もっと言ってしまうとDB設計、SQL設計、チューニングが最も時間を使う部分だと思います。

今回はCMSを利用しているものあり、バックエンドには一切手を入れていません。もしかすると画面表示に不要なデータを取ってきたりしている可能性もありますが、ここに関してはCMSが適切なDB設計、クエリを投げてくれているだろうと思うことにしてます。なによりいじっちゃうと今後のアップデート時に壊れちゃうリスクもありますし。

クライアントで意識するのはAPIを投げる単位とかになるんだろうけど、ここもまあCMSが用意してくれているエンドポイントが適切であれば、問題にはならないからなあ。

強いて言えば、今回は外部リソースとして自前のエンドポイントが3つほどあるので、ここに関してはパフォーマンスを意識した設計にしているつもりです。単発取得用のエンドポイントとリスト取得用のエンドポイントを分離したりですね。

まあでも、ブログサイトで考えることはそんなにないよなあ。たぶんCMSそのままでも結構スコアでますからね。

最後に

このサイトはGhostで運用していますが、Ghostはデフォルトでもかなり高速なCMSです。たぶんWordPressでスコアを出そうとすると、かなり苦労&工夫が要るはず。とはいえ、機能性的にはWordPressの方が上でしょう。

できることが多ければそのぶんパフォーマンスは落ちるので、自分が求めている機能とパフォーマンスのバランスを考えてCMSを選ぶのが大事なんだと思います。