A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://developer.mozilla.org/ja/docs/Web/API/Speculation_Rules_API below:

投機ルール API - Web API

投機ルール API

Experimental: これは実験的な機能です。
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

投機ルール API (Speculation Rules API) は、将来のナビゲーションのパフォーマンスを向上させるように設計されています。これは特定のリソースファイルではなく文書 URL を対象とするので、マルチページアプリケーション (MPA) で意味がありますが、単一のページアプリケーション (SPA) では意味がありません。

投機ルール API は、広く利用できる <link rel="prefetch"> 機能の代替となるもので、 Chrome のみの非推奨である <link rel="prerender"> 機能を置き換えるようにも設計されています。先読みされる文書や事前レンダリングされる文書を指定するための、より表現力があり構成しやすい構文とともに、これらの技術に対して多くの改善点を提供します。

メモ: 投機ルール API はサブリソースの先読みを処理しません。そのためには <link rel="prefetch"> を使用する必要があります。

概念と使用方法

投機ルールは、インラインの <script type="speculationrules"> 要素の中と、 Speculation-Rules レスポンスヘッダーで参照される外部テキストファイルで指定することができます。ルールは JSON 構造で指定します。

スクリプトの例を示します。

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": {
          "and": [
            { "href_matches": "/*" },
            { "not": { "href_matches": "/logout" } },
            { "not": { "href_matches": "/*\\?*(^|&)add-to-cart=*" } },
            { "not": { "selector_matches": ".no-prerender" } },
            { "not": { "selector_matches": "[rel~=nofollow]" } }
          ]
        }
      }
    ],
    "prefetch": [
      {
        "urls": ["next.html", "next2.html"],
        "requires": ["anonymous-client-ip-when-cross-origin"],
        "referrer_policy": "no-referrer"
      }
    ]
  }
</script>

<script> 要素を使用した投機ルールは、サイトにされている場合、 Content-Security-Policy の script-src ディレクティブで明示的に許可する必要があります。これは、 'inline-speculation-rules' のソース、ハッシュソース、ノンスソースのいずれかを追加することで行います。

HTTP ヘッダーの例を示します。

Speculation-Rules: "/rules/prefetch.json"

投機ルール JSON を含むテキストリソースは、任意の有効な名前と拡張子を持つことができますが、MIME タイプ application/speculationrules+json で提供する必要があります。

メモ: ルールは、インラインスクリプトと HTTP ヘッダーの両方を同時に使用して指定することができます。文書に適用されるすべてのルールが解析され、その文書の投機ルールリストに追加されます。

投機的読み込みの種類（"prerender" や "prefetch" など）ごとに、ルールを格納する配列を指定します。各ルールはオブジェクトに格納されており、例えば取得するリソースのリストと、各ルールに対する明示的な Referrer-Policy 設定などのオプションを指定します。事前レンダリングされた URL も先読みされることに注意しましょう。

利用可能な構文の全般的な説明は、 <script type="speculationrules"> を参照してください。

先読みの使用

prefetch ルールを <script type="speculationrules"> 要素または Speculation-Rules の中に含めると、対応しているブラウザーは参照するページのレスポンス本体はダウンロードしますが、ページが参照しているサブリソースはダウンロードしません。先読みされたページに移動した場合、先読みされなかった場合よりもはるかにすばやくレンダリングされます。

結果は文書ごとにメモリー内のキャッシュに保存されます。先読みがキャッシュされたものは、現在のページから移動した時点で、移動先の先読み文書を除いて破棄されます。

これは、ユーザーが移動しないものが先読みされた場合、ヘッダーが許可していれば HTTP キャッシュに結果が入るかもしれませんが、一般的にはリソースの無駄になることを意味しています。とはいえ、先読みのコストは事前レンダリングのコストよりもずっと小さいので、先読みを広く導入することが推奨されます。例えば、サイト上の重要なページをすべて先読みすることが推奨されます（詳しくは、安全でない投機的負荷条件を参照してください）。

