復習4日目_20251126
Day 4：表示速度UP（高速化）
ゴール： サイトを軽量化して表示スピードを改善
やること：
-
PageSpeed Insights でスコア確認（モバイル/PC）
-
キャッシュ設定の検討（プラグイン or Nginx）
-
画像の圧縮・リサイズ・lazy-load確認
-
不要プラグイン・重いJS/CSSの洗い出し
① PageSpeed Insights で現状スコアを測る
↓https://pagespeed.web.dev/にアクセス
↓サイトのURLをいれ、測定
結論：モバイルの最大課題は LCP（Largest Contentful Paint）= 5.8秒
PCは超高速なので問題なし。モバイルだけがボトルネックになっている
携帯電話
First Contentful Paint
Speed Index
First Contentful Paint
最大問題：LCP 5.8秒（= 記事のメイン画像 or ヒーロー画像が重い）
LCP は通常 トップにある大きな画像 が原因になる。
例：記事のアイキャッチ、スライダー、ヘッダーの大きい画像、背景の大きい画像、カルーセル
✔ よくあるパターン
画像サイズが大きすぎる（2000px以上）、圧縮されていない、WebP になってない、lazy-load が無効（LCP候補には lazy-load かけてはいけない場合あり）、hero image だけ critical（優先読み込み）にすべき
アイキャッチ画像（サムネイル）が大きすぎた。
512*512ピクセル
対策は、
- サムネイル画像サイズを「300px前後」にする（必須）（手作業 or プラグイン）
- テーマのサムネイル読み込みを “medium” に変更
- 最初の画像だけ lazy-load を無効化
全部やるのがよいのですが、今夜は１ページ目も３つの画像を変更した。
300px, jpeg, メタ情報の削除を行った。
📊 パフォーマンス比較表
| 指標 | 画像変更前（携帯電話） | 画像変更後（携帯電話） | 差分 |
|---|---|---|---|
| First Contentful Paint (FCP) | 0.9 秒 | 0.9 秒 | ±0.0 秒（同じ） |
| Largest Contentful Paint (LCP) | 5.8 秒 | 1.7 秒 | -4.1 秒（Bが圧倒的に速い） |
| Total Blocking Time (TBT) | 0 ms | 0 ms | ±0 ms（同じ） |
| Cumulative Layout Shift (CLS) | 0 | 0 | ±0（同じ） |
| Speed Index | 2.4 秒 | 3.7 秒 | +1.3 秒（Aのほうが速い） |
**Speed Index（スピードインデックス）**は、
ページ全体が「どれくらいの割合で視覚的に完成していくか」を数値化した指標
Speed Index は ブラウザやネットワーク環境の影響を大きく受ける。実は仕事の関係で、作業前と作業後で、場所も時間も違う。
| 問題 | 影響 | Speed Indexとの関係 |
|---|---|---|
| レンダリングをブロックするCSS/JS | 560ms の遅延 | Speed Index に直結 |
| 強制リフロー | レイアウト描画を何度もやり直し | Speed Index の低下 |
| 依存ツリーが長い | 初期表示までに必要なファイル多い | Speed Index が悪化 |
今回の結果を見る限り、Speed Index が悪かったのは 画像ではなく CSS/JS の描画ブロックとリフロー が原因
つまり、画像を小さくしたのに Speed Index が悪化したのは正常な現象
パフォーマンスは９８なので良しとしたいが、、、
対策は？
| 優先度 | 内容 | 所要時間 | やる理由（Speed Index への効果） | 方法（具体的作業） |
|---|---|---|---|---|
| ⭐⭐⭐⭐⭐ | CSS の非同期読み込み | 10分 | CSS が描画をブロック → Speed Index が悪化 | WP プラグインで 「CSS最適化」オン（後述） |
| ⭐⭐⭐⭐ | JavaScript の defer / 遅延実行 | 10分 | JS が初期描画を止める → Speed Index に大ダメージ | プラグインで JS遅延（delay）をオン |
| ⭐⭐⭐⭐ | Google Fonts の最適化（display=swap） | 5分 | Fonts 読み込み待ちで視覚進行が遅れる | プラグインで フォント最適化オン |
| ⭐⭐⭐ | Critical CSS の自動生成 | 10分 | ファーストビューのCSSだけ先読みできる | LSCacheならワンクリックで自動生成 |
| ⭐⭐ | LazyLoad設定の見直し（上の画像は lazy にしない） | 5分 | LCPに影響し Speed Index の計算にも響く | LazyLoad で ファーストビュー画像を除外 |
| ⭐ | 不要なプラグインの停止 | 5分 | JS/CSSを減らすことで描画ブロック減 | 使ってないプラグインを停止 |
✅ Enable Cache（キャッシュ有効） → ON
✅ Cache Mobile（スマホキャッシュ） → ON
✅ Browser Cache（ブラウザキャッシュ） → ON
ブラウザキャッシュは、ブラウザというタブにある。
③CSS / JS の最適化
↓LiteSpeed Cache → ページの最適化
↓タブ CSS設定
-
CSS圧縮 → ON
-
CSS結合 → ON
-
UCSS生成 → ON
-
UCSSインライン → ON
-
CSS非同期読み込み → ON
④JavaScript 最適化
↓JS 設定
- JS 圧縮 → ON
→ JS を軽くして読み込み速度UP
- JS 結合 → ON
→ 複数の JS をまとめてリクエスト削減
- JS Deferred → ON（重要）
→ JS の読み込みで “描画が止まらなくなる”
→ Speed Index 激改善
- Delay JS（JS 遅延読み込み） → ON
⑤画像の最適化設定（LazyLoad・圧縮）
↓ 画像最適化設定
↓ 画像最適化設定のタブ
ちょっとわかりにくいので、表にした。
| やった作業 | 詳細設定内容 | Speed Index への効果 | LCP（最大描画画像）への効果 | 全体効果の説明 |
|---|---|---|---|---|
| ① LazyLoad（画像遅延読み込み）をON | 画面外の画像を読み込み遅延 | ⭐⭐ Speed Index 改善（画面に見える部分の描画が軽くなる） | △ LCPには直接影響しない（ファーストビュー画像は除外される） | 初期に読み込む画像数が激減 → 画面の埋まりが早くなり Speed Index が上がる |
| ② 次世代フォーマット（WebP）をON | JPEG/PNG → WebP生成 | ⭐ Speed Index わずかに改善（描画が軽量化） | ⭐⭐⭐ LCP 改善に大きく効く（主要画像の軽量化） | ファーストビューの大きな画像が軽くなる → LCPが短縮しスコア改善 |
| ③ “WebP Extra srcset” をON | WordPress の全サイズ（サムネ/大/中/retina）をWebP化 | ⭐ Speed Index わずかに改善 | ⭐⭐ LCPさらに改善 | 各解像度の画像がWebPに置き換わる → 4G/低速環境のレンダリングが高速化 |
| ④ 可逆最適化（ロスレス圧縮）ON | 画質そのままの軽量化 | △ Speed Index に微影響 | △ LCP に微影響 | 全画像が少し軽くなる → 全体の体感速度が微改善 |
| ⑤ オリジナル画像の最適化ON | 元画像の軽量化（画質少し下げる） | △ Speed Index に微影響 | ⭐ LCP 改善に効く（小さくなるため） | 主要画像の容量が少し下がるためレンダリングが早くなる |
で、今日の結果
| 指標 | 対策前（画像変更後） | 対策後（CSS/JS最適化 + LazyLoad + WebP） | 差分 | 評価 |
|---|---|---|---|---|
| FCP（最初の文字が出る） | 0.9秒 | 1.1秒 | +0.2秒（やや悪化） | ほぼ誤差。CSS非同期化の影響で遅く見える |
| LCP（最大画像の表示） | 1.7秒 | 1.9秒 | +0.2秒（誤差レベル） | 実質ほぼ同じ。WebPの効果は出ている |
| TBT（JSのブロック時間） | 0ms | 0ms | ±0 | 完璧な状態 |
| CLS（レイアウトずれ） | 0 | 0 | ±0 | 完璧 |
| Speed Index（画面の埋まり速度） | 3.7秒 | 3.8秒 | +0.1秒（変化なし） | 想定通り。構造的にSpeed Indexは上がりにくい |
ありゃ、あんまりかわらない。
デスクトップでは百点だからいいかな。
👍 今日の最終まとめ
今日実施した CSS/JS最適化・画像最適化 は Speed Index の前提条件
Speed Index の本当の改善 は “ファーストビューの構造” がカギ
上級編のやることは 核心対策 なので、時間がある日にやると効果が大きい