「クリックしたのに、なんか動くの遅くない？」
「タップした瞬間、ワンテンポ遅れて反応する…！」

そんな “操作→画面反応までの遅さ” を測る指標が INP（Interaction to Next Paint） です。
INPはページ内の “もっとも遅い操作” がスコアになるため、
たった1つの重いイベント処理や、1つの第三者スクリプトが
全体の体験を悪く見せてしまうことがあります。

しかも原因は、表面では見えにくいものが多め。
・積み上がったイベントハンドラ
・初回相互作用前に競合してるJS
・重い第三者スクリプト
・hydration が一気に走るUI
こうした“裏側の詰まり”が、操作遅延として跳ね返ってきます。

本記事（後編）では、INP改善を
「遅い操作の特定 → ハンドラ削減 → スクリプト分離 → 読み込みの後ろ倒し」
という実務フローで整理します。

特定ライブラリ名などはぼかしつつ、
どのCMS・どのテーマでも再現できる汎用の設計型 に落とし込んでいます。

“操作した瞬間にスッと動くブログ” を目指すための
根本的な見直しポイントを、ここでまとめていきます！

本記事でわかること

INPの見つけ方（どの操作が遅いかを見抜く最短ルート）
録画しながら “最遅操作” を探す手順と、優先順位の付け方。
イベント処理の棚卸しとハンドラ軽量化
どの要素にイベントが積まれているかを洗い出し、
長い処理を分割して後ろ倒しする「軽量化の型」。
第三者スクリプトの分離・遅延・条件読み込み
よくある競合パターンと、
“必要なページだけ” 読み込むための運用方針。
初回相互作用までの最適化（CSS/JS/画像の役割分担）
クリティカルCSS、JSの優先度、LCP画像とのバランスなど、
「ユーザーが触る前にやらなくていい処理」を後ろにずらす方法。
小さく試して、改善を記録する運用テンプレ
Before→AfterのINPログを残すための表形式テンプレート付き。

“どこが詰まっているか分からない…” という状態から、
“ここを触ればINPが改善する” を見抜ける状態 へステップアップできる内容になっています。

どの操作が遅いかを特定する

INP改善は、まず 「どの操作が遅いのか？」 を pinpoint するところから始まります。
「ページが重い気がする…」という体感だけでは対策は当たりません。
INPは “最も遅い1回の操作” を拾う指標なので、
原因は意外な場所に潜んでいることも多いんです。

ここでは、最短で“詰まり”を見つけるための
観測の型と優先順位の付け方 をまとめていきます。

観測の型 — クリック/タップ・入力・開閉など操作ごとに録画し、最長レイテンシを探す

INPは「どの操作が遅いか」を特定しない限り改善できません。
そこで実務で定番なのが、“録画しながら操作する” という手法です。

▼ まずは「代表的な操作」を試す

ブログ運営者なら以下の操作が候補になります。

目次の開閉
アコーディオン
検索バーの入力
メニューの展開
コメント欄やフォームへの入力
記事中ボタン・リンクのタップ
サイドバーの開閉
モバイルメニューの表示

これらをひとつずつ操作し、
操作後から画面が動き始めるまでの“間（ま）” をチェックします。

INPで最遅の操作を特定する観測図。代表操作を録画し、タップ後の“間”からレイテンシの山を見つけて原因箇所に印を付ける。

▼ 録画すると“違和感の場所”が即わかる

操作を録画しておくと、

タップした直後に“固まる”一瞬
UIの反応がやけに遅い場所
JSがまとめて走っているタイミング

こうした “レイテンシの山” が一目で分かります。

▼ 最遅1回が INP になる

INPは平均値ではなく、
一番遅い1回が指標を引っ張る ため、
“そこだけ” 直せばスコアが劇的に改善することも珍しくありません。

優先順の付け方 — 露出×頻度×遅さで費用対効果を見積もる

「遅い操作がどれか特定した。でもどれから直す？」
——この段階で迷わないために、
改善の優先度を 露出×頻度×遅さ の3軸で判断します。

▼ 1. 露出（どれだけ多くの人が見るUIか）

モバイルのメインメニュー
記事上の目次
ファーストビューのボタン類
これらは露出が桁違いなので、遅いとINP全体に直撃します。

▼ 2. 頻度（1訪問あたり何回使われるか）

目次開閉は1記事で数回
コメント入力や検索は訪問者次第
メニュー開閉はモバイルで高頻度

「頻度が高いUI」は最遅操作を生みやすいため、優先度が高いです。

▼ 3. 遅さ（どのくらい固まるか）

録画すると、
「この操作だけワンテンポ遅い！」
という場所が必ず出てきます。

遅さは露骨にINPへ乗るため、
もっとも“モッサリ”している場所 が最優先。

