「ボタンを押しても一拍おいて反応する」「スマホでメニューがもたつく」。表示自体は速いのに、触ったときの手応えが鈍い。そんな相談を受けたとき、私はまずINPだけを狙って直せないかを考えます。サイトを作り直さなくても、操作の重さは部分的な改修でかなり軽くできるからです。

この記事では、既存サイトを全面リニューアルせずにINPだけを外科的に改善する手順を、実装者の視点でまとめます。指標そのものの網羅的な解説はしません。あくまで「今動いているサイトの、この重さをどう削るか」に絞ります。

INPは何を測っているのか

INP（Interaction to Next Paint）は、クリックやタップ、キー入力などの操作に対して、画面が次に描き変わるまでの遅さを測る指標です。GoogleはこれをCore Web Vitalsの一つと位置づけ、2024年3月12日にそれまでのFID（First Input Delay）に代わる正式な指標として置き換えました。

FIDが「最初の操作の待ち時間」だけを見ていたのに対し、INPはページ上のほぼすべての操作を対象にし、その中の悪い方の値で応答性を代表させます。しかもINPは、入力を受け取るまでの待ち時間だけでなく、イベント処理そのものの時間と、画面を描き直すまでの時間まで含めて測ります。

良い応答の目安は、実利用者の75パーセンタイルで200ミリ秒以下とされています。裏を返せば、多くの利用者が「押した瞬間に反応した」と感じる状態を保てているか、という指標です。

ここまでを整理すると、INPが悪いサイトはたいてい「操作した瞬間に、裏で重い処理が走っている」ことが原因です。だから直し方も、その重い処理をどう避けるかに集約されます。表示速度そのものの話は表示速度とCore Web Vitalsの記事で触れているので、そちらもあわせてどうぞ。

INPを削る4つの手当

私が既存サイトのINPを見るとき、順番に確認するのは次の4点です。

INPを削る4つの手当。長いJS処理を分割する、イベント処理を軽くする、サードパーティのタグを遅延する、不要なJSを外す
  • 長いJS処理を分割する：一度に長く走るJavaScriptは、その間ブラウザが操作に応答できません。処理をいくつかに区切り、途中でブラウザに制御を返します。
  • イベント処理を軽くする：クリックやスクロールのハンドラの中で重い計算やレイアウト測定をしていないか。中身を絞り、急がない処理は後回しにします。
  • サードパーティのJSを遅延する：計測タグやチャットウィジェットなど、外部スクリプトは操作をブロックしがちです。最初の操作の後や、必要になった瞬間に読み込みます。
  • 不要なJSをそもそも外す：使っていないライブラリや、もう不要になった機能のスクリプトを積んだままにしない。積まないのが一番速い、と感じています。

この4つのうち、まず効くのは前半2つと3つ目です。順に実装の具体を見ていきます。

長い処理は区切って、入力を先に返す

JavaScriptは基本的に一本のスレッドで動くので、長い処理が走っている間は操作を受け付けられません。50ミリ秒を超えて連続実行される処理（ロングタスク）が、INP悪化の代表的な原因です。

対策の芯は「長い処理を細かく区切り、合間にブラウザへ制御を譲る」こと。近年のブラウザには、譲るための専用の仕組みも用意されています。

// 重いリストの構築を一気にやらず、こまめに譲る
async function buildList(items) {
  for (const chunk of splitIntoChunks(items, 50)) {
    render(chunk);
    // ブラウザに一度制御を返す（対応環境ではscheduler.yield）
    await new Promise((r) => setTimeout(r));
  }
}

ポイントは、操作に直結する部分を先に返し、残りを後続のフレームに逃がすことです。ユーザーの入力に対する見た目の反応だけ先に済ませ、重い集計や描画は後から追いつかせる。この順番を意識するだけで、体感はかなり変わります。

もう一つ有効なのが、頻発するイベントの間引きです。スクロールや入力のたびに重い処理を呼ぶのではなく、実際に描画が必要なタイミングにまとめる。スクロール連動の演出を入れるときも、処理を軽く保つ設計が要ります。この点は重くないスクロール演出の記事でも触れています。

計測タグ・チャットは「操作の後」に読み込む

実務で一番効きやすいのが、サードパーティスクリプトの遅延です。アクセス解析、広告、チャット、ヒートマップ。これらは自分たちのコードではないぶん中身を軽くできませんが、いつ読み込むかは制御できます。

操作が重い作りと軽い作りの比較。重い作りはJS処理を一気に長く実行し計測タグを最初に全部読むため待たされる。軽い作りは処理を細かく区切って譲り、計測タグを操作の後に読むためすぐ返る

私が自分のサイトでやっているのは、最初の操作やアイドル時間まで計測タグの読み込みを待たせる方式です。ページが表示され、利用者が最初にスクロールなりクリックなりをしたタイミングで初めてタグを差し込む。こうすると、操作が集中する序盤にスクリプトの実行がぶつからず、反応が軽くなったと感じています。

  • 必要になるまで読み込まない：チャットは、ボタンが押された瞬間に本体を読み込む。最初から常駐させない。
  • アイドル時間に回す：計測タグは、ブラウザが暇な瞬間（requestIdleCallback等）に差し込む。
  • 読み込みの優先度を下げる：どうしても早く要るもの以外は、優先度を落として後回しにする。

どれも「機能を消す」わけではなく「タイミングをずらす」だけです。データは取れるし、チャットも使える。ただ、操作の邪魔をしない位置に動かす。ここが外科的改修の勘所です。

作り直しの前に、まず計測して削る

INPは、原因が特定の操作や特定のスクリプトに偏っていることが多い指標です。だからこそ、全面リニューアルの前に「どの操作が、どのスクリプトのせいで重いのか」を計測し、そこだけをピンポイントで直す価値があります。作り直せば直るのは確かですが、費用も期間も段違いです。

手順としては、実利用者のデータで悪い操作を特定し、その裏で走っている処理を分割・軽量化・遅延する。多くの場合、これで200ミリ秒の壁は越えられます。リニューアル全体でSEOと速度を見直す判断はリニューアルとSEOの記事にまとめていますが、INPだけなら、そこまで大掛かりにしなくても手当てできます。

既存サイトの操作が重い、触ったときの反応が悪い、でも作り直す予算はない。そういうときは、まず計測して削れるところから直す方法があります。実装まで含めて相談したい方は、お問い合わせからお気軽にどうぞ。現状のどこが重いのかを見るところからお手伝いします。

本記事は2026年7月時点の情報です。INPの指標仕様や判定基準は今後変わる可能性があるため、実装の際は最新の公式情報もあわせてご確認ください。