Google*NitroPackウェビナー「INP遅い原因と解決策」

フィールドデータINPの重要性とその改善が経営に直結することを適切に表しているため、👉How to Improve Interaction to Next Paint (INP) | Google and NitroPack Webinar について内容をまとめました。やや古い動画であるため、2025/10/27時点の機能をNitroPackダッシュボードから書き出して記載しています。

応答性の重要さ

Webサイトで入力応答性や操作体験が良くないと、応答を待たずクリック等をしない、カート離脱、再訪問などの機会損失につながります。直感的にページの応答性を向上させることは、ユーザー満足度の向上と経営視標の改善につながります。

改善例.1

• Economic Times（インド）
  • 改善前
    • INP 1000ミリ秒以上
    • TBT 3秒
  • 改善後（メインスレッドのタスク効率化、DOMサイズの縮小）
    • INP 250ミリ秒
    • TBT 120ミリ秒
    • 直帰率50%減少
    • ページビュー大幅増加

改善例.2

• RedBus（インド：チケット予約サイト）
  • 改善前
    • ラボデータではINP良好。しかし、フィールドデータは良くなかった
    • 重たいjavascript
    • ネットワーク経由で送信される長いAPIコール
  • 改善後
    • APIコールのサイズ縮小
    • レスポンス結果を細かく別けて取得する遅延読み込みを採用
    • 上記のように各リクエストによる負荷を軽減しINPの大幅削減に成功
    • INP改善により売上が向上

INP（FIDにとって変わる指標）とは

• INP（Interaction to Next Paint）
  • looks at all the interctions on the page , and measuers the longest time between interaction and next paint across those interactions（ページ上のすべてのインタラクションを監視し、これら監視対象のインタラクションについて、インタラクションから次のペイント(ブラウザ描画)までの最長時間を測定します）
    • Mouse Click（マウスクリック操作）
    • Tapping on a touchscreen（タッチスクリーン上のタップ操作）
    • Pressing a keyboard key（キーボードキーの押下操作）
  • ホバーやスクロールはINPで測定されない

• FID（First Input Delay）もINP（Interaction to Next Paint）もWebサイトの応答性（Responsiveness）の指標
  • どちらもWebサイトがユーザーの操作に迅速に反応するかどうかという指標
  • 2024年3月にFIDからINPへ指標が変更された。

👉INP を Core Web Vitals に導入  |  Google Search Central Blog  |  Google for Developers 2023/5/10

Responsiveness と Interaction

• (UI) Responsiveness
  • 画面が操作にどれだけ素早く・滑らかに反応するか。応答性。
• Interaction
  • ユーザーによる個々のクリック、タップ、入力、スクロール等の単発の操作。

FIDとINPの違い

どちらもhttp(s)レスポンス受信から始まる、ブラウザで行われる各種工程のパフォーマンス指標です。

ユーザーがWebサイトに訪問し、ボタンをクリックするとブラウザの内部でWebページ表示に向けた処理が進行中で、BlockingTaskとなる処理が行われています。下図の一番左の濃い紫色の帯の部分です。このTaskにより、ユーザーによる何らか操作としてのインタラクション処理の開始までに少し遅延が発生します。

👉【INP理解】ブラウザアドレスバーURL入力からWebページ表示の全工程と調査

• FID（First Input Delay）
  • 初回（インタラクションの）入力遅延
  • 動画の中でGoogleのBarry Pollard氏は、ページの読み込み中、もしくはページ読み込み直後に初回のインタラクションが発生すると言っています。
  • このタイミングは、ブラウザにとって非常に忙しい時間で、過去にはこれが主要ブロッカー（ボトルネック）であると認識されていた。

• INP
  • FIDのBlockingTaskによる遅延タイミングの前後だけではなく、INPは、ユーザーのマウスクリックなどすべてのインタラクションからBrowserのPainting（描画）まで全インタラクションを監視します。それらのインタラクション間で発生するインタラクションと次のペイントの間の最長時間（極端な外れ値は除外）を測定します。
  • INP計測対象の例外（動画アップロードなど）
    • 動画のアップロードなど高負荷な操作には多くの時間がかかりますが、これは当然のことであるため、ユーザーに対して「処理中」や「処理の進行の程度」などを伝えていれば問題は有りません。買い物かごへの追加なども、トランザクション全体を完了していなくて良いです。この様なケースはINP計測対象の例外となります。
  • INPは3セクションに別けられる
    • Input delay
      • 今までのFIDに相当する部分の遅延
    • Processing time
      • ユーザーによるインタラクション自体の処理時間による遅延
      • 単純なユーザーのインタラクションだけではなく、javascriptのライブラリなどユーザーが直接制御できない機能も含まれる。
    • Presentetion delay
      • Webページを更新する際の表示による遅延
        • DOM更新やスタイル計算変更など

