Interaction to Next Paint - 処理時間

処理時間によって引き起こされるInteraction to Next Paint (INP) 問題

前回の記事ではinteraction to next paintについて、interaction to next paint問題の特定方法を説明しました。基礎について学びたい場合は、そちらを読むことをお勧めします。

この記事では「処理時間」に焦点を当てます。これがInteraction To Next Paint問題にどのように影響するか、そして処理時間を最小化してinteraction to next paintを改善する方法について説明します。

簡単に言うと：Interaction to Next Paint (INP)は、ユーザーがページとやり取りした後、視覚的な変化が表示されるまでにかかる時間を測定します。このINPは3つの要素に分解できます：「input delay」、「処理時間」、「presentation delay」です。処理時間は全体のINPの主要な要因であり、平均して遅延の約40%を占めています。これは、JavaScriptコード、特にイベントハンドラを最適化することで、ウェブサイトのINPスコアに大きな影響を与えることができることを意味します。

INPのヒント: 処理時間は、レイアウト更新に先立つ重要なコードを即座に実行し、その他すべてのコードをその後に実行するようにスケジュールすることで最適化できます。

処理時間とは？

Interaction to Newt Paint (INP)は3つのサブパートに分解できます：「Input Delay」、「処理時間」、「Presentation Delay」です。

処理時間とは、ユーザーがウェブページとやり取りした後（ボタンをクリックしたりキーを押したりするなど）、ブラウザが関連するイベントコールバックを処理するのにかかる時間を指します。処理時間は常に多少ありますが、INP問題はイベントコールバックの処理時間が長すぎる場合に発生します。

処理時間とINP

Interaction To Next Paintを最適化する際、処理時間が「重要なポイント」かもしれません。これはブラウザがレイアウトを更新する前に完了する必要がある「仕事」です。

多くの開発者は、コールバック関数の最適化（処理時間の最適化）という観点でINPの改善を考えており、それは正しいです。しかし重要度の観点では、処理時間は改善すべき最も重要な部分ではありませんが、それでも平均して全体のINP時間の約40%を占めています。

CoreDashでは、毎時数百万のCore Web Vitalsデータポイントを収集しています。そのデータに基づくと、処理時間はInteraction to Next Paintの40%を占めています。これは多いですが、処理時間だけを最適化してもINP問題を解決するには十分ではない可能性が高いです。

処理時間の例：ユーザーがボタンをクリックするなど、ウェブページとやり取りする場合、そのボタンクリックに関連付けられたイベントハンドラが実行を完了するまでにかかる時間を処理時間と呼びます。たとえば、ユーザーがフォームを送信するボタンをクリックした場合、フォームデータを検証し、サーバーに送信し、応答を処理するコードが処理時間に寄与します。これらの操作に時間がかかるほど、処理時間が長くなり、INPスコアが悪化する可能性があります。

処理時間が長くなる原因は何ですか？

処理時間の長さによって引き起こされるINP問題の修正を始めるには、処理時間が長くなる可能性のある原因を理解する必要があります。処理時間の長さ、つまりイベントコールバックが完了するまでの時間は、不要なコード、最適化されていないコード、クラスター化されたコールバック、レイアウトスラッシングによって引き起こされる可能性があります。これら4つの領域をより詳しく見てみましょう。

1. 不要なコード。古い、使用されていないコード、またはユーザーのやり取りとは直接関係のないコードは、コールバックの実行時間を延ばす可能性があります。
   
2. 最適化されていないコード。非効率的なコード（通常はループや非効率的なDOM参照）により、イベントコールバックが必要以上に遅く実行される可能性があります。
   
3. クラスター化されたコールバック：複数のイベントコールバックが近接してスケジュールされると、キューが作成されます。ユーザーのやり取りによってトリガーされたコールバックがこのキューで詰まると、応答が遅れているように見えます。
   
4. レイアウトスラッシング： レイアウトの再計算をトリガーする頻繁なDOM操作は、ブラウザに負担をかけ、パフォーマンスの低下につながる可能性があります。

処理時間を最小化する

