INP改善の方法｜Core Web Vitalsの原因別コードと改善前後の実測値

INP（Interaction to Next Paint）とは、クリック・タップ・キー入力から「画面が次に描き変わるまで」の時間を測る、Core Web Vitalsの応答性の指標です。75パーセンタイルで200ミリ秒以下なら「良好」とされます。改善の基本は、遅れの原因が「入力遅延」「処理時間」「表示遅延」のどこにあるかを切り分け、その区分に合った直し方を選ぶことです。

この記事では、INPの仕組みと基準値を公式情報（web.dev）で確認したうえで、よくある4つの原因をローカルのテストページで再現し、Playwright（Chromium 141）とweb-vitalsライブラリ 6.2.2で改善前後のINPを実測しました。修正コードはそのまま貼って試せる形で載せています。「content-visibilityを1件ずつに付けたら逆に遅くなった」という意外な結果も、数値ごと紹介します。

INP改善の早見表

INPの仕組みと基準値

基準値は200ミリ秒と500ミリ秒

web.devの公式解説（2025年9月更新）によると、INPはページ上のインタラクションのうち最も遅いものに近い値で、評価は実ユーザーの75パーセンタイルで行います。

• 対象の操作：マウスクリック、タップ、キー入力。スクロールやホバーは対象外です。
• 外れ値の扱い：インタラクションが多いページでは、50回ごとに最も遅い1回を除外します。操作が50回未満なら、最も遅い1回がそのままINPになります。
• FIDとの関係：INPは2024年3月にFID（First Input Delay）に代わってCore Web Vitalsになりました。FIDは「最初の1回の入力遅延だけ」でしたが、INPはページ滞在中のすべての操作と、処理と描画までの時間を含みます。

1回のインタラクションは3つの区分に分かれる

flowchart LR
    A[ユーザーがクリック] -->|入力遅延<br>Input delay| B[イベントハンドラ開始]
    B -->|処理時間<br>Processing duration| C[ハンドラ終了]
    C -->|表示遅延<br>Presentation delay| D[次のフレームを描画]

3区分の合計がINPの1回分です。どの区分が長いかで打ち手が変わるため、まず計測で切り分けます。

計測方法の一覧

Lighthouse単体ではINPは測れません（操作がないため）。ラボではTBT（Total Blocking Time）が目安になります。実ユーザーのINPを測るには、フィールドデータかweb-vitalsを使います。

web-vitalsでINPと3区分を記録する

npmの web-vitals 6.2.2（2026年9月時点の最新）で、attributionビルドを使うと3区分と対象要素がわかります。

npm install web-vitals

// main.js（バンドラ利用時）
import { onINP } from 'web-vitals/attribution';

onINP((metric) => {
  const a = metric.attribution;
  const body = JSON.stringify({
    value: Math.round(metric.value),          // INP（ms）
    rating: metric.rating,                    // 'good' | 'needs-improvement' | 'poor'
    target: a.interactionTarget,              // 例: '#calc'
    type: a.interactionType,                  // 'pointer' | 'keyboard'
    inputDelay: Math.round(a.inputDelay),
    processing: Math.round(a.processingDuration),
    presentation: Math.round(a.presentationDelay),
    url: location.pathname,
  });
  navigator.sendBeacon('/analytics/inp', body); // 自前の収集エンドポイント
});

ポイント：onINP は既定ではページが非表示になったとき（タブ切替・遷移）に1回報告します。開発中に毎回見たいときは第2引数に { reportAllChanges: true } を渡します。longAnimationFrameEntries には、そのインタラクションに重なった長いアニメーションフレーム（LoAF）の情報が入り、どのスクリプトが時間を使ったかをたどれます。

検証環境と計測条件

以下の実測は、すべてこのマシンで行った値です。絶対値は端末で大きく変わるため、改善前後の差に注目してください。

計測用スクリプトの骨格です（テストページは各セクションのコードをまとめた1ファイル）。

// measure.mjs（Node.js 22 / playwright 1.56.1）
import { chromium } from 'playwright';

const browser = await chromium.launch();
const page = await browser.newPage();
const cdp = await page.context().newCDPSession(page);
await cdp.send('Emulation.setCPUThrottlingRate', { rate: 4 }); // CPUを4倍遅く
await page.goto('http://127.0.0.1:7250/page.html?s=A&m=before');

// page.click は内部でページ内のチェック処理を待つため、長いタスクの隙間でしか押せない。
// 入力遅延を正しく再現するため、座標を指定して mouse.click を使う
const b = await page.locator('#calc').boundingBox();
await page.mouse.click(b.x + b.width / 2, b.y + b.height / 2);
await page.waitForTimeout(3000);

console.log(await page.evaluate(() => window.__inp.at(-1))); // onINPで貯めた最新値
await browser.close();

