PageSpeed Insightsの指摘を実際に直す―修正前後で表示速度とCore Web Vitalsはどう変わるか

PageSpeed InsightsでPerformance 80だったゆまラボTOPを、Pagefindの遅延ロードとヒーロー画像のレスポンシブ配信改善で修正。再計測ではPerformance 96、FCP 1.5秒、LCP 2.7秒、Speed Index 1.5秒になった。

公開：
PageSpeed Insightsの指摘を実際に直す―修正前後で表示速度とCore Web Vitalsはどう変わるか

PageSpeed InsightsでPerformanceが80になり、LCPも4.0秒。改善項目には画像配信やレンダリングブロックが並んでいました。どこから手を付けると実測値が変わるのか、画面だけでは判断しにくい状態です。

ゆまラボでは、TOPページで出ていた指摘を確認し、Pagefindの初期ロードとヒーロー画像の配信方法を実際に修正しました。公開後に同じMobile条件で再計測すると、Performanceは96、LCPは2.7秒、Speed Indexは1.5秒まで変化しています。

この記事では、修正前の指摘、コード側で変更した内容、修正後の数値、最後まで残った指摘まで、実際の結果を順に記録します。

PageSpeed InsightsでPerformance 80、LCP 4.0秒#

前の記事では、表示速度を4ツールで実測比較し、測定条件によって結果が変わることを確認した。今回はPageSpeed Insightsの指摘から修正対象を選び、実装後に再計測する。

修正前の計測は2026年9月25日14:43 JST。対象はhttps://bringain.com/のTOPページで、携帯電話、Moto G Powerエミュレーション、低速4G、Lighthouse 13.5.0という条件だった。

修正前のPageSpeed InsightsでPerformance 80、FCP 2.6秒、LCP 4.0秒と表示された画面

修正前のMobile計測。Performance 80、LCP 4.0秒。

修正前の主な値は、Performance 80、FCP 2.6秒、LCP 4.0秒、TBT 80ミリ秒、CLS 0、Speed Index 4.8秒。ユーザー補助は96、おすすめの方法とSEOは100だった。

PageSpeed Insights上部の「実際のユーザーの環境で評価する」には「データがありません」と表示されていた。GoogleのPageSpeed Insights公式説明では、PageSpeed InsightsはCrUXの実ユーザーデータとLighthouseのラボデータを扱う。今回は実ユーザーデータが表示されていないため、修正前後の比較はLighthouse側のラボ値を使う。

実際のユーザーの環境で評価する欄にデータがありませんと表示された修正前の画面

修正前の実ユーザーデータ欄。今回はデータなし。

Core Web Vitalsの実ユーザーデータが修正直後に改善したと判断する材料は今回ない。この記事で比較するLCPやCLSは、PageSpeed Insightsのラボ計測で得られた値として扱う。

修正前に出ていた指摘を確認#

修正前のレポートで目立ったのは、ヒーロー画像、Pagefind、レンダリングブロックの3点だった。

「画像配信を改善する」では、TOPのヒーロー画像が36.7 KiBで配信され、推定20.9 KiB削減できると表示されていた。

修正前のPageSpeed Insightsでヒーロー画像に約21KiBの削減見込みが表示された画面

修正前。ヒーロー画像は36.7 KiB、推定削減可能サイズは20.9 KiB。

HTMLを見ると、この画像にはすでにsrcset、loading="eager"、fetchpriority="high"、width、heightが付いていた。属性を追加する作業より、ブラウザがどの画像候補を選ぶかを確認する必要がある。

レンダリングブロックでは、Pagefindのpagefind-component-ui.cssが約8.2 KiB含まれていた。ほかにTOP固有CSSとSiteLayoutのCSSが並び、合計14.4 KiB、継続時間1,120ミリ秒と表示されている。

修正前のレンダリングブロック一覧にPagefind CSSが含まれている画面

修正前。Pagefind CSSを含むレンダリングブロックが14.4 KiB。

