この記事のポイント
- モバイルのPerformanceは60、LCPは7.2秒だった
- Total Blocking TimeとCLSはともに良好な0だった
- 最優先候補はレンダリングを止めるリクエストの約2.1秒削減だ
サムネイルはイメージ写真。写真の配布元：Unsplash（利用許諾）。本文の画面は実際の操作時に撮影した。
検証条件：2026年10月6日21時9分、PageSpeed InsightsでRyXeonトップページをモバイル測定。Moto G Power、低速4G、Lighthouse 13.5.0、HeadlessChromium 153.0.8010.36のラボ条件で実行した。実ユーザーデータは「データがありません」だった。
結果はPerformance 60、Accessibility 100、Best Practices 96、SEO 100だった。主要指標はFCP 5.4秒、LCP 7.2秒、Total Blocking Time 0ミリ秒、CLS 0、Speed Index 7.2秒である。
操作を止める重いJavaScriptやレイアウトの揺れより、最初の見た目を作るまでの待ち時間が現在の弱点である。TBTとCLSが0なのにPerformanceが60なのは、FCPとLCPの遅さが効いているためだ。
操作手順
- PageSpeed Insightsを開く。
- 公開ページのURLを入力して「分析」を押す。
- 携帯電話とデスクトップのタブを分けて見る。
- 総合点の下にあるFCP、LCP、TBT、CLSを記録する。
- 「インサイト」の推定削減時間が大きい項目から、実装と効果を確認する。
今回の改善順
最上位の候補は「レンダリングをブロックしているリクエスト」で、推定削減時間は2,100ミリ秒だった。次に画像配信の改善173KiB、未使用CSSの削減164KiB、キャッシュ59KiBが続く。まず初期表示に不要なCSSやフォント読み込みを遅らせ、ファーストビュー画像を適切な寸法・形式へ整えるのが筋である。
一方、未使用CSSを一括削除するだけではCocoonの部品表示を壊す恐れがある。トップページで実際に読み込むテーマ、スキン、ブロック、プラグインの各CSSを分類し、使っていない資産の読み込みを止める方が追跡しやすい。スコアは測定ごとに動くため、変更前後を同じ条件で複数回測り、LCPの中央値で判断したい。
コメント