要約: Extensions API は、バックフォワード キャッシュをサポートするよう更新されました。 ナビゲーションをプリロードできます。詳しくは以下をご覧ください。
Chrome は、ナビの高速化に取り組んできました。インスタント ナビゲーション バックフォワード キャッシュなどのテクノロジー （リリース: パソコン、 Chrome 96）と推測ルール （Chrome 103 でリリース）で前後の両方を改善 体験できますこの投稿では、ブラウザに加えられた更新内容をご紹介します。 拡張 API を開発し、これらの新しいワークフローに対応しました。
ページの種類について
バック/フォワード キャッシュと事前レンダリングを導入する前は、 タブにアクティブなページが 1 つしか含まれていなかった。これは常に見えていたものでした。もし ユーザーが前のページに戻ると、アクティブなページは破棄されます（ページ B） 履歴内の前のページが完全に再構成されます（ページ A）。 拡張機能では、ライフサイクル ページのどの部分が管理されていなくてもよい 1 つのタブに対してアクティブ/表示状態の 1 つしかないためです。
<ph type="x-smartling-placeholder">
バックフォワード キャッシュと事前レンダリングを使用すると 1 対 1 ではなくなる タブとページの関係などです各タブには実際には複数の ページやページは、破棄されるのではなく、状態間で遷移します。 あります。
たとえば、あるページが事前レンダリングされた（非表示の）ページとしてスタートし、 ユーザーがリンクをクリックすると、アクティブな（表示可能な）ページに遷移し、 ユーザーが次に移動したときに、バックフォワード キャッシュに格納される（非表示） そのページが破棄されることはありません。後述 拡張機能が何なのかを把握できるように 新しく公開されたプロパティについて説明します 把握できます
<ph type="x-smartling-placeholder">
なお、1 つのタブには、1 つだけでなく複数の事前レンダリングされたページ、1 つのページ、 active（表示可能）ページ、一連のバックフォワード キャッシュ ページ。
拡張機能のデベロッパー向けの変更点
FrameId == 0（フレーム ID == 0）
Chromium では、最上位フレーム（メインフレーム）を最も外側のフレームと呼びます。
frameId を前提とする拡張機能作成者
が 0 の場合（以前のベスト プラクティス）に問題が生じる可能性があります。
1 つのタブに、最も外側の複数のフレーム（事前レンダリングおよびキャッシュ済み）を設定できるようになったため
最外層に 1 つのページがあるという前提で、
正しくないタブです。frameId == 0 が引き続き表示されます
アクティブ ページの最も外側のフレームですが、
同じタブ内の他のページはゼロ以外になります。新しいフィールド frameType は次のとおりです。
この問題を解決するために追加されました。「最も外側のフレームかどうかを判断するにはどうすればよいですか？」をご覧ください。
ご覧ください。
フレームとドキュメントのライフサイクル
拡張機能で問題となるもう 1 つの概念は、 クリックします。フレームはドキュメント（コミットされた URL に関連付けられたドキュメント）をホストします。 ドキュメントは変更できますが（ナビゲーションなど）、frameId は変更されないため、 特定のドキュメントで何かが発生したことを、 frameIds のみ）。documentId のコンセプトを導入しています。 これは各ドキュメントの一意の識別子ですフレームが移動して ID が変更される新しいドキュメントが開きます。このフィールドは ページのライフサイクルの状態が prerender/active/cached など）は変更されないためです。
ウェブ ナビゲーション イベント
chrome.webNavigation 名前空間のイベント
1 回のリクエストで複数回
同じページで表示されます詳しくは、
「ページのライフサイクルはどのようにわかるのですか？」
と「ページが移行したタイミングを判断するにはどうすればよいですか？」のセクションも参照してください。
ページのライフサイクルを確認するにはどうすればよいですか？
DocumentLifecycle
タイプが frameId でしたが、いくつかの拡張機能 API に
使用できます。イベントに DocumentLifecycle タイプが存在する場合
（onCommitted など）
その値はイベントが生成された状態です。いつでもクエリを実行できます
WebNavigation（getFrame()）からの情報
および getAllFrames()
メソッドですが、常にイベントの値を使用することが推奨されます。もし
どちらの方法でも、フレームの状態がイベント発生時と
両方のメソッドによる Promise の戻り値が解決された時点で生成されます。
DocumentLifecycle
次の値があります。
"prerenderインチ: 現時点ではユーザーには表示されていませんが、ユーザーに表示される可能性がある状態になっています。"active": 現在ユーザーに表示されます。"cached": バック フォワード キャッシュに保存されます。"pending_deletion": ドキュメントは破棄中です。
最も外側のフレームであるかどうかを確認するにはどうすればよいですか？
以前の拡張機能では、frameId == 0
最も外側のフレームでイベントが発生したかどうか。複数ページ
タブには最も外側のフレームが複数あるので、frameId の定義で
問題があります。バックフォワード キャッシュに関するイベントを受信しなくなる
クリックします。ただし、事前レンダリングされたフレームの場合、frameId は
指定することもできます。そのため、frameId == 0 を
最も外側のフレームが間違っているかどうかを判断します。
これに対処するために、
FrameType
そのため、そのフレームが本当に最も外側のフレームかどうかを判断することは簡単です。
FrameType の値は次のとおりです。
"outermost_frame": 通常、最上位フレームと呼ばれます。注: その倍数があります。たとえば 事前レンダリングとキャッシュに 各ページには、最上位フレームと呼ばれる外側のフレームがあります。"fenced_frame": 将来の使用のために予約されています。"sub_frame": 通常は iframe です。
DocumentLifecycle を FrameType と組み合わせることで、フレームが
最も外側のアクティブなフレームです。次に例を示します。
tab.documentLifecycle === “active” && frameType === “outermost_frame”
フレームの使用時間の問題を解決するにはどうすればよいですか？
前述したように、フレームはドキュメントをホストし、そのフレームが新しいドキュメントに移動する場合がある
frameId は変更されません。この方法では、
イベントを受信したときに frameId のみです。URL を確認した場合
イベントの発生時刻とは異なる場合があります。これは、
使用時間の問題です
これに対処するために、documentId を導入しました。
（および parentDocumentId）。
webNavigation.getFrame()
メソッドにより、documentId が指定されている場合に frameId がオプションになりました。「
documentId はフレームが移動されるたびに変更されます。
ページが遷移するタイミングを判断するにはどうすればよいですか？
ページがステータス間で遷移するタイミングを判断するための明示的なシグナルがあります。
WebNavigation イベントを見てみましょう。
どのページでも最初のナビゲーションでは、4 つのイベントが順番に表示されます。
下の一覧をご覧ください。なお、この 4 つのイベントは、
DocumentLifecycle 状態は "prerender" または "active" です。
onBeforeNavigate
onCommitted
onDOMContentLoaded
onCompleted
下の図では、documentId の変更を示しています。
事前レンダリングされたページがアクティブなページになると "xyz" に設定されます。
documentId
表示されます。ページがバックフォワード キャッシュまたは事前レンダリングから
アクティブ状態にはさらに 3 つのイベントがあります（ただし、DocumentLifecyle
"active" です）。
onBeforeNavigate
onCommitted
onCompleted
documentId は元のイベントと同じままです。これは、
documentId == xyz を有効にすると、上の図のようになります。なお、
同じナビゲーション イベントが発生する（onDOMContentLoaded を除く）
イベントがトリガーされます。
ご意見やご質問がございましたら、 Chromium の拡張機能 できます。