Syntax

<script type="speculationrules">
  // JSON object defining rules
</script>

Ausnahmen

TypeError

Die Definition der Spekulationsregeln ist kein gültiges JSON-Objekt.

Beschreibung

Ein <script type="speculationrules">-Element muss eine gültige JSON-Struktur enthalten, die Spekulationsregeln definiert. Die folgenden Beispiele zeigen separate Regeln für das Vorladen und Vorab-Rendern:

<script type="speculationrules">
  {
    "prefetch": [
      {
        "urls": ["next.html", "next2.html"],
        "requires": ["anonymous-client-ip-when-cross-origin"],
        "referrer_policy": "no-referrer"
      }
    ]
  }
</script>

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": { "href_matches": "/next" },
        "eagerness": "eager"
      }
    ]
  }
</script>

JSON-Darstellung der Spekulationsregeln

Die JSON-Struktur enthält ein oder mehrere Felder auf der obersten Ebene, von denen jedes eine Aktion zur Definition von Spekulationsregeln darstellt. Derzeit sind die unterstützten Aktionen:

"prefetch" Optional

Regeln für potenzielle zukünftige Navigationen, deren zugehöriger Dokumentantwortkörper heruntergeladen werden sollte, was zu erheblichen Leistungsverbesserungen führt, wenn zu diesen Dokumenten navigiert wird. Beachten Sie, dass keine der von der Seite referenzierten Unterressourcen heruntergeladen werden.

"prerender" Optional

Regeln für potenzielle zukünftige Navigationen, deren zugehörige Dokumente vollständig heruntergeladen, gerendert und in einem unsichtbaren Tab geladen werden sollten. Dies umfasst das Laden aller Unterressourcen, das Ausführen aller JavaScripts und sogar das Laden von Unterressourcen und das Durchführen von Datenabrufen, die durch JavaScript gestartet wurden. Wenn zu diesen Dokumenten navigiert wird, sind die Navigationen sofort, was zu erheblichen Leistungsverbesserungen führt.

Jedes Aktionsfeld enthält ein Array, das wiederum ein oder mehrere Objekte enthält. Jedes Objekt enthält eine einzige Regel, die eine Menge von URLs und zugehörige Parameter definiert.

Jedes Objekt kann die folgenden Eigenschaften enthalten:

"source"

Ein String, der die Quelle der URLs anzeigt, auf die sich die Regel bezieht. Dies ist optional, da der Wert immer aus anderen Eigenschaften abgeleitet werden kann.

Dies kann einer der folgenden sein:

"document"

Gibt an, dass die URLs aus Navigationslinks im zugehörigen Dokument (wie in <a> und <area>-Elementen definiert) basierend auf den durch einen "where"-Schlüssel beschriebenen Bedingungen abgeglichen werden. Beachten Sie, dass die Präsenz eines "where"-Schlüssels "source": "document" impliziert, was so optional ist.

"list"

Gibt an, dass die URLs aus einer Liste im "urls"-Schlüssel stammen. Beachten Sie, dass die Präsenz eines "urls"-Schlüssels "source": "list" impliziert, was so optional ist.

"urls"

Ein Array von Zeichenfolgen, das eine Liste von URLs darstellt, auf die die Regel angewendet werden soll. Diese können absolute oder relative URLs sein. Relative URLs werden relativ zur Basis-URL des Dokuments (wenn inline in einem Dokument) oder relativ zur URL der externen Ressource (wenn extern abgerufen) analysiert. "urls" und "where" können nicht beide in derselben Regel gesetzt werden.

"where"

Ein Objekt, das die Bedingungen darstellt, anhand derer die Regel auf URLs im zugehörigen Dokument angewendet wird. Im Wesentlichen stellt das "where"-Objekt einen Test dar, der bei jedem Link auf der Seite durchgeführt wird, um festzustellen, ob die Spekulationsregel darauf angewendet wird. "where" und "urls" können nicht beide in derselben Regel gesetzt werden.

Dieses Objekt kann genau eine der folgenden Eigenschaften enthalten:

"href_matches"

