モバイルファーストの現実解｜PSIで“スマホだけ悪い”をどう改善するか

PageSpeed Insights（以下 PSI）を計測すると、PCは90点台、スマホだけ60点台という結果は珍しくありません。

こんな時に諦めていませんか？

• 「モバイル回線が遅いから仕方ない」
• 「端末性能の問題だからどうしようもない」
• 「PCが速いならOKでは？」

しかし、スマホだけスコアが悪くなるケースの多くは回線や端末そのものではなく、構成と実行順序の問題です。

今回は「スマホ向けに作り直す」でも「全部削る」でもない、モバイルファーストの現実的な改善アプローチを整理します。

なぜ「スマホだけ悪い」が起こるのか（整理）

まず、スマホで遅くなる要因は単独ではありません。

• 回線が不安定
• CPU性能が低い
• JavaScriptの実行が重い

これらが同時に重なる設計になっているとき、PSI（モバイル）では一気に評価が下がります。

スマホ向けのPSI改善とは「軽いものを使う」ことではなく“詰まる瞬間を作らない”構成に変えることと言えます。

モバイルファーストとは「スマホ用に別物を作る」ことではない

モバイルファーストという言葉は、しばしば「スマホ専用デザイン」「機能削減」と誤解されます。

しかしPSIの文脈で言うモバイルファーストは違います。

• 最初に処理されるものを厳選する
• 後回しにできる処理を明確に分ける
• 初期表示に不要な負荷を積まない

つまり、実行順序の設計思想の話です。

スマートフォンでPageSpeed Insightsで見るべきポイント

スマホだけ悪い場合、以下の指標に必ず兆候が出ます。

• LCP：2.5秒を超えている
• Speed Index：見た目が出揃うまでが遅い
• Total Blocking Time：初期操作が効かない時間が長い

ここで重要なのは、どれか1つだけを見ることではありません。

• LCPが悪い → 初期リソースが重い
• Speed Indexが悪い → 不要な描画・読み込みが多い
• TBTが悪い → JavaScript実行が詰まっている

この組み合わせを見て判断します。

“スマホだけ悪い”を改善するための現実的な施策群

ここでは、よくある「やりすぎ施策」ではなく、効果が出やすい順に整理します。

• 初期表示に関与する要素を明確に分ける
• ファーストビューに必要な要素だけを先に描画
• それ以外の画像・装飾・機能は後段へ

「全部必要」に見える構成ほど、スマホでは破綻しやすくなります。

JavaScriptを“止める”のではなく“遅らせる”

多くのサイトで問題なのは、JavaScriptが多いことではなく初期に全部実行していることです。

• LCP表示後に初期化する
• ユーザー操作があってから読み込む
• 非同期でも「即実行」させない

これだけでTBT・Speed Indexは大きく改善します。

スマホで不要な処理を「実行させない」設計

同じコードでも、以下のような処理は非常に多いです。

• PC：問題なし
• スマホ：詰まる

これを存在しているだけで実行されている処理がないか、という視点で見直します。

• スクロール連動
• 常時監視のイベント
• 表示されていない要素への処理

モバイルPSI改善は「最適化競争」ではない

PSIだけを見て、次のようなテクニック合戦になっていませんか？

• preloadを足す
• priorityを上げる
• 指標を緑にする

しかしスマホで重要なのは、速く見せることではなく引っかからずに使わせることです。

• スクロールが効く
• タップが反応する
• 画面が急に変わらない

これらが守られていれば、PSIの数値も自然と安定します。

モバイルファーストの「現実解」とは

モバイルファーストの現実解とは、スマホ専用に作り直すことでも表現を削り落とすことでもなく、処理の優先順位をスマホ基準で設計し直すことです。

• 初期にやるべきこと
• 後でやればいいこと
• やらなくても成立すること

これを整理できたサイトは、PSIでも、実際の操作感でも、確実に安定します。スマホで遅い理由は「環境のせい」ではありません。構成と実行順の問題です。

PageSpeed Insightsを「点数を見るツール」ではなく、詰まりを発見するツールとして使えるようになると、モバイル改善は一気に現実的になります。

［参考文献］
・Google / web.dev「モバイルパフォーマンス、Core Web Vitals、PageSpeed Insights に関する公式解説」（モバイル回線・CPU制約・JavaScript実行コストの考え方を含む）
・Chrome Developers（旧 Google Developers）「PageSpeed Insights・Lighthouse の評価指標（LCP / Speed Index / TBT）とモバイル環境におけるパフォーマンス特性の公式ドキュメント群」
・W3C Web Performance Working Group「Long Tasks / Main Thread ブロッキング / UI 応答性に関する仕様および設計思想（「50msを超える処理がUXを阻害する」という前提の根拠）」