ネットワーク依存関係ツリーには、pagefind-component-ui.cssに加えてpagefind-component-ui.js約39.5 KiBも入っていた。検索を開いていないTOP表示の段階で、Pagefind関連リソースが初期読み込みへ入っている状態だった。

修正前のネットワーク依存関係ツリーにPagefind CSSとJavaScriptが表示されている画面

修正前。Pagefind CSSとJavaScriptが初期ネットワーク依存関係に入っている。

Googleタグの未使用JavaScriptやCloudflare Web Analyticsのキャッシュ期間も指摘されていた。今回はアクセス計測の仕様を変えず、サイト側で直接変更できるPagefindとヒーロー画像に対象を絞った。

Pagefindを検索時だけ読み込む#

最初に手を入れたのはPagefind。修正前は検索UI用のCSSとJavaScriptが初期表示から読み込まれていたため、検索を使わない閲覧でもネットワーク依存関係に入る。

実装では、初期HTMLからPagefindのCSSとJavaScriptの直接読み込みを外し、検索トリガーを操作した時点で必要なリソースを読み込む方式へ変更した。既存の検索UI、PC表示、スマホ表示、サイドバー検索はそのまま維持している。

今回変更したファイルは7件。

  • scripts/verify.mjs
  • src/components/BaseHead.astro
  • src/components/PagefindSearchTrigger.astro
  • src/components/SiteHeader.astro
  • src/components/SiteSidebar.astro
  • src/pages/index.astro
  • src/styles/global.css

検索ショートカットのCtrl / Cmd + Kは作業前から存在するPagefind標準機能だった。Pagefindのpagefind-modal-trigger公式仕様では、既定のショートカットがmod+kで、Windows/LinuxではCtrl、MacではCmdとして動く。遅延ロード後もこの動作を維持した。

実装後はnpm run buildが成功し、102ページを生成。Pagefindは87ページをインデックスし、内部リンク4,309件、壊れたリンク0件を確認した。node scripts/verify.mjsもPASS。生成したTOP HTMLでは、初期Pagefind CSS/JS要求が0件になっている。

ヒーロー画像の候補を960wまでに変更#

もう一つの対象がTOPのヒーロー画像。修正前は最大1200wまで候補があり、Mobileの表示幅に対して大きい画像が選ばれていた。

修正後のsrcsetは360 / 480 / 720 / 960w。あわせてsizesを現在のレイアウト幅に合わせた。既存のloading="eager"、fetchpriority="high"、width、heightは維持している。

画像自体を単純に1サイズへ縮小すると、PC表示側で必要な解像度まで失う可能性がある。今回は複数候補を残し、表示幅に応じてブラウザが選択できる構成にした。

本番反映後に同じMobile条件で再計測#

本番反映後、2026年9月25日15:32 JSTにPageSpeed Insightsで再計測した。対象は同じTOPページで、携帯電話タブを使用している。

修正後のPageSpeed InsightsでPerformance 96と表示された画面

修正後。Performanceは96。

修正後はPerformance 96。ユーザー補助95、おすすめの方法100、SEO 100となった。

修正後のFCP 1.5秒、LCP 2.7秒、TBT 40ミリ秒、CLS 0、Speed Index 1.5秒

修正後。FCP 1.5秒、LCP 2.7秒、TBT 40ミリ秒、CLS 0、Speed Index 1.5秒。

前後を並べると差が分かりやすい。

横にスクロールできます
指標修正前修正後変化
Performance8096+16
FCP2.6秒1.5秒-1.1秒
LCP4.0秒2.7秒-1.3秒
TBT80ms40ms-40ms
CLS00変化なし
Speed Index4.8秒1.5秒-3.3秒

Performanceは80から96へ上がった。FCPは1.1秒、LCPは1.3秒、Speed Indexは3.3秒短縮。TBTも80ミリ秒から40ミリ秒になった。CLSは0を維持している。