ハマりどころ：最初は page.click() で計測したところ、裏で長いタスクが走るパターンでも入力遅延がほぼ0msになりました。page.click() は要素のチェックをページ内で実行してからクリックするため、長いタスクが終わった直後にしか押されないからです。座標指定の page.mouse.click() に変えると、入力遅延が再現しました。

原因1：クリック時の重い処理（処理時間が長い）

改善前：ハンドラの中で全部計算してから表示する

// 60万までの素数を数える（重い計算の例）
function countPrimes(from, to) {
  let c = 0;
  for (let n = from; n < to; n++) {
    let p = n > 1;
    for (let d = 2; d * d <= n; d++) { if (n % d === 0) { p = false; break; } }
    if (p) c++;
  }
  return c;
}

document.getElementById('calc').addEventListener('click', () => {
  const total = countPrimes(0, 600000);            // ここが長いタスク
  document.getElementById('status').textContent = `結果: ${total}`;
});

改善後：先に見た目を変え、残りを小分けにして譲る

// scheduler.yield() があれば使い、なければ setTimeout で代用
function yieldToMain() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

document.getElementById('calc').addEventListener('click', async () => {
  const status = document.getElementById('status');
  status.textContent = '集計中…';                   // 1. すぐに反応を見せる
  await yieldToMain();                              // 2. 描画の機会を渡す
  let total = 0;
  const STEP = 50000;
  for (let i = 0; i < 600000; i += STEP) {
    total += countPrimes(i, Math.min(i + STEP, 600000));
    await yieldToMain();                            // 3. 小分けにして都度譲る
  }
  status.textContent = `結果: ${total}`;
});

実測結果

INPは「次の描画まで」を測るため、最初の描画を先に済ませれば、残りの計算がどれだけ長くてもそのインタラクションのINPには入りません。ただし、分割しないまま後ろに回すと、次の操作の入力遅延になります。だから「先に表示」と「小分け」をセットにします。

scheduler.yield() と setTimeout の違いと対応状況

Safariでも動かすため、上の yieldToMain() のように機能検出してフォールバックする書き方が安全です。

原因2：1文字ごとの全件フィルタと全件描画

改善前

const items = Array.from({ length: 5000 }, (_, i) =>
  `備品-${String(i).padStart(4, '0')} ${['机', '椅子', 'モニター', 'ケーブル', '棚'][i % 5]}`);
const list = document.getElementById('list');

function renderList(keyword, max) {
  const hit = items.filter((t) => t.includes(keyword));
  const shown = max ? hit.slice(0, max) : hit;
  list.innerHTML = shown.map((t) => `<div class="card">${t}</div>`).join('');
}

document.getElementById('q').addEventListener('input', (e) => {
  renderList(e.target.value, 0);   // 1文字ごとに全件を描き直す
});

改善後：デバウンス＋表示は50件まで

let timer;
document.getElementById('q').addEventListener('input', (e) => {
  const kw = e.target.value;
  clearTimeout(timer);
  timer = setTimeout(() => renderList(kw, 50), 200); // 入力が200ms止まってから、50件だけ描画
});

デバウンス（debounce）とは、連続するイベントが一定時間止まってから1回だけ処理する手法です。入力欄の文字自体はブラウザがすぐに描画するので、打鍵の反応は速いまま保てます。

処理時間だけでなく表示遅延も縮んでいる点に注目してください。描画する要素数を減らすことが、DOM更新後のレイアウト時間の短縮にも効いています。

原因3：大きなDOMと広い範囲のスタイル変更（表示遅延が長い）

2万件のカードを並べたページで、body のクラスを切り替えてテーマを変える操作を測りました。