良好なINPとは？

良好なINPの基準

INP ≦ 200ms

モバイルとデスクトップの端末別で 75パーセンタイル 基準による測定として、200ミリ秒以内に画面が更新されること。

運用では様々な課題が必ず発生するため、厳密に 200ms と決めるのではなく、INP ≦ 100ms を目標としてバッファを確保することが強く推奨されます。

NitroPack CTO Ivailo Hristov氏は、「特定のコンテンツをページに掲載する or しない、という様な再考を行ってまで、DOM構造の変更、サイトの構築方法の変更、コンテンツの変更をすることはあまり良いアイデアではない」という点に言及しています。

INP計測ツール

• 👉PageSpeed Insights
• 👉Google Search Console
• CrUX Dashboard（廃止） →👉CrUX Vis
• 👉GoogleChrome/web-vitals（javascript）
• Chrome拡張Web Vitals(廃止) →ChromeブラウザDevTools > Performance > Local metrics

INPが遅くなる原因

3rd Partyのコードは下記の主要な根本原因となることが特に多い。Googleにも状況を改善するための責任があり、応答性の向上に取り組んでいると発言されています。

• ページ上の多すぎる処理（長いTaskの多発）
  • 大規模なDOM
  • 複雑なCSSセレクタ
  • 多すぎるjavascript
  • Webプラットフォームを活用してない
• 低品質なコード
• メインスレッドに制御を戻さない計算負荷の高いタスク実行

INPデバッグ改善フロー概要

Webサイトの最適化は、常に、最新の情報キャッチアップと終わりのないプロセス。

1. INPの問題をRUMデータ監視で特定
   • どのページでどの要素が影響を受けているか特定
2. 根本原因の調査
3. 修正の適用
   • 部分的な修正とするのか、根本原因を考慮して全体に波及させられる修正とするのか

INPが遅くなる原因の特定

動画の中では、ECサイトで製品検索の虫眼鏡をクリックすると、400msの遅延発生後に製品一覧が表示されるサンプルが用意され、紹介されています。改善対応後、「外れ値」がいくつか発生していましたが、バッファが有ることでINP ≦ 200msに抑えられていました。

以下の方法で、INPが遅くなる原因の特定が可能です。

• Chrome Dev Tools の Performanceタブ（Performance profiler）でRecordボタンをクリック
  • （ブラウザの）イベントのトレースを記録
    1. フレームチャートのMainスレッドで最も長いTask（のバー）を探す
    2. 最も長いTaskの下を見て、工程別で長いTask（のバー）を探す
    3. 紫色の Recalcurate Style などの工程別Taskを探してクリック、Summaryで Duration（タスクの処理にかかった時間）と Elements Affected（影響を受けたDOM要素の数）を調べる
    4. また、Mainスレッドで最も長いTaskの中の工程別は他にも有るため、他の紫色の Recalcurate Style などのTaskもクリック。Summaryで Durationと Elements Affectedを調べる

動画内の後半の Q and A では、ユーザーによる様々なケースを運用者側で調査することは難しいため、RUM（Real User Monitoring）による計測も、上記の様にブラウザで再現できない場合や、デバイス（モバイル／デスクトップ）、ページ、DOMの要素を把握するため、有効であると会話が有りました。

Performanceタブのメインスレッドで探し出した工程別タスクの解決

Performanceタブのメインスレッドで長いタスクは、Summaryに記載されている以下の数値を減らす事が基本的な対策となります。

• Duration
  • 特定された「工程別Taskで長いTask」のタスクの処理にかかった時間を減らす
• Elements Affected
  • 特定された「工程別Taskで長いTask」の影響を受けたDOM要素の数を減らす

対策を実施するためのNitroPack設定

NitroPackで以下の設定を行う。

• HTML遅延読み込み（非クリティカルアセットの取得を遅延）
• HTML遅延レンダリング（非クリティカルアセットのScripting、Calcurate Style、Layout、Paintingの遅延）
• 未使用cssの削除

改善策を施したページと改善してないページで比較を行い、効果を確認出来たら本番環境へデプロイし監視する

（メインスレッドに制御を戻さない）計算負荷の高いタスクへの対処

このケースでは、以下の方法が有ります。

1. 小さなタスクに分割し、メインスレッドへの主導権を細かく返して負荷を下げる
2. Web Workersの活用。CPUの重い処理をメインスレッドを空ける
3. タグ類（計測、広告、チャット）をWorkerに隔離し、メインスレッドの占有を防ぐ。

