「Lighthouseのモバイルスコアが76です。すぐ改善した方がいいですか?」。クライアントからこの質問をもらった時、即答する前に確認することがあります。
「実機でも遅いと感じますか?」
LighthouseモバイルPerformance 80 = 体感も80、ではない。意外と知られていないことです。
モバイルプロファイルのthrottling
ChromeがLighthouseを実行するとき、formFactor: 'mobile' を指定すると、以下のthrottlingが自動適用されます。
| 項目 | 値 | 想定実機 |
|---|---|---|
cpuSlowdownMultiplier | 4 | mid-range Android(Moto G Power、2019年頃) |
rttMs | 150ms | 4Gモバイル(やや遅め) |
throughputKbps | 1638(約1.6 Mbps) | 4Gモバイル |
| ビューポート | 412×823 deviceScaleFactor 1.75 | Pixel系 |
CPU 4× slowdownは、計測マシン(M2 Mac等)のCPUを1/4に絞ってシミュレートする仕組み。マシン速度に依存しないスコアを返すために、Lighthouseが意図的にハンディキャップを課しています。
フラッグシップ機(Snapdragon 8 Gen 3、Apple A17)の実機ならもっと速い。ただMid-tierユーザーが多いコーポレートサイトを測る分には、保守的でちょうどいい設定だと思います。この4×を「特定のSoC相当」と言い切るのは無理があるので、特定SoCに紐付けず「実機より遅い条件で測っている」と捉えておけば足ります。
Performance 76を分解する
仮に /notes/article-with-react-island/ のモバイルPerformanceが76だったとします。即「遅い」と判断する前に、Lighthouse Reportの詳細メトリクスを開きます。
まずLCP (Largest Contentful Paint)。何がLCP要素で、いつ描画されたかを見ます。次にTBT。どのスクリプトがメインスレッドをブロックしているか。CLSはレイアウトシフトの犯人探しですが、後回しで構いません。
たとえば「LCP 2.8s、TBT 320ms、CLS 0.001」だったとします。Core Web VitalsのLCP基準は2.5s以下がgood、2.5〜4.0sが要改善(Needs improvement)、4.0s超がpoor。LCP 2.8sは要改善だがpoorではない、つまり「もう少し詰めたい」レンジ。TBT 320msはやや高く、メインスレッドをブロックするスクリプトがあります。CLS 0.001はほぼシフトなしで、レイアウトは安定。
主因はTBT、JavaScriptのハイドレーションコストです。これがReact Islandのハイドレーションだと特定できれば、改善の方向性は「ReactからバニラJSもしくはPreact」「動的インポートで遅延化」。逆に、LCP 4.8sなら主因は「初期描画の遅さ」で、フォントロード、画像最適化、critical CSSの検討が先です。
どのメトリクスが下げているかで、打ち手が変わります。
実機との乖離
Lighthouseモバイル76のサイトをiPhone 14で実機計測すると、Performance 92〜95になることがあります。これはLighthouseプロファイルがMid-tier想定だから。
ここで見るべきは、そのサイトに実際に来ているユーザーのデバイス層です。Google AnalyticsやSearch Consoleで「どの端末からの訪問が多いか」を確認する。Mid-tier以下が多いならLighthouse数値を重視し、改善の余地は大きい。High-endやApple中心ならLighthouse数値より実機計測を信頼し、軽微な悪化は無視できます。
コーポレートサイトの典型的なターゲット(PM、経営層、エンジニア)はiPhoneと比較的新しいAndroidが多く、Lighthouse 80でも実機95+ なら改善優先度は下げてよい。
High-end中心でも数値を保つ理由
ターゲットがHigh-endでも、Lighthouse数値を90+に保つ価値はあります。
Core Web Vitalsのフィールドデータは検索評価の一要素(モバイル検索ランキングへの影響)。Lighthouseはあくまでラボの予測値で、Googleが実際のランキングに使うのはCrUX (Chrome User Experience Report)のフィールドデータです。それに新興国向けに展開すればMid-tierユーザーの比率は上がる。今がHigh-end中心でも、数字を放置する理由にはなりません。
逆に、実機で速くてCrUXもgreen、Lighthouseモバイルだけ76、という組み合わせなら、無理に数字を追わず放っておく判断もできます。プロファイルとフィールドデータを並べて、どちらを信じるか自分で決める、というだけの話です。
Webパフォーマンス領域では、こうしたスコアの読み解きと改善の優先度づけを扱っています。