LCPはもう古い？ Googleの新指標『INP』が計測する”イライラ”の正体と、エンジニアがやるべき3つのデバッグ

もしあなたのサイトがこの状態なら、危険信号です。 Googleは2024年3月、Core Web Vitals（Webサイトの健全性指標）に大きな変更を加えました。

これまで重視されてきた FID (First Input Delay) が廃止され、新たに INP (Interaction to Next Paint) が導入されたのです。

これは単なる指標の入れ替えではありません。 Googleが**「サイトの表示速度（LCP）」よりも「操作の応答速度（INP）」を重視し始めた**という、評価基準のパラダイムシフトです。

本記事では、多くの企業が対策に苦戦しているこの「INP」の正体と、エンジニアが今すぐ確認すべきデバッグ手法を解説します。

---

第1章：LCP（表示）と INP（応答）の違い

まず、用語を整理しましょう。

• LCP (Largest Contentful Paint):
  • 「いつ見えるか？」
  • メインの画像やテキストが表示されるまでの時間。
  • 例：レストランに入店して、料理が出てくるまでの時間。
• INP (Interaction to Next Paint):
  • 「いつ動くか？」
  • ボタンを押してから、実際に画面が反応するまでの時間。
  • 例：店員さんに「すみません」と声をかけてから、振り返ってくれるまでの時間。

なぜGoogleはLCPだけでは満足しなかったのか？

従来のLCP対策によって、多くのサイトは「表示」だけは速くなりました。 しかし、**「画面は出ているのに、ボタンを押してもフリーズして動かない」**という現象（ハイドレーション待ちなど）が多発しました。

ユーザーにとって、「無視される（反応がない）」ストレスは、「待たされる（表示が遅い）」ストレスよりも遥かに大きいものです。 Googleはこの「操作時のイライラ」を検知するために、INPを導入しました。

---

第2章：INPの正体は「メインスレッドの渋滞」

INPが悪化する原因を一言で言えば、**「JavaScriptが忙しすぎて、ユーザーの相手ができない状態」**です。

ブラウザには**「メインスレッド」**という、たった一本の作業レーンしかありません。
描画、スクリプト実行、イベント処理…すべてをこの一本のレーンでこなしています。

INP 200ms超えのメカニズム

1. ユーザーが「カートに入れる」ボタンをクリックする。
2. しかし、メインスレッドでは「広告タグの読み込み」や「複雑な計算」などの**重い処理（Long Task）**が走っている。
3. ブラウザは「ちょっと待って、今手が離せない！」とクリックを無視する。
4. 処理が終わってようやく「カートに入れました」と画面を書き換える。

この「待って！」と言われている時間（フリーズ時間）こそが、INPの正体です。
Googleは、これが 200ミリ秒（0.2秒） を超えると「改善が必要」と判定します。

---

第3章：エンジニアがやるべき3つのデバッグ

では、具体的にどう改善すればいいのでしょうか？ 闇雲にコードを消すのではなく、Chrome DevToolsを使って科学的にアプローチします。

Step 1. 「犯人」を特定する (Performance Panel)

Chromeのデベロッパーツールを開き、[Performance] タブを使います。

1. 録画ボタンを押し、ページ上でボタンをクリックするなどの操作を行う。
2. 結果のタイムラインに 「赤色の斜線」が入ったブロック があれば、それが「Long Task（50ms以上かかる重い処理）」です。
3. その下にある Function Call を見れば、どのJavaScript関数がメインスレッドを占有しているか特定できます。

多くの場合、サードパーティ製のスクリプト（チャットボットや大量のトラッキングタグ）か、巨大なReactコンポーネントの再レンダリングが犯人です。

Step 2. 処理を「譲る」 (Yielding to Main Thread)

重い処理が見つかったら、それを分割します。 setTimeout や、新しいAPIである scheduler.yield() を使うことで、処理の合間に「息継ぎ」を入れることができます。

例）JavaScript

// 悪い例：重い処理が終わるまで画面が固まる
function heavyTask() {
  doPart1();
  doPart2(); // ← ここでユーザーがクリックしても反応できない
  doPart3();
}

// 良い例：処理の合間に制御をブラウザに返す
async function heavyTaskOptimized() {
  doPart1();
  await scheduler.yield(); // 「お先にどうぞ」とメインスレッドを譲る
  doPart2();
  await scheduler.yield();
  doPart3();
}

これにより、重い処理の途中でも、ユーザーのクリックに即座に反応できるようになります。

Step 3. 見た目だけでも即答する (Optimistic UI)

処理自体の高速化に限界がある場合は、
**「見せ方」**でINPを改善します。

ボタンを押した瞬間に、裏側の処理（API通信や計算）を待たず、まずはCSSでボタンの色を変える、ローディングアイコンを出すといった「描画（Paint）」を最優先で行います。

INPは「処理が終わる時間」ではなく、「次の描画（Next Paint）が始まる時間」を計測するからです。
**「処理は終わってないけど、反応はしたよ」**とブラウザに認識させることで、スコアは劇的に改善します。

---

まとめると、INP改善は「おもてなし」である

INPのスコアが悪いということは、あなたのサイトはユーザーに対して**「無視」**を繰り返しているということです。 これでは、いくら良い商品を置いていても、SEO順位は下がり、コンバージョン率も低下します。

• 表示（LCP） は速くて当たり前。
• これからは 応答（INP） の時代です。

エンジニアはDevToolsを開き、メインスレッドの渋滞を解消してください。それが、ユーザー体験を劇的に向上させる最短ルートです。

---

👇 【解決策】INPを改善する「UI実装」の極意

【React】ローディングスピナーは「敗北」である。Optimistic UIの実装論

本記事のStep 3で紹介した「見た目だけでも即答する」技術。 サーバーレスポンスを待たずに画面を更新する「Optimistic UI」の具体的なコード実装はこちら。

👉 記事を読む：Optimistic UIの実装コードと注意点 :::

👇 【根本治療】重い処理を「サーバーレス」へ逃がす

【AWS】UXを爆速にする「非同期処理」アーキテクチャ

フロントエンド（メインスレッド）で行っている重い計算やログ送信を、AWS（SQS × Lambda）へ逃がしてINPを爆上げする方法。

👉 記事を読む：AWSによる非同期ログ基盤の構築手法 :::

---

👉 記事を書いた人