Ein String, der ein URL-Muster enthält, oder ein Array, das mehrere URL-Muster-Strings enthält, die der Standard-Syntax der URL Pattern API folgen. Links im Dokument, deren URLs mit dem/den Muster(n) übereinstimmen, werden die Regel angewendet.

"relative_to"

Im Fall einer "href_matches"-Bedingung kann dies angeben, wo Sie möchten, dass diese Bedingung relativ zu einer bestimmten Stelle abgeglichen wird. Dies funktioniert genau wie der rule-level "relative_to"-Schlüssel, außer dass es nur eine einzelne "href_matches"-Bedingung innerhalb eines "where"-Schlüssels beeinflusst.

"selector_matches"

Ein String, der einen CSS-Selektor enthält, oder ein Array, das mehrere CSS-Selektoren enthält. Links im Dokument, die durch diese Selektoren abgeglichen werden, wird die Regel angewendet.

"and"

Ein Array, das ein oder mehrere Objekte mit Bedingungen ("href_matches", "selector_matches", "and", "not", oder "or") enthält, die alle erfüllt sein müssen, damit die Regel auf sie angewendet wird.

"not"

Ein Objekt, das eine Bedingung ("href_matches", "selector_matches", "and", "not", oder "or") enthält, die, wenn sie erfüllt ist, nicht die Regel auf sie angewendet wird. Alle Links, die nicht mit der Bedingung übereinstimmen, werden die Regel angewendet.

"or"

Ein Array, das ein oder mehrere Objekte mit Bedingungen ("href_matches", "selector_matches", "and", "not", oder "or") enthält, von denen eines übereinstimmen kann, damit die Regel auf sie angewendet wird.

"where"-Bedingungen können in mehreren Ebenen tief verschachtelt werden, um komplexe Bedingungen zu erstellen, oder Sie können sich dafür entscheiden, sie in separate Regeln zu unterteilen, um sie einfach zu halten. Siehe where examples für weitere Erklärungen und mehrere Anwendungsbeispiele.

"eagerness"

Ein String, der dem Browser einen Hinweis darauf gibt, wie eifrig er Linkziele vorladen/vorrendern sollte, um Leistungsgewinne gegen Ressourcenaufwand abzuwägen. Mögliche Werte sind:

"immediate"

Der Autor denkt, dass der Link sehr wahrscheinlich gefolgt wird und/oder dass das Dokument erheblichen Zeitaufwand beim Abrufen erfordert. Das Vorladen/Vorrendern sollte so schnell wie möglich beginnen, nur durch Überlegungen wie Benutzereinstellungen und Ressourcenlimits beschränkt.

"eager"

Der Autor möchte eine große Anzahl von Navigationen so früh wie möglich vorladen/vorrendern. Das Vorladen/Vorrendern sollte bei jedem leichten Hinweis darauf beginnen, dass ein Link gefolgt werden könnte. Zum Beispiel könnte der Benutzer seinen Mauszeiger in Richtung des Links bewegen, ihn für einen Moment schweben/fokussieren oder das Scrollen mit dem Link an prominenter Stelle anhalten.

"moderate"

Der Autor sucht nach einem Gleichgewicht zwischen eager und conservative. Das Vorladen/Vorrendern sollte beginnen, wenn es eine vernünftige Vermutung gibt, dass der Benutzer in naher Zukunft einem Link folgen wird. Zum Beispiel könnte der Benutzer einen Link ins Sichtfenster scrollen und ihn eine Weile schweben/fokussieren.

"conservative"

Der Autor möchte einige Vorteile durch spekulatives Laden mit einem relativ geringen Ressourcenaufwand erzielen. Das Vorladen/Vorrendern sollte nur beginnen, wenn der Benutzer anfängt, auf den Link zu klicken, zum Beispiel bei mousedown oder pointerdown.

Wenn "eagerness" nicht explizit angegeben ist, sind list ("urls")-Regeln standardmäßig auf immediate und document ("where")-Regeln auf conservative eingestellt. Der Browser berücksichtigt diesen Hinweis zusammen mit seinen eigenen Heuristiken, sodass er möglicherweise einen Link auswählt, den der Autor als weniger eifrig angedeutet hat als einen anderen, wenn der weniger eifrige Kandidat als bessere Wahl angesehen wird.

