INP（Interaction to Next Paint）

要点：入力から次描画までの応答性。 本ページでは、現場での判断軸/実装/検証までをまとめます。

定義

INP（Interaction to Next Paint）はWebの体感速度を数量化する指標です。ページ種類/端末/回線ごとに分布で見て、p75を改善対象にします。

なぜ重要か

正しく測れなければ改善できません。**事実（RUM）と再現（Lab）**の両輪で、投資対効果の高い箇所へ集中します。

実務での活用（判断基準付き）

• RUMでp75をモニタリング。端末/回線セグメントを分ける。
• Labで原因切り分け（JS/画像/ネット）。改善の因果を確認。
• ダッシュボードで回帰検知とアラートを構築。

実装例

// Paint Timing / PerformanceObserverでLCP/INPを収集
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // 送信先はRUMエンドポイント
    navigator.sendBeacon('/rum', JSON.stringify({ name: entry.name, value: entry.value }));
  }
});
po.observe({ type: 'largest-contentful-paint', buffered: true });
po.observe({ type: 'event', buffered: true, durationThreshold: 40 });

検証と失敗例

• 計測軸: p75≤200msを目標に、主因がimage.decode()かJS長タスクかを切り分け。
• 失敗例: LQIPフェードをrAF外で実行→INPスパイク / 画像CDN変換待ちでTBT悪化。
• 判断軸: Worker移送で50ms超の長タスクを0本化できたか。イベント抑制・バッチ化の徹底。

チェックリスト

• 指標のp75をモニタリングしRUMとDevToolsの差異を把握
• ボトルネックをJS長タスク/画像デコード/ネットで切り分けたか
• 改善施策後に回帰がないかダッシュボードで監視したか
• ロールバック手順とメトリクスのガードレールを設定したか

関連用語

lcp, inp, ttfb, long-tasks