▼ 優先順位の例（ブログ運営の典型パターン）

モバイルメニュー / 目次開閉（露出×頻度×遅さが高い）
記事上のタップ要素（シェア・いいね・ジャンプ系）
検索欄・フォーム入力
アコーディオン・関連記事の展開
ページ下部のUI（頻度が低め）

INP改善の優先度決定図。露出・頻度・遅さの3軸で候補UIを採点し、影響が大きい操作から直して再計測する流れを示す。

この順番で見直していくと、
“最遅1回”の候補をすばやく潰す ことができます。

イベント処理の軽量化

INPをもっとも悪化させるのは、
“重いイベント処理（Event Handler）” です。

クリック・タップ・入力・開閉など、
ユーザー操作の直後に実行される JS が詰まっていると、
画面が反応するまでワンテンポ止まる ―― まさに INP の悪化ポイント。

しかも、イベント処理はテーマやプラグインが“勝手に積み上げている”ことが多く、
表からは気づけないケースもあります。

ここでは、実務で再現しやすい
「イベントを軽量化するための棚卸し → 分割 → 再描画節約 → リスナ最適化」 の4ステップを解説します。

イベント処理でINPを改善する手順図。ハンドラ棚卸しと重複削除、重い処理の分割、DOM更新の集約、passive化でメインスレッド渋滞を減らす。

ハンドラの棚卸し — どの要素に何個付いているか（重複・バブリングの無駄）

まずは どの要素にイベントハンドラが付いているかを全て洗い出す ところから。

WordPressテーマやウィジェットを使っていると、
知らないうちに次のような状況が起きています：

同じ要素に クリックイベントが2つ以上 付いている
イベントが 親要素に似た内容で二重に 付いている
バブリング（伝搬）で 不要なハンドラが毎回発火 している
展開UIの処理が ページ全体に登録されている

これらは操作時に 無駄なJSが何度も走る 原因になります。

▼ 棚卸しで見るポイント

どの要素にどんなイベントが付いているか
同じ挙動を複数の場所で処理していないか
“全ページに発火するイベント” がないか
スクロール・リサイズなど重いイベントが多重登録されていないか

棚卸しが終わると、
「この処理、そもそも要らなかったのでは？」
という箇所が必ず出てきます。

処理の分割 — 長い関数を小分け、重い処理は後回し（遅延実行）

多くの“モッサリUI”は、イベントの中に
時間のかかる処理が丸ごと詰め込まれている のが原因です。

例：

大量のDOM操作
JSONの解析
画像・ウィジェットの生成
レイアウト計算の多重実行
サーバー通信を同期的に待つ処理

これらは イベント直後に全部やる必要はありません。

▼ 実務で使える分割の型

① 最低限だけ即処理、残りは setTimeout で後ろ倒し

ユーザーに反応を返す部分だけ最優先で実行し、
重い処理は「次のタイミング」で実行する方式。

② 必要になるまで処理しない（遅延/条件実行）

初めてクリックされた時だけ初期化
画面内に入った時だけ計算
該当ページでのみ読み込み

など、“必要な場面でだけ走る” ように分けます。

▼ 分割するとどう変わる？

イベント直後の負荷が軽くなるため、
「タップ→反応」が一気に軽くなる のを実感できます。

再描画の節約 — DOM操作のまとめ打ち／レイアウトスラッシングを避ける

JSで複数のDOM操作をすると、
ブラウザはそのたびに レイアウト計算（reflow） を行います。
この reflow の回数が多いほど、INPは悪化します。

特に危険なのは
レイアウトスラッシング（read → write → read → writeの繰り返し）
と呼ばれる状態。

例：
1つDOMを取得（read）
→ すぐスタイル変更（write）
→ 別要素の幅を計測（read）
→ またスタイル変更（write）

これだけでブラウザは何度もレイアウト計算を挟むため、
操作後の処理が急激に重くなります。

▼ 実務での対処法

DOMの取得と書き込みを それぞれまとめる
「計算→変更」を1サイクルで済ませる
レイアウトが必要な処理は requestAnimationFrame で1回に集約
不要なDOM操作を減らす（class追加で一括変更など）

▼ 効果は地味だが強力

扱いやすいテクニックですが、
複数箇所で改善すると INPが秒単位で改善 することもあります。

受動リスナ — スクロールやポインタ系は passive 前提で

スクロール・タッチ・ホイール系イベントは、
ブラウザの動作と密接に関わるため、ハンドラ内で重い処理があると
画面自体の“滑らかさ” に影響します。

特にスマホでは、
スクロールがカクつくと「反応が遅い」と強く感じられます。

▼ 対策：passive: true を基本に

スクロールイベントは
preventDefault() しない前提のイベント なので、
passive: true を付けておくとブラウザが最適化しやすくなります。

