「通信×JavaScript×CPU」が重なる瞬間｜スマホだけ遅くなる典型パターン
»
表示速度を改善しているはずなのに、「なぜかスマホだと重く感じる」この違和感を覚えたことはないでしょうか。
LCPやSpeed Indexが改善しても、体感が追いつかないケースは少なくありません。
今回は、数値上は速いのに"遅く見える"理由を整理します。
体感の遅さは「通信」より「処理待ち」で起きる
一般的に「遅い＝回線が悪い」と思われがちですが、実際のボトルネックは端末側の処理待ちであることが多いです。
特にモバイルでは次の状態が重なります。
- 回線はすでにデータを受信し終えている
- しかし CPU が JavaScript 処理で埋まっている
- 結果として画面が反応しない
この状態では、ユーザー視点では「まだ読み込み中」に見えるというズレが生じます。
「表示されたのに操作できない」が一番ストレスになる
数値指標では見落とされやすいのが、"見えているのに反応しない時間"です。
たとえば、以下のようなケース。
- 画像やテキストは表示された
- しかしスクロールが引っかかる
- タップしても反応が遅れる
この状態は、次のような状況でも発生します。
- LCP：良好
- Speed Index：改善済み
ユーザーにとっては「速くなった」ではなく「使いにくい」という評価に直結します。
JavaScript が「一瞬止める」だけでも体感は悪化する
モバイル端末では、以下が一度でも詰まると、体感の遅さとして強く残ります。
- 50ms を超える JavaScript 処理
- 初期化が重い UI コンポーネント
- スクロールやタップに絡む処理
重要なのは、処理が「長いか」ではなく「操作の直前に走っていないか」という視点です。
「あとから実行」は体感改善に直結する
数値改善よりも効く対策はシンプルです。
- 初期表示に不要な JavaScript を後ろに回す
- 操作が始まる前に処理を挟まない
- 見えてから初期化する UI を減らす
これだけで、操作開始までの引っかかり「重い印象」は大きく変わります。
体感速度は「速さ」ではなく「流れ」で決まる
モバイルにおける体感速度は、以下の数値よりも大切なことがあります。
- 回線速度
- 転送量
- スコア
それよりも、「操作 → 反応」が途切れないかで判断されます。
数値が改善しているのに評価が上がらない場合、それは処理の置き場所に原因がある可能性が高いです。
［参考文献］
・Google / web.dev「モバイルパフォーマンスおよび JavaScript 実行に関する公式解説」
・Chrome Developers「メインスレッド処理とユーザー操作の関係に関するドキュメント」
※当記事はWebの間コーポレート記事の転載です。元記事はこちら。
SpecialPR