処理時間を最小化するには、その後のレイアウト更新に関与するコードをできるだけ速く実行する必要があります。これを行うには、既存のコードを最適化し（不要なコードを削除し、現在のコードを最適化する）、レイアウト更新の前後に実行する必要があるコードを区別します。基本的に、レイアウト更新にとって重要なコードはその前に実行する必要があり、その他すべてのコードはレイアウト更新の後に実行できます。

1. 未使用のコードを削除する。未使用のコードの削除は当たり前のように思えるかもしれませんが、ほとんどのサイトには、ページやUXに何も追加せずに単に実行される古い未使用のコードが少なくともいくつかあります。つまり、最初にすべきことは、必要のないコードが実行されていないことを確認することです。これは多くの方法で実行できます。たとえば、ツリーシェイキングやコード分割と呼ばれるプロセスによって。または、Chromeでコードカバレッジを検査することによって手動で、また、未使用のコードをヒントする優れたIDEを使用することによって。（プロのヒント：Tag Managerによって読み込まれるリソースも批判的に見てください）
2. コールバックの実行時間を最小化する：JavaScriptプロファイラを使用してコードのボトルネックを特定し、それらの領域を最適化のターゲットにします。冗長な計算を避けるために、メモ化、事前計算、キャッシングなどの手法を検討してください。（ヒント：Chromeのパフォーマンスパネルを使用して、実行時間の長いスクリプトを見つけることができます！）
   
3. 重要なコードを優先し、他のコードをスケジュールする：コールバックコードが最適化されたら、すぐに実行する必要があるコードと延期できるコードにコードを分割します。この実例を見てください：
   
   この例では、Google Tag ManagerとFacebookイベントコールバックが、レイアウト更新に先立つ（REACT）コードの前に実行されます。解決策は、ブラウザがアイドル状態のときにGTMコールバックをスケジュールすることでした。
4. レイアウトスラッシングまたはリフローを避ける。レイアウトスラッシングは、スタイルの更新とスタイルの読み取りがループ内で混在する場合に発生し、ブラウザがレイアウトを何度も再計算します。
   レイアウトスラッシングを避けるには、スタイル値を要求する（「取得」）前に、すべてのスタイル変更（「設定」）を実行します。このアプローチにより、レイアウト更新の頻度が最小限に抑えられ、ウェブページが高速化されます。
   たとえば、各段落の幅を要素の幅に合わせて設定するループでは、ループの前に要素の幅を1回読み取り、その値を使用してループ内の段落の幅を更新します。

重要なコードを優先する方法

最後の項目「重要なコードを優先し、他のコードをスケジュールする」は、多くの人にとって少し抽象的かもしれません。requestIdleCallback()を使用し、メインスレッドに譲ることで、重要なコードを優先できます。

すぐに実行する必要のない、それほど重要でないタスクにはrequestIdleCallbackを使用します：GTMイベントをスケジュールする前後の例を次に示します。

/* 前 :: コードをすぐに実行  */
gtag('event', '', {
   'event_category': '',
 });

/* 後 :: ブラウザがアイドル中に同じコードを実行 */
requestIdleCallback(() => {
  gtag('event', '', {
    'event_category': '',
  });
}, { timeout: 1000 });

requestIdleCallbackの欠点は、コードが希望どおりにすぐに実行されない可能性があることです。その場合、最も重要なコードが実行された後に「メインスレッドに譲る」ことができ、そうすることでブラウザにレイアウト更新を実行する瞬間を与えます。メインスレッドに譲ることでタスクを分割する方法の例を次に示します。

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

async function handleClick(){
 // ここで最も重要なレイアウト更新を行う
 await yieldToMain();
 // レイアウト更新後にできるだけ早く実行する必要がある他のタスクを行う
}

将来的には、メインスレッドに譲るだけでなく、window.schedulerを使ってもっと多くのことができるようになるでしょう。scheduler APIを使用してタスクに優先順位を付けることもできます（サポート表を参照）。

scheduler APIは、優先度を設定することでタスクのより細かいスケジューリングのためのpostTask()関数を提供し、ブラウザが作業に優先順位を付け、優先度の低いタスクがメインスレッドに譲るのを助けます。

postTask()関数は3つの優先度設定を受け入れます：最も優先度の低いタスクには「background」、中程度の優先度のタスクには「user-visible」、高い優先度を必要とする重要なタスクには「user-blocking」です。

