LCPを改善 | 項目 | 状態 | |------|------| | LCP画像の優先読み込み（fetchpriority / loading="eager"） | 適用済み（8a6d5a5・Load Delay 766ms→0ms） | | 画像の最適化（WebP変換） | 適用済み（f26aea6・**転送量 -47.1%**） | | 画像サイズ過大（logo2_sp.gif） | 適用済み（0ef0d75・3406x850→436x109、-71.3%） | | オフスクリーン画像の遅延読み込み | 適用済み（18ec494・23件にloading="lazy"） | | 重複ダウンロード | 適用済み（419a758・-1件 / -35,748B） | | パブリックCDNの同一ドメイン化 | 不採用（f6a1d62＋revert・simulated -77.4%だが**observed不変**） | | recommend.js の defer化 | 不採用（2bd06b0＋revert・simulated LCP +27.9%悪化） | | PC用画像のSP配信の解消 | 不採用（33fc4bb＋revert・**observed LCP +32.4%、二峰化**） | | picture/srcset による出し分け | 該当あり（未導入が弱点。ただし本サイトはPC/SPで別HTMLを配信する設計） | | 海外サーバーからの配信 | 該当あり（jsdelivr フランクフルト492ms / code.jquery.com ニューヨーク356ms） | | 指標 | 開始時 | 完了時 | |------|--------|--------| | simulated LCP（中央値） | 1390.0 ms | 約 1308 ms | | observed LCP（中央値） | 1590.0 ms | 約 1576.5 ms | | **転送量（total）** | **4.88 MB** | **2.51 MB（-48.6%）** | LCPそのものの改善はごくわずかだが、**転送量をほぼ半減**させた。 プラクティス1は simulated LCP を **-77.4%** 改善したが、observed LCP は **+0.28%** で完全に不変だった。 lcp-planner が実装前に「observed LCP も改善すること」を採用条件として明文化していたため、 見かけ上-77%の「改善」を正しく退けることができた。 最終状態のLCP内訳: TTFB 約489ms（38%）/ Load Delay **0ms** / Load Time 約14ms / **Render Delay 約800ms（62%）** 当初「webstore.js の1.68MB同期バンドルが原因」としていたが、**実測により否定された**: - 最長RunTask長は **21.9〜23.3ms**、50ms超は **0件** - メインスレッドの総作業量は **131.8ms** のみ、bootup-time は 0.0ms - **cpuSlowdownMultiplier: 1（CPUスロットリングなし）** **真の原因は Lantern がシミュレートするネットワーク遅延（requestLatencyMs: 562.5）** であり、 LCP要素（カルーセル画像）の表示に必要な jQuery → slick → webstore.js → recommend.js という **複数オリジンにまたがる依存チェーンの段数**に依存する。 これを短縮するにはカルーセルをJSに依存せずCSS/HTMLのみで初期表示できるよう アーキテクチャを変更する必要があり、inventoryの編集では対処不可能。 プラクティス6では、早期（507ms）にリクエストされていた `logo_pc.gif`（わずか7.8KB）を 削除しただけで、**20回中10回が約1秒遅いクラスタに分裂**した。 practice-commiter が git stash で対照を10回再取得し、二峰化が消えることを確認して因果を確定した。 **このページのロード順序は極めて脆く、無関係に見える小さなリソースの削除でも不安定化する。** LCP: 1318ms CLS: 0.000 TBT: 0ms FCP: 232ms SI: 1447ms Overall Score: 100