これだけでスクロール体験が軽くなり、
INPが改善するケースも多いです。

▼ スクロール監視は極力軽量に

Intersection Observer の活用
スロットリング・デバウンス
不要なスクロール計測の削除

これらも合わせて行うと、
「スクロールが重いUI」を根本から改善 できます。

第三者スクリプトの扱い

INPを悪化させる“裏側の犯人”として、
かなりの割合を占めるのが 第三者スクリプト（サードパーティJS） です。

解析ツール、シェアボタン、レコメンド、チャットウィジェット…。
便利だからといって積みすぎると、
ページの初期化が詰まり、操作→反応までが重くなる という典型パターンに。

しかも、第三者スクリプトは中身が見えないため、
「どこで何をしているか分からない」状態になりがちです。

ここでは、実務で再現しやすい
“分離 → 遅延 → 条件読み込み → 競合防止 → フォールバック” の型をまとめます。

第三者スクリプトでINPを悪化させない制御図。導入JSを一覧化し重複を削り、遅延・条件読み込みへ移行し、未読込でも体験が壊れない設計にする。

遅延/条件読込 — 初回相互作用後にロード、必要ページだけに限定

第三者スクリプトは、
“ページ表示直後” に読み込む必要がないものがほとんど です。
にもかかわらず、初期ロードにまとめて出してしまうため、
INPだけでなくLCPも悪化します。

▼ 原則：初回相互作用「後」にロードする

ユーザーが 初めてスクロールした瞬間
何か操作（タップ）が行われた瞬間
ページの主要処理が終わった後

このような“余裕のあるタイミング”で読み込むだけで、
INP改善への効果は非常に大きくなります。

▼ 条件読み込みの型

該当ページでだけ 読み込む（カテゴリ・記事タイプ別）
ユーザー操作があった時だけ 読み込む
モバイルでは読み込まない などのデバイス条件

「グローバルで常に読み込む必要があるスクリプト」はほぼありません。
“必要になったときだけ読み込む” が、INP視点では正解です。

競合の回避 — 同系ツールの二重読込をやめる（解析/シェア/計測など）

第三者スクリプトの本当に怖いところは、
知らないうちに似た機能が二重・三重で読み込まれていること です。

実際のブログ運用では、

テーマ側の解析＋自前で入れた解析
シェアボタンのJSがテーマとプラグインでかぶっている
計測タグを複数サービスが入れている
チャット/ポップアップ/レコメンド系が3本以上ある

こうした“カオス状態”はめずらしくありません。

▼ 二重読込が引き起こす問題

JSの初期化処理が倍増
似た監視処理が同時に動く
DOMの監視が重複して負荷が跳ね上がる
初回相互作用前にとんでもない量のJSが走る

結果、INPが2〜3倍遅くなる ことも普通にあります。

▼ 実務での解決ステップ

どんな第三者スクリプトが入っているか一覧化
役割が重複していないかチェック
どれが必須か、どれが“あると便利”かを仕分け
不要なものは削除 or 代替（軽量版へ差し替え）
残したスクリプトは遅延・条件読込へ移行

「入れっぱなしのJSを整理するだけ」で、
INPがごっそり改善することが本当に多いです。

フォールバック — 読み込めなくても体験が壊れない設計

第三者スクリプトは、
ネットワークの状態や提供元の都合で 読み込めない日もある という前提で考える必要があります。

読み込めなかった結果、

シェアボタンが押せない
お問い合わせフォームが開かない
コメント欄が固まる

といった“不具合”が発生すると、
読者体験が完全に壊れます。

▼ フォールバックの考え方（実務向け）

読み込めなくても 最低限のHTMLリンクは残す
機能しなかった場合の 静的な代替UI を置いておく
コメント欄などは ネイティブのフォームを併設
チャット/ポップアップは なくても記事が読める前提

「スクリプトが動かない時も破綻しない」設計は、

INPだけでなく 全体の安定性 に直結します。

第三者スクリプトの最適化は、
“削る→遅らせる→条件を付ける” の3段階が基本です。
これだけで INP の主要な詰まりが取れて、操作感が一気に軽くなります。

初回相互作用までの設計

INPは、“最遅の1回” を拾う指標です。
その最遅が生まれやすいのが、
ユーザーが最初に触れる直前〜直後のタイミング。

ページが完全に落ち着く前に、

CSS
JS
画像
ウィジェット
これらが一気に読み込みや初期化を始めると、
操作の反応が重くなるのは当然です。

ここでは、「最初の相互作用を軽くする」ための
CSS・JS・画像・hydrationの役割分担 を整理します。

初回相互作用を軽くする設計図。クリティカルCSSとLCP画像を優先し、不要JSを後回し、初期化を分散してタップ直後の反応遅延を防ぐ。