同一サイトおよびサイト間の先読みは動作しますが、サイト間の先読みは制限されます（両者の違いの説明は "same-site "と "cross-site" を参照してください）。プライバシーの理由から、サイト間での先読みは、現在のところ、ユーザーが出力先のサイトにクッキーを設定しない場合にのみ動作します。サイトが前回設定されたクッキーに基づいて、先読みされたページ（実際には一度も訪問していないかもしれません）を通してユーザーの活動を追跡できるようになることは望ましくありません。

メモ: 将来的には Supports-Loading-Mode ヘッダーでサイトをまたぐ先読みのオプトインが提供される予定ですが、執筆時点では実装されていません（オリジンをまたぐ、同一サイトの事前レンダリングのオプトインのみが利用できました）。

投機ルールの先読みに対応しているブラウザーでは、古い先読み機構、すなわち <link rel="prefetch"> や fetch() に priority: "low" オプションを設定します。なぜなら、投機ルールの先読みはナビゲーションのためのものであり、一般的なリソースの先読みではないからです。

さらに、投機ルールの先読みには次のような特徴があります。

事前レンダリングの使用

prerender ルールを <script type="speculationrules"> 要素または Speculation-Rules ヘッダーに入れると、対応しているブラウザーはコンテンツを取得し、レンダリングし、非表示のタブに読み込んで文書ごとのメモリー内キャッシュに格納します。これには、すべてのサブリソースの読み込み、すべての JavaScript の実行、さらには JavaScript によって開始されるサブリソースの読み込みとデータ取得の実行が含まれます。キャッシュされた事前レンダリングとそのサブリソースは、現在のページから離れると破棄されます。もちろん、移動先が事前レンダリングされたドキュメントである場合を除きます。

事前レンダリングされたページへの今後のナビゲーションは、ほぼ瞬時に行われます。ブラウザーは通常のナビゲーションプロセスを実行する代わりに非表示のタブをアクティブにし、既存の表示ページを事前レンダリングされたページに置き換えます。ページが完全に事前レンダリングされる前にアクティブ化された場合、そのページは現在の状態でアクティブ化され、引き続き読み込みが行われます。

事前レンダリングは、メモリとネットワーク帯域幅を使用します。事前レンダリングされたコンテンツにユーザーが移動しない場合、これらは無駄になります（ただし、ヘッダーが許可していれば結果は HTTP キャッシュに保存され、後で使用することができるかもしれません）。事前レンダリングの先行コストは、先読みよりもずっと大きくなります。また、その他の条件により、コンテンツを事前レンダリングするのが安全でなくなることもあります（詳しくは、安全でない投機的読み込み条件を参照してください）。そのため事前レンダリングは、ユーザーがそのページに移動する可能性が高く、ユーザーの体感的な利点が余分なコストに見合うと考えられるようなケースを慎重に考慮し、控えめに採用することが推奨されます。

メモ: 潜在的なリソースの浪費を考慮すると、事前レンダリングされた場合、 <iframe> をレンダリングするのとほぼ同じ量のリソースを使用します。

メモ: 多くの API は、事前レンダリング時もしくは有効化されるまで、自動的に延期されます。詳しくは事前レンダリング中に延期または制限されるプラットフォーム機能を参照してください。

事前レンダリングされた文書は、既定では同一オリジンの文書に制限されています。異なるオリジンであっても、同じサイトの事前レンダリングは可能です。そのためには、 Supports-Loading-Mode ヘッダーに credentialed-prerender という値を指定して、ナビゲーションターゲットがオプトインする必要があります。現時点では、異なるサイトの事前レンダリングはできません。

対応しているブラウザーでは、投機ルールの事前レンダリングは古い事前レンダリングの仕組み、いわゆる <link rel="prerender"> よりも優先されるべきです。

投機ルール API の機能検出

投機ルール API に対応しているかどうかは、以下のコードで確認できます。

if (
  HTMLScriptElement.supports &&
  HTMLScriptElement.supports("speculationrules")
) {
  console.log("お使いのブラウザーは投機ルール API に対応しています。");
}