.card { padding: 8px; margin: 4px; border: 1px solid #ccc; border-radius: 6px; }
body.dark .card { background: #222; color: #eee; border-color: #555; }

document.getElementById('theme').addEventListener('click', () => {
  document.body.classList.toggle('dark'); // 処理は一瞬。重いのは後のスタイル計算と描画
});

4つの方法を比べた結果です。

content-visibilityは「まとまり」に付ける

/* 100件ずつ <section class="group"> で包み、そのまとまりに付ける */
.group {
  content-visibility: auto;              /* 画面外のまとまりは描画処理を省く */
  contain-intrinsic-size: auto 6000px;   /* 省いている間の仮の高さ */
}

content-visibility: auto は、画面外の要素のレイアウトと描画を省略するCSSプロパティです（Chrome 85、Firefox 125、Safari 18以降）。今回の計測では、2万個の小さな要素それぞれに付けると、要素ごとの管理コストが上回って逆に遅くなりました。100件ずつのまとまりに付けると、表示遅延は947ms→49msに縮みました。付ける単位で結果が大きく変わるので、必ず改善前後を計測して確かめるのがおすすめです。

DOMを減らすのが最も確実

• ページ分割・「もっと見る」・仮想スクロールで、画面にある要素を数百件程度に保つ
• スタイル変更の影響範囲を狭くする（body ではなく対象コンテナのクラスを切り替える）
• アニメーションは transform と opacity を使い、レイアウトを起こすプロパティ（width・top など）を避ける
• 読み取り（offsetHeight 等）と書き込み（style 変更）を交互に行わない（強制同期レイアウトを避ける）

Lighthouseは、DOM要素数が多いページで「過大な DOM サイズの回避」の診断を表示します。目安として確認しておくと原因の当たりがつけやすくなります。

原因4：裏で動く長いタスク（入力遅延が長い）

広告・チャット・計測タグなどのサードパーティスクリプトや、自前のポーリング処理が長いタスクを作ると、ユーザーの操作がその終了を待たされます。200msごとに150msの処理が走るページで、軽いクリック処理を10回計測しました。

// 改善前：150msを一気に実行
setInterval(() => {
  const end = performance.now() + 150;
  while (performance.now() < end) {} // 重い処理の代わり
}, 200);

// 改善後：30ms×5に分割し、合間でメインスレッドを譲る
setInterval(async () => {
  for (let k = 0; k < 5; k++) {
    const end = performance.now() + 30;
    while (performance.now() < end) {}
    await yieldToMain();
  }
}, 200);

ハンドラ自体は数ミリ秒で終わるのに、INPは160msでした。自分のコードに問題がなくても、他の処理で遅くなる例です。50msを超えるタスクは「長いタスク（Long Task）」と呼ばれ、分割の目安になります。

サードパーティスクリプトの整理チェックリスト

改善の進め方（手順）

flowchart TD
    A[Search Console / PSIで<br>INPが悪いURLを特定] --> B[web-vitals attributionで<br>対象要素と3区分を収集]
    B --> C{一番長い区分は？}
    C -->|入力遅延| D[裏の長いタスクを分割<br>サードパーティを整理]
    C -->|処理時間| E[先に見た目を更新<br>scheduler.yieldで分割<br>デバウンス]
    C -->|表示遅延| F[DOMを減らす<br>変更範囲を狭める<br>content-visibility]
    D --> G[DevToolsで改善前後を計測]
    E --> G
    F --> G
    G --> H[28日後にCrUXで確認]

フィールドデータ（CrUX）は28日間の集計なので、修正の効果が反映されるまで時間がかかります。修正直後はDevToolsやweb-vitalsの自前計測で確認し、フィールドデータは推移で見ます。

よくある失敗と直し方

LCP・CLSとの関係（簡単に）

3指標とも75パーセンタイルで「良好」を満たすと、そのページはCore Web Vitalsに合格です。INPの改善で大きなDOMを減らすと、LCPやメモリ使用量にも良い影響が出ることがよくあります。

よくある質問

Q. INPはSEOの順位にどのくらい影響しますか？ A. Core Web VitalsはGoogleのページエクスペリエンスの一部として評価に使われますが、検索順位は主にコンテンツの関連性で決まります。INPの改善は、順位対策というより「使いやすさと離脱の減少」への投資と考えるのが現実的です。

Q. PageSpeed Insightsで「データがありません」と出ます。 A. CrUXに十分な実ユーザーのデータが集まっていないページです。その場合は、web-vitalsで自前計測するか、DevToolsのPerformanceパネルで操作を記録して確認します。

Q. React や Vue のアプリでも同じ考え方ですか？ A. はい。3区分で切り分ける考え方は同じです。Reactなら useTransition や useDeferredValue で重い更新の優先度を下げる、リストを仮想化する、といった手段が処理時間と表示遅延の短縮に使えます。

Q. scheduler.yield() はSafariで使えますか？ A. 2026年9月時点のMDNの互換性データでは、Safariは未対応です。機能検出して setTimeout にフォールバックする yieldToMain() の形で書けば、全ブラウザで動きます。

まとめ

• INPは操作から次の描画までの時間で、75パーセンタイル200ms以下が良好
• 入力遅延・処理時間・表示遅延の3区分で切り分け、web-vitalsのattributionで記録する
• 重い処理は先に見た目を更新し、scheduler.yield() で小分けに（実測792ms→16ms）
• 入力欄はデバウンス＋表示件数の上限（実測216ms→24ms）
• 大きなDOMは描画量を減らす。content-visibility はまとまり単位で（実測960ms→56ms）
• 裏の長いタスクも分割すると入力遅延が縮む（実測160ms→16ms）
• 改善は必ず前後を計測し、フィールドデータは28日の推移で確認する

株式会社RJCでは、計測して原因を切り分け、改善前後を数字で確かめる進め方を、プロジェクトの中で仲間と共有しています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。