新しい INP 指標が、JavaScript フレームワークとライブラリを使用して構築されたサイトのエクスペリエンスにどのように影響するかをご確認ください。
Chrome では最近、Chrome UX レポート レポートに新しい応答性に関する試験運用版の指標が導入されました。この指標は、Interaction to Next Paint（INP）という名称で、ページでのユーザー インタラクションに対する全体的な応答性を測定するものです。本日は、この指標に関連して、最新の JavaScript フレームワークを使用して構築されたウェブサイトがどのような位置にあるのかについての分析情報を共有します。INP がフレームワークに関連する理由と、Aurora とフレームワークがどのように応答性の最適化に取り組んでいるかについて説明します。
背景
Chrome では Core Web Vitals（CWV）の一部として、First Input Delay（FID）を使用してウェブサイトの読み込み応答性を測定します。FID は、最初のユーザー操作から、その操作に接続されているイベント ハンドラをブラウザが処理できるようになるまでの待ち時間を測定します。これには、イベント ハンドラの処理、同じページの後続のインタラクションの処理、イベント コールバックの実行後に次のフレームのペイントを行う時間は含まれません。しかし、ユーザーはページの読み込み後の滞在時間の約 90% を費やすため、ページのライフサイクル全体を通じて応答性を維持することが極めて重要になります。
INP は、ユーザーが操作を開始してから次のフレームが画面に描画されるまでに、ウェブページがユーザー操作に応答するまでの時間を測定します。Google は、INP を使用して、ページのライフサイクルにおけるすべてのインタラクションで認識されるレイテンシを集約して測定できるようにしたいと考えています。Google では、INP の方がウェブページのより正確な推定値を提供できると考えています。ランタイムの応答性が向上します
FID では最初のインタラクションの入力遅延のみが測定されるため、ウェブ デベロッパーは CWV 改善プロセスの一環として後続のインタラクションを事前に最適化していない可能性があります。そのため、サイト、特にインタラクティビティが高いサイトでは、この指標がうまく機能するように努力する必要があります。
フレームワークの役割
多くのウェブサイトは JavaScript を使用してインタラクティビティを実現しているため、INP スコアは主にメインスレッドで処理される JavaScript の量の影響を受けます。JavaScript フレームワークは、最新のフロントエンド ウェブ開発に不可欠な要素であり、JavaScript コードのルーティング、イベント処理、区分け化において有用な抽象化をデベロッパーに提供します。つまり、コンテナを使用するウェブサイトの応答性とユーザー エクスペリエンスを最適化するうえで中心的な役割を果たします。
フレームワークは、早い段階でウェブサイトの FID を改善することで、応答性を向上させる措置を講じている可能性があります。しかし、今は利用可能な応答性の指標データを分析し、特定されたギャップの解消に取り組む必要があります。一般的に、INP は合格率が低くなる傾向があり、測定プロセスの違いにより、追加のコード最適化が必要になります。次の表にその理由をまとめます。
Chrome の Aurora チームは、オープンソースのウェブ フレームワークと連携して、デベロッパーがパフォーマンスや CWV 指標など、ユーザー エクスペリエンスのさまざまな側面を改善できるよう支援しています。INP の導入に伴い、フレームワーク ベースのウェブサイトの CWV 指標の変化に備えています。CrUX レポートで試験運用版の応答性指標に基づいてデータを収集しました。フレームワーク ベースのウェブサイトの INP 指標への移行を容易にするインサイトとアクション アイテムを共有します。
試験運用版の応答性指標データ
INP が 200 ミリ秒以下は、応答性が良いことを示します。2023 年 6 月の CrUX レポートデータと CWV Technology Report から、一般的な JavaScript フレームワークの応答性について次の情報が得られています。
この表は、応答性スコアが良好である各フレームワークのオリジンの割合を示しています。数字からも好意的ですが、まだ改善の余地はたくさんあることがわかります。
JavaScript は INP にどのように影響しますか？
フィールドの INP 値は、ラボで観察された合計ブロック時間（TBT）とよく相関しています。これは、メインスレッドを長時間ブロックするスクリプトは INP に適していないことを示唆している可能性があります。なんらかの操作の後に JavaScript を実行すると、メインスレッドが長時間ブロックされ、その操作に対するレスポンスが遅れる可能性があります。スクリプトをブロックする一般的な原因は次のとおりです。
最適化されていない JavaScript: 冗長なコード、不適切なコード分割、読み込み方法が原因で、JavaScript が肥大化してメインスレッドが長時間ブロックされることがあります。コード分割、プログレッシブ読み込み、長いタスクの分割により、応答時間を大幅に短縮できます。
第三者スクリプト: 第三者スクリプトはインタラクションの処理には不要な場合があるため（広告スクリプトなど）、メインスレッドをブロックして不要な遅延を発生させることがあります。重要なスクリプトを優先することで、サードパーティ スクリプトによる悪影響を軽減できます。
複数のイベント ハンドラ: それぞれの操作に関連付けられた複数のイベント ハンドラがそれぞれ異なるスクリプトを実行する場合、互いに干渉し合い、長い遅延を引き起こす可能性があります。これらのタスクの一部は必須ではなく、ウェブ ワーカーでスケジュールしたり、ブラウザがアイドル状態のときにスケジュールしたりできます。
イベント処理のフレームワークのオーバーヘッド: フレームワークには、イベント処理のための追加の機能や構文がある場合があります。たとえば、Vue は v-on を使用してイベント リスナーを要素にアタッチしますが、Angular はユーザー イベント ハンドラをラップします。これらの機能を実装するには、標準の JavaScript よりも上のフレームワーク コードを追加する必要があります。
ハイドレーション: JavaScript フレームワークを使用する際、サーバーがページの最初の HTML を生成することは珍しくありません。HTML ページをウェブブラウザで操作できるように、イベント ハンドラやアプリケーションの状態を使って拡張する必要があります。私たちはこのプロセスを水分補給と呼んでいます。JavaScript の読み込みとハイドレーションの終了にかかる時間によっては、読み込み時に負荷の高いプロセスになる可能性があります。また、操作していないのにインタラクティブであるかのように見える場合もあります。ハイドレーションは多くの場合、ページの読み込み中や遅延（ユーザーの操作時など）に自動的に発生し、タスクのスケジューリングによって INP や処理時間に影響を与える可能性があります。React などのライブラリでは、
useTransitionを活用して、コンポーネントのレンダリングの一部を次のフレームに配置し、コストのかかる副作用を将来のフレームに残すことができます。したがって、クリックのような緊急の更新につながるような遷移中の更新は、INP に適したパターンになり得ます。プリフェッチ: 以降のナビゲーションに必要なリソースを積極的にプリフェッチすると、パフォーマンスの向上につながる可能性があります。ただし、SPA ルートを同期的にプリフェッチしてレンダリングすると、高コストのレンダリングがすべて 1 つのフレームで完了するため、INP に悪影響が及ぶ可能性があります。これとは対照的に、ルートをプリフェッチせず、代わりに必要な処理（
fetch()など）を開始し、ペイントのブロックを解除します。プリフェッチに対するフレームワークのアプローチが最適な UX を実現しているかどうかと、それが INP にどのような影響を与えるか（ある場合）は、再確認することをおすすめします。
今後、INP スコアを高くするには、デベロッパーがページでのあらゆるインタラクションの後に実行されるコードの確認に集中し、チャンク、リハイドレーション、読み込み戦略、ファーストパーティとサードパーティのスクリプトの両方について、Render() の各アップデートのサイズを最適化する必要があります。
Aurora とフレームワークは INP の問題にどのように対処していますか？
Aurora は、ベスト プラクティスを組み込んでフレームワークと連携することで、一般的な問題に対する組み込みソリューションを提供します。Google は、Next.js、Nuxt.js、Gatby、Angular と協力して、フレームワーク内で強力なデフォルトを提供し、パフォーマンスを最適化するソリューションを開発してきました。この状況における Google の取り組みの要点を以下に示します。
React と Next.js: Next.js Script コンポーネントは、サードパーティ スクリプトの非効率的な読み込みが原因で発生する問題に対処するのに役立ちます。Next.js できめ細かなチャンクが導入され、共有コードを小さなチャンクサイズにできるようになりました。これにより、すべてのページでダウンロードされる未使用の共通コードの量を減らすことができます。また、Next.js を使用して、INP データを Analytics サービスの一部として利用できるように取り組んでいます。
Angular: Aurora は Angular チームと連携し、サーバー側のレンダリングとハイドレーションの改善に取り組んでいます。また、INP を改善するために、イベント処理と変更検出の改善も計画しています。
Vue と Nuxt.js: Google は主にスクリプトの読み込みとレンダリングに関連するコラボレーション手段を模索しています。
フレームワークは INP の改善についてどのように考えていますか？
React と Next.js
startTransition と Suspense を通じて実装される React.js のタイム スライシングを使用すると、選択的または段階的なハイドレーションにオプトインできます。つまり、ハイドレーションは同期ブロックではありません。任意の時点で割り込み可能な小さなスライスで行われます。
これにより、INP が改善され、キー入力、遷移中のマウスオーバー効果、クリックに、より迅速に対応できるようになります。また、予測入力などの大規模な遷移が発生しても React アプリの応答性を維持できます。
Next.js は、ルートの遷移にデフォルトで startTransition を使用する新しいルーティング フレームワークを実装しました。これにより、Next.js サイト所有者は React タイム スライシングを導入し、ルート遷移の応答性を向上させることができます。
Angular
Angular チームは、INP に役立つアイデアをいくつか検討しています。
- ゾーンレス: 初期バンドルサイズを削減します。また、アプリでレンダリングする前に読み込む必要のあるコードを削減します。
- ハイドレーション: アイランド スタイルのハイドレーション機能で、操作のために起動する必要があるアプリの量を制限します。
- CD のオーバーヘッドを削減する: たとえば、変更検出のコストを低く抑えたり、アプリのチェックを減らす方法を見つけたり、何が変更されたかに関する受動的なシグナルを活用したりします。
- より粒度の細かいコード分割: 最初のバンドルを小さくします。
- インジケーターの読み込みのサポートを強化:: SSR の再レンダリング時、ルート ナビゲーション時、遅延読み込みオペレーションなど。
- プロファイリング ツール: 操作費用（特に特定の操作の変更検出費用に関連する）を把握できる優れた開発ツール。
こうした機能強化により、応答性やユーザー エクスペリエンスの低下につながるさまざまな問題に対処し、フレームワーク ベースのウェブサイトの CWV 指標と新しい INP 指標を向上させることができます。
まとめ
INP スコアは、ウェブサイトの応答性とパフォーマンスの向上に役立つ優れたコンパスを今後提供するものと期待しています。2023 年は、既存の INP ガイドをベースに、フレームワーク デベロッパー向けに実用的なヒントを提供する予定です。Google は、以下の方法でこれを実現したいと考えています。
- フレームワークとウェブ デベロッパーが INP のフィールド データに簡単にアクセスするためのチャネルを作成する。
- フレームワークと連携して、デフォルトで INP を改善する機能を構築する。
INP の最適化に着手したフレームワーク ユーザーからのフィードバックをぜひお寄せください。