例えば、対応しているブラウザーでは先読みのための投機ルールを挿入したいが、他のブラウザーでは <link rel="prefetch"> のような古い技術を使いたい場合は次のようにします。

if (
  HTMLScriptElement.supports &&
  HTMLScriptElement.supports("speculationrules")
) {
  const specScript = document.createElement("script");
  specScript.type = "speculationrules";
  const specRules = {
    prefetch: [
      {
        source: "list",
        urls: ["/next.html"],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  document.body.append(specScript);
} else {
  const linkElem = document.createElement("link");
  linkElem.rel = "prefetch";
  linkElem.href = "/next.html";
  document.head.append(linkElem);
}
先読みおよび事前レンダリングされたページの検出

この節では、リクエストされたページが先読みまたは事前レンダリングされたかどうかを検出するさまざまな方法を見ていきます。

サーバー側での検出

先読みまたは事前レンダリングのページリクエストは、 Sec-Purpose リクエストヘッダーが付きます。

先読みの場合:

事前レンダリングの場合:

Sec-Purpose: prefetch;prerender

サーバーは、このヘッダーに基づいて応答し、例えば、投機的な読み込みリクエストをログに記録したり、異なるコンテンツを返したり、投機的な読み込み自体を防止したりすることができます。成功ではないレスポンスコード（リダイレクト後の 200~299 以外の HTTP ステータス）が返された場合、ページは先読み/事前レンダリングされません。さらに、204 および 205 のステータスコードも事前レンダリングを禁止します （ただし、先読みは禁止しません）。

サーバー側で投機的な読み込みを禁止する最も簡単な方法は、失敗コード（例えば 503）を使用することです。ただし、通常は、先読み/事前レンダリングを許可し、ページが実際に表示されたときにのみ実行すべきアクションは、 JavaScript を使用して遅延させた方が良い手法です。

JavaScript による先読みの検出

ページが先読みされると、その PerformanceResourceTiming.deliveryType 項目は "navigational-prefetch" という値を返します。以下は "navigational-prefetch" 型のパフォーマンス項目を受け取ったときに関数を実行するために使用することができます。

if (
  performance.getEntriesByType("navigation")[0].deliveryType ===
  "navigational-prefetch"
) {
  respondToPrefetch(); // 作者定義の関数
}

このテクニックは、パフォーマンスを測定するときや、 先読み中に発生すると問題を引き起こす可能性のあるアクションを 延期したいときに有益です（安全でない先読み を参照してください）。

JavaScript による事前レンダリングの検出

ページが事前レンダリングされている際にアクティビティを実行するには、 Document.prerendering プロパティを調べるとよいでしょう。例えば、分析に使用することができます。

if (document.prerendering) {
  analytics.sendInfo("事前レンダリングでここまで取得しました。");
}

事前レンダリングされた文書がアクティブになると、 PerformanceNavigationTiming.activationStart には、事前レンダリングを始めてから実際に文書がアクティブになるまでの時間を表す DOMHighResTimeStamp が設定されます。以下の関数は、ページが事前レンダリング中または事前レンダリング済みであることを調べることができます。

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.("navigation")[0]?.activationStart > 0
  );
}

事前レンダリングされたページがページを閲覧しているユーザーによってアクティブにされると、prerenderingchangeイベントが発生します。これは、以前はページ読み込み時に既定で開始されていたアクティビティを、ページがユーザーによって表示されるまで遅らせたい場合に使用することができます。以下のコードは、事前レンダリングされたページで、事前レンダリングが完了したら関数を実行する、または事前レンダリングされていないページですぐに関数を実行するイベントリスナーを設定します。

if (document.prerendering) {
  document.addEventListener("prerenderingchange", initAnalytics, {
    once: true,
  });
} else {
  initAnalytics();
}
安全でない投機的読み込み条件

この節では、先読みと事前レンダリングが 安全でない 条件に注目していきます。これは、これらの条件を示すページの先読み/事前レンダリングは、コードの緩和を要求されるか、完全に避ける必要があることを意味しています。

安全でない先読み

前述したように、先読みすることによるリスクとリターンの比率はかなり低く、リソースの浪費の可能性は最小であり、性能の向上も大きいため、私たちは先読みを広く採用することを推奨します。しかし、先読みされるページがアプリケーションのフローに問題を発生させないようにする必要があります。

先読みが行われると、ブラウザーは参照したページのレスポンス本体を単一の GET リクエストでダウンロードします。特に問題が発生しやすいのは、リクエストの URL が、その URL に移動するまでは起こってほしくない、サーバー主導の副作用を引き起こす場合です。

例えば次のようなものです。

このような問題は、リクエストが来たときに Sec-Purpose: prefetch ヘッダーを監視し、問題のある機能を延期する固有のコードを実行することで、サーバー上で軽減することができます。その後、ページが実際に移動されたときに、必要であれば JavaScript で延期された機能を起動することができます。

メモ: 検出コードの詳細は、先読みおよび事前レンダリングされたページの検出の節にあります。

また、サーバーがレンダリングした文書が、ユーザーが現在のページで取り得る操作によってコンテンツが変化するような文書を先読みすることは、潜在的に危険です。例えば、フラッシュセールのページや映画館の座席地図などです。このようなケースを注意深くテストし、ページが読み込まれたらコンテンツを更新することで、このような課題を軽減してください。これらのケースの詳細については、状態の変化をサーバー側でレンダリングする場合を参照してください。

メモ: ブラウザーは先読みされたページを破棄する前に短時間キャッシュします（例えば Chrome は 5 分間キャッシュします）ので、どのような場合でもユーザーは最大 5 分前のコンテンツを見ることになります。

JavaScript はアクティブになるまで実行されないため、ページを取得することによる副作用がすべて JavaScript の実行によるものである場合、先読みは安全です。

最後のヒントは、 robots.txt ファイルに許可されていないとして掲載されている URL を監査することです。通常、この URL は認証されたユーザーのみがアクセスできるページを指しているため、検索エンジンの検索結果に含めることができません。これらの多くは問題ないでしょうが、先読みされるのに安全でない（つまり記述されている条件を示している） URL を探すのに良い場所となります。

安全でない事前レンダリング

事前レンダリングは、先読みよりも導入リスクが高いため、それを行う価値がある場合にのみ、控えめに行うべきです。事前レンダリングには、注意すべき安全でない条件がより多くあります。したがって、見返りは大きくなりますが、リスクも大きくなります。

事前レンダリングが行われると、ブラウザーは URL を取得し、コンテンツをレンダリングして非表示のタブに読み込みます。これは、コンテンツの JavaScript を実行し、JavaScript で取得したものを含むすべてのサブリソースを読み込みます。以下のいずれかの条件が見られた場合、そのコンテンツは事前レンダリングが安全でない可能性があります。

このような問題を軽減するには、以下の技術を使用することができます。

状態の変化をサーバー側でレンダリングする場合

サーバーがレンダリングする状態には、主に 2 つの種類があります。それは古い状態とユーザー別の状態です。これは安全でない先読みと事前レンダリングの両方を発生させる可能性があります。

ユーザー別の状態の問題は、例えば言語設定、ダークモードの環境設定、カートへの商品の追加など、他にもユーザー設定によって発生することがあります。また、単一のタブのみが関係している場合にも発生することがあります。

このような場合、そして実際にコンテンツがサーバーと同期しなくなるような場合の最善の緩和策は、必要に応じてページを更新することです。例えば、サーバーはブロードキャストチャンネル API や fetch() や WebSocket のような別のメカニズムを使用するかもしれません。ページは、まだアクティブになっていない投機的に読み込まれたページを含め、適切に更新することができます。

事前レンダリングされた文書のセッション履歴の動作

事前レンダリング中/事前レンダリング済みの文書をアクティブにすると、エンドユーザーの視点で見れば、従来のナビゲーションと同じように動作します。アクティブ化された文書はタブに表示され、セッション履歴に追加され、既存の前方履歴項目は削除されます。アクティブ化される前に事前レンダリングされた閲覧コンテキストに配置されたナビゲーションは、セッション履歴に影響を与えません。

開発者の視点から見ると、事前レンダリングされた文書は、現在の項目という 1 つの項目しか存在しない微小なセッション履歴があると考えることができます。事前レンダリングされたコンテキスト内のナビゲーションはすべて効果的に置き換わります。

セッション履歴を処理する API 機能（例えば History や Navigation）は事前レンダリング文書内で呼び出すことができますが、それらはコンテキストの微小なセッション履歴を処理するだけです。その結果、事前レンダリングされた文書は参照するページの共同セッション履歴に属しません。例えば、 History.back() によってリファラーに移動することはできません。

この設計により、ユーザーが戻るボタンを使用したときに期待した経験を得ること、つまり、最後に見たものに戻ることを確実にします。事前レンダリング文書がアクティブになると、単一のセッション履歴項目のみが結合セッション履歴に追加され、事前レンダリング閲覧コンテキスト内で起こった前回までの操作は無視されます。結合セッション履歴を 1 段階戻ると（例えば戻るボタンを押すと）、ユーザーは参照元のページに戻ります。

事前レンダリング中に延期または制限されるプラットフォーム機能

事前レンダリングされたページは非表示状態で開かれるため、潜在的に邪魔になる動作を引き起こすいくつかの API 機能は、この状態では有効化されず、代わりにページが有効化されるまで遅延されます。事前レンダリング時に問題となるその他のウェブプラットフォーム機能は、すべて制限されます。この章では、遅延または制限される機能の詳細について説明します。

メモ: 延期および制限が実現不可能なごく少数のケースでは、事前レンダリングは取り消されます。

非同期 API の延期

延期とは、API 機能によって待機中のプロミスがすぐに返され、ページがアクティブになるまで何も実行されないことを意味します。アクティブ化後、機能は通常どおり実行され、プロミスは通常どおり解決または拒否されます。

以下の非同期機能の結果は、アクティブ化されるまで、事前レンダリングされた文書内で延期されます。

暗黙的に制限される API 他の制限されている機能 インターフェイス

投機ルール API は独自のインターフェイスを定義していません。

他のインターフェイスの拡張
Document.prerendering Experimental

論理値プロパティで、文書が現在事前レンダリングされつつある場合に true を返します。

prerenderingchange イベント Experimental

事前レンダリングされた文書がアクティブになった（ユーザーがページを表示した）ときに発行されます。

PerformanceNavigationTiming.activationStart Experimental

文書が事前レンダリングを開始してからアクティブになるまでの時間を表す数値。

PerformanceResourceTiming.deliveryType "navigational-prefetch" 値 Experimental

パフォーマンス項目の種別が先読みであることを示します。

HTTP ヘッダー
Content-Security-Policy 'inline-speculation-rules' 値 Experimental

取得する文書に投機ルールを定義するために <script type="speculationrules"> の使用を許可するオプトインに使用します。

Speculation-Rules Experimental

投機ルール JSON 定義を含むテキストリソースを指す URL のリストを提供します。レスポンスが HTML 文書の場合、これらのルールは文書の投機ルールセットに追加されます。

Supports-Loading-Mode Experimental

ナビゲーション対象が、よりリスクの高い様々な読み込みモードを使用することをオプトインするために設定します。例えば、異なるオリジン間、同じサイトの事前レンダリングには Supports-Loading-Mode の値として credentialed-prerender が要求されます。

HTML 機能
<script type="speculationrules"> Experimental

現在の文書内の先読みや事前レンダリングの投機ルールを定義するために使用します。これらのルールは、この文書の投機ルールセットに追加されます。

例

完全な事前レンダリングのデモはこちらにあります。

仕様書 ブラウザーの互換性 api.Document.prerendering api.Document.prerenderingchange_event html.elements.script.type.speculationrules 関連情報

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4