Notes / Web技術

Lighthouseモバイルスコアの読み方。CPU 4× slowdownプロファイルを分解する

Lighthouseモバイル Performance 80 を見て「遅い」と即断する前に、計測プロファイルを分解します。CPU 4× slowdown、1.6 Mbps throttling、Moto G Power 想定の意味と、実機Mid-tierとの乖離。実数で判断する習慣。

Lighthouse performance mobile measurement

「Lighthouseのモバイルスコアが76です。すぐ改善した方がいいですか?」。クライアントからこの質問をもらった時、即答する前に確認することがあります。

「実機でも遅いと感じますか?」

Lighthouseモバイル Performance 80 = 体感も 80、ではない。意外と知られていないことです。

Lighthouseモバイルプロファイルは意図的に厳しい

ChromeがLighthouseを実行するとき、formFactor: 'mobile' を指定すると、以下のthrottlingが自動適用されます。

項目想定実機
cpuSlowdownMultiplier4mid-range Android(Moto G Power、2019年頃)
rttMs150ms4Gモバイル(やや遅め)
throughputKbps1638(約1.6 Mbps)4Gモバイル
ビューポート412×823 deviceScaleFactor 1.75Pixel系

CPU 4× slowdownは、計測マシン(M2 Mac等)のCPUを1/4に絞ってシミュレートする仕組み。Lighthouseはマシン速度に依存しないスコアを返すために、意図的にハンディキャップを課しています。

実機のフラッグシップ機(Snapdragon 8 Gen 3、Apple A17)ではもっと速い。けれどMid-tierユーザー比率が高いコーポレートサイトには、適切な保守設定です。CPU slowdownを「特定SoC相当」と断定するのは難しいので、「実機よりも遅い条件で測っている」という理解で十分。

Performance 76を分解する

仮に /notes/article-with-react-island/ のモバイル Performance が 76 だったとします。即「遅い」と判断する前に、Lighthouse Reportの詳細メトリクスを開きます。

LCP (Largest Contentful Paint) で、何がLCP要素か、いつ描画されたか。TBT (Total Blocking Time) で、どのスクリプトがメインスレッドをブロックしたか。CLS (Cumulative Layout Shift) で、レイアウトシフトを起こした要素は何か。

たとえば「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+ なら改善優先度は下げてよい。

それでもLighthouse数値を改善する理由

ターゲットがHigh-endでも、Lighthouse数値を90+に保つ価値はあります。

Core Web Vitals のフィールドデータは検索評価の一要素 (モバイル検索ランキングへの影響)。Lighthouseはラボ指標で予測値、実評価は CrUX (Chrome User Experience Report) のフィールドデータで行われます。Mid-tierユーザー比率は将来増える可能性もある (新興国向け展開時)。

実機で速い、CrUXもgreen、Lighthouseモバイルだけ76、という場合は過剰最適化に時間を取られない判断ができます。優先順位はプロファイルとフィールドデータを照らし合わせた上で決めます。


Lighthouseモバイル Performance スコアは「CPU 4× slowdownプロファイル」のラボ指標であり、実機Mid-tierより厳しい予測値です。どのメトリクスが下げているか、ターゲットユーザーのデバイス層はどこか。ここを分解すれば、改善すべきか現状維持でよいかが見えてきます。

Webパフォーマンス分析のご相談はお問い合わせから、業務領域の詳細はServicesへ。