"expects_no_vary_search"

Ein String, der dem Browser einen Hinweis darauf gibt, welchen No-Vary-Search-Header-Wert für Antworten auf Dokumente, die zuvor Vorlade/Vorrender-Anfragen erhalten, festgelegt wird. Mithilfe dieses Hinweises kann der Browser im Voraus bestimmen, ob es nützlicher ist, auf ein bestehendes Vorladen/Vorrendern zu warten oder eine neue Abrufanfrage zu starten, wenn die Spekulationsregel übereinstimmt. Siehe das "expects_no_vary_search"-Beispiel für weitere Erklärungen, wie dies verwendet werden kann.

"referrer_policy"

Ein String, der eine spezifische Referrer-Policy darstellt, die beim Anfordern der in der Regel angegebenen URLs verwendet werden soll – siehe Referrer-Policy für mögliche Werte. Der Zweck davon ist es, der verweisenden Seite zu erlauben, eine strengere Richtlinie speziell für die spekulative Anforderung festzulegen als die, die die Seite bereits eingestellt hat (entweder standardmäßig oder durch Verwendung der Referrer-Policy).

Hinweis: Ein domainspezifisches Vorladen erfordert eine Referrer-Policy, die mindestens so streng ist wie der Standardwert "strict-origin-when-cross-origin" — also "strict-origin-when-cross-origin", "same-origin", "strict-origin", oder "no-referrer". Eine weniger strenge Regelung in den Spekulationsregeln überschreibt eine strengere Regelung auf der verweisenden Seite, solange sie dennoch hinreichend streng für den domainspezifischen Fall ist.

Hinweis: Im Fall von Dokumentregeln wird die angegebene Referrer-Richtlinie des verknüpften Links (z.B. unter Verwendung des referrerpolicy-Attributes) verwendet, es sei denn, die Regel legt eine Richtlinie fest, die sie überschreibt.

"relative_to"

Ein String, der angibt, wo Sie möchten, dass über URL gefundene Links relativ dazu abgeglichen werden. Der Wert kann einer der folgenden sein:

document

URLs sollten relativ zu dem Dokument abgeglichen werden, auf das die Spekulationsregeln eingestellt sind.

ruleset

URLs sollten relativ zu der Datei abgeglichen werden, in der die Regeln angegeben sind. Dies ist der Standardwert.

Diese Schlüsseleinstellung ist nur relevant für Regeln, die in einer externen Datei definiert sind (festgelegt durch den Speculation-Rules-Header). Wenn Regeln innerhalb desselben Dokuments festgelegt werden, für das sie gelten (d.h. in einem Inline-<script>-Element), spielt es keine Rolle.

"requires"

Ein Array von Strings, die Fähigkeiten des Browsers darstellen, der die Regel analysiert und die verfügbar sein müssen, damit die Regel auf die angegebenen URLs angewendet wird.

Warnung: Vorladungen schlagen automatisch in Browsern fehl, die eine angegebene Anforderung nicht erfüllen können, selbst wenn sie die Speculation Rules API unterstützen.

Mögliche Werte sind:

"anonymous-client-ip-when-cross-origin"

(nur für Vorladen) Gibt an, dass die Regel nur zutrifft, wenn der Benutzeragent in der Lage ist, die Sichtbarkeit der Client-IP-Adresse für den Ursprungsserver zu verhindern, falls eine domainspezifische Vorladeanfrage gesendet wird. Wie dies funktioniert, hängt von spezifischen Implementierungsdetails des Browsers ab. Zum Beispiel:

• Chromes Implementierung versteckt die IP-Adresse mit einem Google-eigenen Proxy, daher funktioniert dies standardmäßig nur für von Google kontrollierte Verweiser (da in diesem Fall das Versenden der URLs der Ziel-URLs an Google kein zusätzlicher Privatsphärenverlust bedeutet). Bei Benutzung auf einer Nicht-Google-eigenen Seite werden Regeln, die dies beinhalten, nur auf Benutzer zutreffen, die "Erweitertes Preloading" in chrome://settings/preloading eingeschaltet haben.
• Andere auf Chromium basierende Browser müssen ihre eigenen Lösungen bereitstellen. Eine gründliche Prüfung in allen Zielbrowsern wird empfohlen.
• Eine zukünftige Safari-Implementierung könnte möglicherweise etwas Ähnliches wie den iCloud Private Relay verwenden.
• Eine zukünftige Firefox-Implementierung könnte eventuell auf dem Mozilla VPN basieren.

"tag"

Ein String, der verwendet wird, um eine Regel oder Regelsatz zu identifizieren. Dies wird im Sec-Speculation-Tags-Anforderungsheader für alle Spekulationen enthalten sein, die durch diese Regel abgedeckt sind.

"target_hint"

Ein String, der angibt, wo der Inhalt des vorgerenderten Documents aktiviert werden soll. Die Direktive wird für Vorlade-Spekulationen nicht unterstützt. Erlaubte Werte sind:

"target_hint": "_blank"

Öffnet den vorgerenderten Inhalt auf einer neuen Seite.

"target_hint": "_self"

Öffnet den vorgerenderten Inhalt auf der aktuellen Seite. Dies ist der Standard, wenn nicht angegeben.

Beispiele

Vorladen und Vorab-Rendern im selben Regelsatz

Die grundlegenden Beispiele, die im Beschreibungsabschnitt gezeigt wurden, enthielten separate Spekulationsregeln, die für Vorladen und Vorab-Rendern definiert wurden. Es ist möglich, beides in einem einzigen Regelsatz zu definieren:

<script type="speculationrules">
  {
    "prefetch": [
      {
        "urls": ["next.html", "next2.html"],
        "requires": ["anonymous-client-ip-when-cross-origin"],
        "referrer_policy": "no-referrer"
      }
    ],
    "prerender": [
      {
        "where": { "selector_matches": ".product-link" },
        "eagerness": "eager"
      }
    ]
  }
</script>

Mehrere Regelsätze

Es ist auch erlaubt, mehrere Regelsätze in einer einzigen HTML-Datei einzuschließen:

<script type="speculationrules">
  {
    "prefetch": [
      {
        "urls": ["next.html", "next2.html"],
        "requires": ["anonymous-client-ip-when-cross-origin"],
        "referrer_policy": "no-referrer"
      }
    ]
  }
</script>
<script type="speculationrules">
  {
    "prerender": [
      {
        "where": { "selector_matches": ".product-link" },
        "eagerness": "eager"
      }
    ]
  }
</script>

Und mehrere Regeln in einem einzigen Ergebnisset:

<script type="speculationrules">
  {
    "prerender": [
      {
        "urls": ["one.html"]
      },
      {
        "urls": ["two.html"]
      }
    ]
  }
</script>

Dynamisches Einfügen von Regeln

Nachfolgend ist ein Beispiel, das Spekulationsregeln erkennt und, falls unterstützt, eine Vorab-Render-Spekulationsregel dynamisch über JavaScript hinzufügt:

if (
  HTMLScriptElement.supports &&
  HTMLScriptElement.supports("speculationrules")
) {
  const specScript = document.createElement("script");
  specScript.type = "speculationrules";
  const specRules = {
    prerender: [
      {
        urls: ["/next.html"],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log("added speculation rules to: next.html");
  document.body.append(specScript);
}

where-Syntaxbeispiele

Eine dokumentenbezogene Regel enthält eine "where"-Eigenschaft, die ein Objekt darstellt, das Kriterien enthält, die definieren, welche Links im Dokument abgeglichen werden. Im Wesentlichen stellt das "where"-Objekt einen Test dar, der bei jedem Link auf der Seite ausgeführt wird, um festzustellen, ob die Spekulationsregel darauf angewendet wird.

Die grundlegendste Version wird ein einzelnes URL-Muster oder einen CSS-Selektor abgleichen:

{ "where": { "href_matches": "/next" } }

{ "where": { "selector_matches": ".important-link" } }

"href_matches" und "selector_matches" können auch auf ein Array von Werten gesetzt werden, sodass mehrere URL-Muster oder CSS-Selektoren gleichzeitig abgeglichen werden können:

{ "where": { "href_matches": ["/next", "/profile"] } }

{ "where": { "selector_matches": [".important-link", "#unique-link"] } }

URL-Muster und Selektoren können auch Platzhalter (*) enthalten, sodass ein einzelner Wert auf mehrere URLs zutreffen kann. Zum Beispiel könnte das unten stehende Objekt user/, user/settings, user/stats, usw. abgleichen.

{ "where": { "href_matches": "/user/*" } }

Suchparameter (oder Abfragezeichenfolgen) können auch in href_matches gezielt werden. Zum Beispiel könnte das unten stehende Objekt alle gleichstämmigen URLs mit einem category-Suchparameter abgleichen (als erster oder weiterer Parameter):

{ "where": { "href_matches": "/*\\?*(^|&)category=*" } }

Jede Bedingung kann negiert werden, indem sie in eine "not"-Bedingung gesetzt wird — dies bedeutet, dass, wenn sie abgeglichen wird, ein Link nicht die Spekulationsregel angewendet bekommt, aber wenn nicht abgeglichen, wird sie doch angewendet. Das folgende Beispiel bewirkt, dass alle Links, die nicht mit dem URL-Muster /logout übereinstimmen, die Regel angewendet bekommen, aber nicht Links, die mit /logout übereinstimmen:

{ "where": { "not": { "href_matches": "/logout" } } }

Mehrere "where"-Bedingungen mit "and" oder "or" kombinieren

Mehrere Bedingungen können innerhalb von "and"- oder "or"-Bedingungen kombiniert werden — diese nehmen den Wert von Arrays, die mehrere Bedingungen enthalten, an, alle oder jede davon (jeweils) müssen übereinstimmen, damit die Spekulationsregeln auf einen Link angewendet werden. Durch die Verwendung von "and" oder "or" können Bedingungen in mehreren Ebenen verschachtelt werden — es gibt kein festgelegtes Limit für erlaubte Verschachtelungsebenen.

Es ist nützlich, das "where"-Objekt als Äquivalent zu einer if-Anweisung zu betrachten. Also

{ and: [A, B, { or: [C, { not: D }] }] }

ist gleichwertig zu

if (A && B && (C || !D)) {
  apply speculation rule
}

Im folgenden vollständigen Spekulationsregelbeispiel werden alle gleichstämmigen Seiten zum Vorladen markiert, außer solche, die als problematisch bekannt sind — die /logout-Seite und alle Links mit Klassen von .no-prerender:

<script type="speculationrules">
  {
    "prefetch": [
      {
        "where": {
          "and": [
            { "href_matches": "/*" },
            { "not": { "href_matches": "/logout" } },
            { "not": { "selector_matches": ".no-prerender" } }
          ]
        }
      }
    ]
  }
</script>

"relative_to"-Beispiel

Für Regelsätze, die extern geladen werden (z.B. über das Speculation-Rules-Antwort-Headerfeld), werden URLs in Listenregeln und URL-Muster in Dokumentregeln standardmäßig relativ zur URL der enthaltenen externen Textdatei analysiert. Um URLs in einer Listenregel relativ zur Basis-URL des Dokuments zu analysieren, wird "relative_to" wie folgt verwendet:

{
  "urls": ["/home", "/about"],
  "relative_to": "document"
}

Für Dokumentregeln kann "relative_to" direkt mit "href_matches" gepaart werden, und die Basis-URL des Dokuments würde nur für Muster in dieser bestimmten Bedingung verwendet:

{
  "where": {
    "or": [
      { "href_matches": "/home", "relative_to": "document" },
      { "href_matches": "/about" }
    ]
  }
}

Im obigen Beispiel wird nur das erste "href_matches"-Muster relativ zur Basis-URL des Dokuments abgeglichen.

relative_to ist hauptsächlich relevant, wenn die Spekulationsregel-JSON-Datei auf einem anderen Ursprung als das Dokument liegt, auf das Sie sie anwenden möchten:

1. Wenn sich das Dokument unter https://example.com/some/subpage.html befindet und die Regeln unter https://example.com/resources/rules.json, entspricht /home immer https://example.com/home, unabhängig davon, ob relative_to auf document oder ruleset eingestellt ist.

2. Wenn sich das Dokument jedoch unter https://example.com/some/subpage.html befindet und die Regeln unter https://other.example/resources/rules.json (zum Beispiel auf einer Drittanbieter- oder cookieless Resource) liegen, dann:

   • "relative_to": "document" wird bewirken, dass /home https://example.com/home entspricht.
   • "relative_to": "ruleset" wird bewirken, dass /home https://other.example/home entspricht.

   Dies ist das typische Anwendungsbeispiel für "relative_to".

3. Ein weiteres mögliches (aber selteneres) Anwendungsbeispiel ist, wenn Ihre URLs in der Form home anstelle von /home angegeben werden. Wenn sich das Dokument unter https://example.com/some/subpage.html befindet und die Regeln unter https://example.com/resources/rules.json, dann:

   • "relative_to": "document" würde bewirken, dass home https://example.com/some/home entspricht.
   • "relative_to": "ruleset" würde bewirken, dass home https://example.com/resources/home entspricht.

"expects_no_vary_search"-Beispiel

Betrachten Sie den Fall einer Benutzerverzeichnis-Landingpage /users, die einen id-Parameter erhält, um Informationen zu einem bestimmten Benutzer anzuzeigen, z.B. /users?id=345. Ob diese URL für Cache-Zwecke als identisch angesehen werden sollte, hängt vom Verhalten der Anwendung ab:

1. Wenn dieser Parameter die Wirkung hat, eine völlig neue Seite zu laden, die die Informationen zum angegebenen Benutzer enthält, dann sollte die URL separat im Cache gespeichert werden.
2. Wenn dieser Parameter die Wirkung hat, den angegebenen Benutzer auf derselben Seite hervorzuheben und möglicherweise ein Panel anzuzeigen, das seine Daten zeigt, dann sollte die URL für Cache-Zwecke als identisch angesehen werden. Dies könnte zu Leistungsverbesserungen beim Laden der Benutzerseiten führen und durch einen No-Vary-Search-Header mit einem Wert von params=("id") erreicht werden.

Wie beeinflusst dies die Spekulationsregeln? Betrachten Sie den folgenden Code:

<script type="speculationrules">
  {
    "prefetch": [
      {
        "urls": ["/users"]
      }
    ]
  }
</script>
<a href="/users?id=345">User Bob</a>

Was würde in diesem Fall passieren, wenn der Benutzer eine Navigation zu /users?id=345 beginnt, während die Header für das Vorladen von /users noch nicht erhalten wurden? Zu diesem Zeitpunkt weiß der Browser nicht, was der No-Vary-Search-Wert sein wird, falls es einen gibt. Wenn kein No-Vary-Search-Wert gesetzt war und das Anwendungsverhalten mehr wie in Option 1 oben war, wäre das Vorladen vergeudet und der Browser müsste die separate /users?id=345-Seite von Grund auf neu laden.

Um dies zu lösen, können wir einen Hinweis darauf geben, was der Seitenersteller erwartet, was der No-Vary-Search-Wert sein sollte. Eine Spekulationsregel kann ein "expects_no_vary_search"-Feld haben, das eine Stringdarstellung des erwarteten Headerwerts enthält:

<script type="speculationrules">
  {
    "prefetch": [
      {
        "urls": ["/users"],
        "expects_no_vary_search": "params=(\"id\")"
      }
    ]
  }
</script>
<a href="/users?id=345">User Bob</a>

Dies zeigt an, dass Option 2, wie oben beschrieben, das ist, was der Server voraussichtlich produziert. Wenn eine Navigation beginnt, während ein Vorladen von /users noch im Gange ist, informiert dies den Browser, dass es angemessen ist, auf das Vorladen zu warten, anstatt sofort eine neue Anforderung für /users?id=345 zu starten.

Dokumentregeln können auch in Verbindung mit "expects_no_vary_search" verwendet werden, abhängig vom verwendeten Muster. Zum Beispiel im Fall von:

<script type="speculationrules">
  {
    "prefetch": [
      {
        { "where": { "href_matches": "/users?id=*" } },
        "expects_no_vary_search": "params=(\"id\")"
      }
    ]
  }
</script>
<a href="/users?id=012">User Bill</a>
<a href="/users?id=345">User Bob</a>
<a href="/users?id=678">User Ben</a>

Wenn über einen Link geschwebt wird, beginnt der Browser mit dem Vorladen dieses spezifischen Links.

Wenn der Benutzer vor Abschluss des Vorladens über einen anderen Link schwebt, teilt das expects_no_vary_search-Muster dem Browser mit, dass es nicht erforderlich ist, das aktuelle Vorladen abzubrechen, da alle /users-URLs mit id-URL-Parameterwerten für diesen Kontext effektiv auf dieselbe Seite verweisen (und für Cache-Zwecke).

Mehrere Parameter können in einem durch Leerzeichen getrennten Array angegeben werden:

<script type="speculationrules">
  {
    "prefetch": [
      {
        { "where": { "href_matches": "/users?id=*" } },
        "expects_no_vary_search": "params=(\"id\" \"order\" \"lang\")"
      }
    ]
  }
</script>

eagerness-Beispiel

Der folgende Satz von Dokumentregeln zeigt, wie eagerness verwendet werden kann, um anzudeuten, mit welcher Eifrigkeit der Browser jedes passende Set von Links vorladen/vorrendern sollte.

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": { "href_matches": "/*" },
        "eagerness": "conservative"
      },
      {
        "where": { "selector_matches": ".product-link" },
        "eagerness": "eager"
      }
    ]
  }
</script>

Hier deuten wir an, dass:

• Alle gleichmäßigen Seiten-Links, die im Dokument enthalten sind, konservativ vorgerendert werden sollten (d.h. wenn der Benutzer beginnt, sie zu aktivieren).
• Alle Produktlinks (in diesem Fall diejenigen mit einer class von .product-link) im Dokument sollten eifrig vorgerendert werden (d.h. wenn der Benutzer irgendeine Art von Bewegung in Richtung einer Navigation zu ihnen macht).

tag-Beispiel

Ein tag kann auf oberster Ebene enthalten sein, um den gesamten Regelsatz zu identifizieren:

<script type="speculationrules">
  {
    "tag": "my-rules",
    "prerender": [
      {
        "where": { "href_matches": "/*" },
        "eagerness": "conservative"
      }
    ]
  }
</script>

Oder um einzelne Regeln zu identifizieren:

<script type="speculationrules">
  {
    "prefetch": [
      "tag": "my-prefetch-rule",
      "urls": ["next.html"]
    ],
    "prerender": [
      "tag": "my-prerender-rule",
      "urls": ["next2.html"]
    ],
  }
</script>

Siehe Sec-Speculation-Tags für weitere Beispiele.

target_hint-Beispiel

Ein target_hint kann enthalten sein, um das Ziel-Fenster anzugeben, in dem passende Vorab-Render-Spekulationen geöffnet werden:

<script type="speculationrules">
  {
    "tag": "my-rules",
    "prerender": [
      {
        "eagerness": "eager",
        "target_hint": "_blank",
        "urls": ["page2.html"]
      }
    ]
  }
</script>

Die oben aufgeführten Regeln ermöglichen es, die folgenden Links korrekt in den entsprechenden Zielen vorab zu rendern:

<a href="page1.html">Open link in this window</a>
<a target="_blank" href="page2.html">Open link in new window</a>

target_hint wird nur für Listenregeln benötigt, die urls verwenden. Sie sind nicht für Dokumentregeln erforderlich (die where verwenden), da in diesen das Ziel aus dem target-Attribut des <a> Linkelements bekannt sein kann.

Spezifikationen

Browser-Kompatibilität

Siehe auch

• Seiten in Chrome vorab laden, um sofortige Seiten-Navigationen zu ermöglichen auf developer.chrome.com
• Spekulatives Laden
• Speculation Rules API