「user-blocking」で重要なタスクに優先順位を付けることで、開発者はそれらが高い優先度で実行されることを保証でき、ブラウザがユーザーのやり取りをより応答性高く処理できるようになります。scheduler APIは、優先度を設定することでタスクのより細かいスケジューリングのためのpostTask()関数を提供し、ブラウザが作業に優先順位を付け、優先度の低いタスクがメインスレッドに譲るのを助けます。

実用的な意味

最も重要な質問に行きましょう：「これは私のサイトにとって何を意味しますか」。処理時間に関してInteraction to Next Paintを改善する方法について、WordPress & REACTについて説明しましょう。

WordPress

WordPressはスクリプトに関して非常に少ない制御しか提供しません。多くのスクリプトはプラグインを通じて追加されます。ほとんどの場合、これらのスクリプトは、interaction to next paint (INP)を遅延させる以外に何もしない「イベントリスナー」をページに追加します。WordPressサイトが長い処理時間によって引き起こされるInteraction to Next Paintの問題を抱えている場合は、次の手順を実行してください：

• テーマ設定を確認してください。「スムーズスクロール」や「アニメーションメニュー」などの不要なオプションのチェックを外します。このような設定はINP問題を引き起こす傾向があります。
• どのスクリプトが長い処理時間の原因となっているかを確認してください（ヒント：Chromeのパフォーマンスパネルを使用してください）。それらのスクリプトがプラグイン関連である場合は、ほぼ同じことを行う別のプラグインを見つけることを検討してください。
• 多くの場合、カスタムスクリプトがページで実行されています。それらのスクリプトを確認し、メインスレッドに頻繁に譲り、重要度の低いコールバックをrequestIdleCallback関数でラップしていることを確認してください。
• ページごとに未使用のスクリプトをアンロードします（ヒント：wp_deregister_scriptを使用してください）。一部のプラグインは、機能が必要でない場合でもすべてのページにスクリプトを注入する傾向があります。
• Tag managerを確認し、未使用または不要なタグを削除してください。
• 軽量でクリーンなテーマを使用してください。多くの場合、「すべてを行う」多目的テーマは、より多くのスクリプトを持つ傾向があります。
• ページビルダーは避けてください。エンドユーザーにページを表示するためにJavaScriptに大きく依存していることが多いからです。

REACT / NextJS

Reactのフックと機能により、INP処理時間を削減することができます：

ReactのConcurrency機能でユーザーインタラクションを優先する：

バージョン16および18で導入されたReactのConcurrency機能は、特に入力中に、よりスムーズなユーザー体験のためにレンダリングを最適化するフックとメカニズムを提供します。

• useTransition & startTransition：重要でない更新を後でレンダリングするようにマークします。これにより、大規模な更新がユーザーのやり取りをブロックするのを防ぎます。
• useDeferredValue：UIを重要なセクションと重要度の低いセクションに分割します。Reactは、より応答性の高い体験のために、重要度の低い部分のレンダリングを中断できます。
• useOptimistic：非同期操作（ネットワークリクエストなど）が進行中の間、一時的で楽観的な状態を表示します。これにより、データ取得中もUIが応答性を保ちます。

データフェッチのためのSuspense（React 18+）：

React 18のSuspenseは、ブラウザがユーザーのやり取りを優先し、レンダリングを最適化できるようにすることで、INP（Interaction to Next Paint）を改善するために使用できます。React 16がコード分割のためにSuspenseを導入した一方で、React 18はこの機能をデータフェッチに拡張しています。

• ローディングインジケーターのようなフォールバックコンポーネントは、データがロードされている間表示されます。
  
• データが到着すると、Reactは一時停止されたコンポーネントのレンダリングを再開します。
• Concurrent ReactのSuspenseと中断可能なレンダリングを組み合わせることで、ユーザーのやり取りが優先されます。ユーザーが一時停止されたコンポーネントとやり取りする場合、Reactはそのコンポーネントのレンダリングを優先し、応答性を維持します。

全体として、これらの機能は連携して、Reactがユーザーのやり取りを優先し、更新やデータフェッチ中にUIをブロックしないようにします。