Q and A

Q.問題の原因となっているコードが自分(自社)の管理下にない場合、どうしたらいい？

1. 3rd Partyのベンダーへ連絡し、改善を依頼する
2. Partytownを使い、3rd PartyのコードをWebWorkerにロードして効果があるか？有無を確認。そもそも3rd Partyを採用するかどうか。もしくは代替手段を探す。

Q.自分の問題でも責任でもないコードで、なぜペナルティを受けるのか？

GoogleのBarry Pollard氏は、「苦しんでいるのはユーザーであり、ライセンス料金などのお金を払って3rd Partyを使っている場合、なぜ、（3rd Partyの利用者である）ユーザーがペナルティを受けるのか？と3rd Partyに問います」

という核心を突く言葉が出ています。「誰かが気付いて対応してくれるだろう」とするよりも、3rd PartyによるCoreWebVitals劣化ペナルティに気付いた当事者がベンダーに対してアクションしたほうがいいというニュアンスでした。

Q.Javascriptによるタイムアウトが起きる場合、どのように改善したら良いか？

1. 遅いjavascriptのパーツであれば、WebWorkerで実行し、メインスレッドを使わないで改善するか試してみる（ビデオ処理を複数回行う、画像処理、Webアプリで計算コストの高い税金などの計算で、直下に記載している分割をしなくて済むかもしれません。ただし、オフロードも取り扱うコストは必要なため、やらないで済むならそのほうがいいです）
2. プロセスをできるだけ多くの小さなタスクに分割する、javascriptの分割を行う。

NitroPackで対応可能な機能 2025/10/27

NitroPackは、全コンテンツとウェブサイトの構造を維持したまま、主に以下の様な機能を導入可能。随時、新機能追加されています。React/Vue.js/Angularなどで機能を追加実装せず、NitroPackで改善策対応が可能です。

• 画像と動画
  • 画像の遅延読み込み
  • iframeの遅延読み込み
  • self-hosted videos の遅延読み込み（youtubeではなく自社ホストによる動画ファイル）その他
  • 画像最適化（.webp）
  • （コンテンのサイズに合わせた）画像サイズ調整
  • ビデオファサード（ユーザーが再生するまで動画読み込みを遅延）
  • LCP Preload
• javascript
  • レンダリングに対するblocking resourcesの除外
  • 非クリティカルリソースの遅延読み込み
  • Google Tag Manager最適化
  • 圧縮
• HTML/CSS
  • JSON-LD
  • HTML正規化
  • Critical CSS
  • フォントをCriticalCSSから除外（ページ初期レンダリングから除外）
  • 未使用CSS除外
  • CSS結合
  • 30kbを超える大きなインラインCSSを外部ファイル化
  • 圧縮
• フォント
  • フォントレンダリング動作の上書き
  • 「preload」 or 「after onload event」
  • サブセット化
  • 圧縮
  • Google hosted fonts最適化
• キャッシュ
  • 有効期限カスタム
  • 広告最適化
  • ユーザー訪問時のキューにおけるページ最適化
  • インスタントキャッシュ再最適化（キャッシュ期限切れ時に自動で更新などの再最適化）
  • AJAX URLキャッシュ
  • キャッシュ最適化ページで保持するヘッダーの指定
  • バックグラウンドパージ（古いキャッシュが置き換えられる前に、バックグラウンドで新しいキャシュを構築）
  • 動的コンテンツクッキー
  • 画像、URL，javascript、css、cookieなどの個別リソース指定によるキャッシュ除外
  • Preload (Cache) warmup
    • 自動 or XMLサイトマップでURL指定
      • XMLサイトマップ自体は、最新コンテンツ状況をボットやクローラーに伝えるため、キャッシュ除外が必要

API（参考）

👉NitroPack Cloud API

CoreWebVaitals対応におけるバッファの大切さ

にしラボでも、FCP、LCP、TBT、CLSを削減したことでGA4やリマーケなどの追跡系javascriptタグによる劣化分をバッファで補う状況に遭遇したことがあります。さらに、FCP、LCP、TBT、CLSの削減により元来から発症していたINPが目立つようになるケースなども多いと考えられます。基準値よりも目標を高く設定し、バッファを持つことでRUM監視の安定性を確保するという考え方は、CVRやページ離脱に対する改善では重要です。

大量ハイドレート と 内製済ソースコード

動画内では、3rd Partyが多くの場合の原因である、として言及されていますがjavascriptの大量ハイドレート、内製済ソースコードもINP劣化の原因となる可能性があります。