INP改善の進め方：実際のWebサイトでInteraction to Next Paintを直す手順

Interaction to Next Paint（INP）は、クリック、タップ、キー入力に対してページがどれだけ速く反応するかを測る指標です。ブラウザは操作ごとに、入力から次の画面描画までの時間を記録します。ホバー、スクロール、ズームは対象外です。多くのサイトでは最も遅い操作の値がそのページのINPになり、操作の多いページでは50回ごとに最も遅い1回が除外されるため、1回の外れ値でスコアが決まることはありません。

Googleの基準は、実ユーザーのページ読み込みの75パーセンタイルに対して、モバイルとデスクトップ別に適用されます。200ミリ秒以下が「良好」、200ミリ秒超〜500ミリ秒が「改善が必要」、500ミリ秒超が「不良」です。INPはFirst Input Delay（FID）の後継となる応答性のCore Web Vitalです。FIDは最初の操作でハンドラが動き出すまでの待ち時間しか測っていなかったため、FIDは楽に合格していたサイトがINPでは不合格になることがあります。

Googleは、検索で成功するために良好なCore Web Vitalsを達成することを強く推奨しており、Core Web Vitalsはほかのページエクスペリエンスの要素とともに、コアランキングシステムが評価しようとするものと一致すると説明しています。INPはLargest Contentful Paint（LCP）、Cumulative Layout Shift（CLS）と並ぶ3指標の1つです。実際には、INPを改善しても検索意図に合っていないページの順位は上がりませんが、反応の遅いページは順位にもコンバージョンにも不利に働きます。

主に2025年7月の計測に基づくHTTP ArchiveのWeb Almanac 2025によると、INPが良好なWebサイトはモバイルで77%（2024年の74%から上昇）、デスクトップでは97%でした。Core Web Vitals全体が良好なサイトは、モバイルで48%、デスクトップで56%にとどまります。不合格の場合、まず確認すべきはモバイルです。

INPはフィールド指標なので、ラボのスコアではなく実ユーザーのデータから始めます。RUM（リアルユーザーモニタリング）ツールを使えば、どのページのどの要素がクリックされたか、そのときページがどこまで読み込まれていたかまで分かるため、最も多くの手がかりが得られます。RUMがない場合はPageSpeed InsightsでChrome User Experience Report（CrUX）のフィールドデータを確認できますが、合否は分かっても原因となった操作まではほとんど分かりません。

これまでINPのRUMデータはほぼChromium系ブラウザからしか取得できませんでした。2025年12月リリースのSafari 26.2でEvent Timing APIが追加され、WebKitはこれによりINPの計測が可能になったと説明しています。iPhoneの利用者が多いサイトでは、計測ツールを更新し、SafariとChromeを比較してから問題の所在を判断しましょう。なお、CrUX、つまりGoogleが報告するスコアは引き続きChromeユーザーのデータです。

操作の遅延時間は3つの合計です。入力遅延は、ユーザーの入力からイベントハンドラが動き出すまでの時間で、多くはメインスレッドがほかの処理で埋まっていることが原因です。処理時間は、イベントハンドラの実行にかかる時間です。表示遅延は、ハンドラの終了からブラウザが次のフレームを描画するまでの時間で、スタイル計算、レイアウト、ペイントが含まれます。

この分解が工程全体で最も重要な判断です。対策が重ならないためです。ユーザーがタップした時点で外部スクリプトの評価がまだ続いていたことが真の原因なら、クリックハンドラを書き直しても効果はありません。また、iframeはそれぞれ独自のメインスレッドを持つため、操作がどのフレームで起きたかも確認します。

判断の目安をシンプルにしておくと作業がぶれません。入力遅延が最も大きい場合、問題は操作そのものではなく、メインスレッドで同時に動いている別の処理であることが多いため、対策はスクリプトの読み込み方にあります。処理時間が最も大きい場合は、自社のイベントハンドラやコンポーネントのコードを直します。表示遅延が最も大きい場合は、操作後にページのどれだけが変化するか、DOMがどれだけ大きいかを確認します。2つのフェーズが同程度なら、変更コストの低い方から直し、再計測してから次に進みます。

どのフェーズが大きいか分かれば、選択肢はすぐに絞れます。50ミリ秒を超えるタスクは「長いタスク」と呼ばれ、入力遅延や処理時間の問題の多くはこれが原因です。フェーズごとのGoogleの推奨は次のとおりです。

コーポレートサイトやECサイトでは、同じパターンが繰り返し見られます。以下は診断結果ではなく、自社の実データで確かめるための仮説として使ってください。

これらの問題の多くは、構築時ではなく公開後に持ち込まれます。マーケティング担当が新しいタグを入れる、プラグインがウィジェットを追加する、商品一覧が50件から2,000件に増える、といった変化です。だからこそINPは、サイトを構築した開発者だけでなく、本番サイトへの変更を承認する担当者が責任を持つべき指標です。

ラボのテストで操作が速くなったことは確認できますが、重要なのはフィールドでの75パーセンタイルです。変更したページと操作のRUMデータを、デバイス別に追いかけます。フィールドデータは実際の訪問から蓄積されるため、PageSpeed InsightsやSearch Consoleへの反映はリリースから数週間かかると考えておきましょう。

Google自身も、INP改善の鍵は粘り強さだとしています。1つの遅い操作を直すと、次の遅い操作が見えてくることが多いからです。リリース前のチェックリストにINPの目標値を加え、外部スクリプトを追加したら必ず再確認します。改善を最も台無しにしやすいのがその変更だからです。