Lighthouseの公式ドキュメントでは、Performanceスコアは計測条件やネットワーク状態などで変動すると説明されている。今回の数値は、9月25日に行った修正前後の実測記録として扱う。

Pagefindが初期依存関係から消えた#

再計測で最も分かりやすかった変化はPagefindだった。

修正後のレンダリングブロック一覧には、pagefind-component-ui.cssが出ていない。対象はSiteLayoutとTOP固有CSSだけになり、合計は6.3 KiB、継続時間600ミリ秒まで減った。

修正後のレンダリングブロック一覧からPagefind CSSが消えた画面

修正後。Pagefind CSSが一覧から消え、6.3 KiBまで減少。

修正前は14.4 KiB、1,120ミリ秒だったため、初期レンダリングへ入るCSS量と継続時間の両方が減っている。

ネットワーク依存関係ツリーからも、PagefindのCSSとJavaScriptが消えた。

修正後のネットワーク依存関係ツリーからPagefind CSSとJavaScriptが消えた画面

修正後。初期ネットワーク依存関係からPagefind関連リソースが消えた。

検索機能は残したまま、必要になるタイミングまで読み込みを遅らせた結果だ。検索ボタンを操作するとPagefindが読み込まれ、PC・スマホとも検索UIが開く。Astroで検索した確認では87件の結果が表示され、読み込み後のCtrl / Cmd + Kも動作した。

ヒーロー画像は軽くなったが指摘は残った#

ヒーロー画像の転送サイズは、36.7 KiBから27.5 KiBへ減った。約9.2 KiBの削減になる。

修正後も画像配信の改善指摘が残り、ヒーロー画像が27.5KiBと表示された画面

修正後。ヒーロー画像は27.5 KiBまで減ったが、画像配信の指摘は残った。

一方、PageSpeed Insightsの「画像配信を改善する」は残っている。推定削減可能サイズも20.9 KiBから20.6 KiBで、大きな変化はなかった。

修正後のMobileでは720×412の画像が選択され、実際の表示は360×206。候補の上限を960wへ下げ、転送量は減ったものの、Mobileではさらに小さい候補を選ばせる余地が残っている。

今回はこの時点で追加変更を止めた。Performanceが96まで上がり、Pagefind側の初期読み込みも解消している。画像側は「転送量は減った」「指摘は残った」という実測結果をそのまま記録する。

Accessibility 96から95も確認#

再計測ではユーザー補助が96から95になった。今回の変更にはヘッダー、サイドバー、検索トリガー周辺も含まれるため、git差分と検索動作を確認した。

確認では、今回の変更を原因とする明確なAccessibility回帰は特定できなかった。検索UIはPC・スマホで開き、既存のキーボード操作も維持している。修正前から「タップ ターゲットのサイズや間隔は十分な大きさではありません」という指摘も存在していた。

修正前から存在していたタップターゲットのサイズと間隔に関する指摘

修正前から確認できていたタップターゲットの指摘。

Performance改善と直接関係する修正は追加せず、Accessibility 95は今回の再計測結果として残した。

今回の結果#

今回の修正では、Pagefindの初期読み込みを検索利用時へ移し、ヒーロー画像のsrcsetとsizesを現在の表示幅に合わせた。

その結果、PageSpeed InsightsのPerformanceは80から96へ上がり、FCP 2.6秒から1.5秒、LCP 4.0秒から2.7秒、Speed Index 4.8秒から1.5秒まで変化した。PagefindのCSS/JSは初期ネットワーク依存関係から消え、レンダリングブロックも14.4 KiBから6.3 KiBへ減っている。

ヒーロー画像は36.7 KiBから27.5 KiBへ減ったが、画像配信の改善指摘は残った。指摘を0件にすることだけを目標にせず、実際にどのリソースが初期表示へ入っているか、修正後の数値がどう変わったかを確認すると、次に触る場所を判断しやすい。

参考情報#