クリティカルCSSと分離 — 最初に必要なスタイルだけを先に

CSSは“軽い”と思われがちですが、
CSSの読み込みが終わるまで、ブラウザは描画を止めます。

つまり、無秩序にCSSを増やしていくと
「ページは見えてるけど操作はまだ重い」という状態に。

▼ 対策：クリティカルCSSと分離の2段構え

クリティカルCSS（最初に必要な範囲）だけインライン化
- ファーストビュー
- 主要見出し
- ナビゲーション
  必要最低限の装飾だけを先に読み込み、真っ先に安定させます。
残りのCSSは後ろで読み込み（遅延 or 非同期）
優先度を下げることで、初期化の渋滞を防げます。

▼ なぜINPが改善する？

CSSの読み込みが短いほど、
ユーザーが何かを操作する前にレイアウトが安定し、
初回反応の遅延が小さくなるためです。

画像とJSの優先度 — LCP画像は高優先度、JSは後回し

初回相互作用の重さは、
画像・JS の 読み込み競合 でも簡単に起きます。

▼ 原則：LCP画像は最優先、JSは後回し

LCP画像（最も大きい画像）
→ 高優先度で真っ先に読み込む
装飾的な画像/サムネ/アイコン
→ lazyload
初回操作に関係ないJS
→ defer や async
UI初期化が重いJS
→ インタラクション後に読み込む

▼ よく起きる失敗例

初期ロードで JS が全部走るため、
タップ直後に固まる
サイドバーやウィジェットのJSが、
ページ上部の画像より先に読みに行く
priority が誤って低く、
メイン画像が後回しになる

これらはすべて初回相互作用を重くする原因です。

hydrationの分散（概念） — まとめて初期化せず段階的に（細部はぼかし）

JSフレームワーク系のテーマやウィジェットは、
ページ表示直後に hydration（初期化） をまとめて行います。

この“初期化の一斉起動”が、
タップ直後の反応を丸ごと持っていく ことが多いです。

▼ 対策：初期化を分散させる（概念）

ファーストビュー付近のUIだけ先行初期化
下部コンテンツはスクロール後に初期化
モーダル・アコーディオンは操作された時に初期化
一気に hydration するのではなく、
“必要になる瞬間” にロード＆初期化

▼ なぜこれが効くのか？

初回相互作用の直前に
JS初期化がドバッと走る状態を避けられる ためです。

JSの束が小さくなるだけで、
反応速度は驚くほど軽くなります。

CSS・JS・画像・hydration。
この4つの“初手の動き”を整えるだけで、
「触った瞬間に動く」体験にぐっと近づきます。

運用・計測・ログ

INPを改善するうえで大切なのは、
“施策 → 計測 → 比較 → 横展開” の 小さなPDCA を回すことです。

INPは CLS と違い、
ユーザーの操作によって数値が揺れやすい指標 なので、
一回の計測だけで判断すると必ず迷います。

ここでは、改善をムダにしないための
運用の型・計測の型・ログの残し方 をまとめていきます。

小さく試す — 1ページで差を確認→横展開

INP改善は、いきなり全ページに適用するより
まず1つのページで実験してみる のが圧倒的に効率的です。

▼ 1ページ実験のメリット

変化の要因を特定しやすい
施策の“効き”が分かりやすい
テーマ全体を壊すリスクが小さい
成功したら、そのまま他ページに横展開できる

▼ 実験の流れ

計測用の1ページを決める
遅い操作（INPの原因）を特定
その操作にだけ対策を当てる
Before/After を比較
効果が出たら量産する

“小さく始める” が、実務ではほぼ必須の戦略です。

定点観測 — 数URLでINP/LCP/CLSの推移を記録

1回だけの測定は参考程度にしかなりません。
INPはブラウザ・ネットワーク・操作内容によって
日ごとの変動が大きい指標 だからです。

そこで有効なのが 「定点観測」。

▼ 定点観測のやり方

3〜5ページほどを“監視対象”にする
毎日 or 毎週、INP/LCP/CLSを一式記録
大きく変動した日があれば施策との因果関係をチェック
季節性・時間帯差もメモしておくと判断がラク

これで
「施策の効果」なのか「一時的な揺れ」なのか
が見極めやすくなります。

実務ログテンプレ

改善した内容は、必ず Before→After 形式で記録 しておきましょう。
後から「どれが効いたっけ？」と迷わず済みます。

▼ INP改善ログ（テンプレ）

ページ	施策（削除/分離/遅延）	操作種別	INP Before→After	備考
例：/article-01	モバイルメニューJSを遅延読込に変更	メニュー開閉	290ms → 110ms	体感も改善
	レコメンドJSを条件読込へ	スクロール	260ms → 180ms	他ページにも適用予定