Unterstützte Browser
- 109
- 109
- x
- x
Das Chrome-Team hat an Optionen gearbeitet, um das vollständige Pre-Rendering von Seiten, die ein Nutzer wahrscheinlich aufrufen wird, wiederherzustellen.
Ein kurzer Überblick über das Pre-Rendering
Früher unterstützte Chrome den Ressourcenhinweis zu <link rel="prerender" href="/next-page">, wurde aber nur in Chrome unterstützt und war keine besonders ausdrucksstarke API.
Dieses alte Pre-Rendering mit dem Link rel=prerender wurde zugunsten des NoState Prefetch eingestellt. Dieser hat stattdessen die von der zukünftigen Seite benötigten Ressourcen abgerufen, aber die Seite weder vollständig im Voraus gerendert noch JavaScript ausgeführt. „NoState Prefetch“ trägt zwar dazu bei, die Seitenleistung zu verbessern, indem das Laden von Ressourcen verbessert wird. Im Gegensatz zu einem vollständigen Pre-Rendering erfolgt jedoch kein sofortiger Seitenaufbau.
Das Chrome-Team hat jetzt das vollständige Pre-Rendering in Chrome wieder eingeführt. Um Komplikationen bei der bestehenden Nutzung zu vermeiden und eine künftige Erweiterung des Pre-Renderings zu ermöglichen, verwendet dieser neue Pre-Rendering-Mechanismus nicht die <link rel="prerender"...>-Syntax, die für den NoState-Vorabruf beibehalten wird und in der Zukunft eine Abschaffung dieser Funktion bedeutet.
Wie wird eine Seite vorab gerendert?
Eine Seite kann auf eine von vier Arten vorab gerendert werden, die alle dazu dienen sollen, die Navigation zu beschleunigen:
- Wenn Sie eine URL in die Adressleiste von Chrome eingeben, die auch als Omnibox bezeichnet wird, wird die Seite möglicherweise automatisch vorab für Sie gerendert, wenn es sehr wahrscheinlich ist, dass Sie die Seite besuchen werden.
- Wenn Sie einen Suchbegriff in die Adressleiste von Chrome eingeben, wird die Suchergebnisseite möglicherweise automatisch vorab gerendert, wenn die Suchmaschine dazu aufgefordert wird.
- Websites können die Speculation Rules API verwenden, um Chrome programmatisch mitzuteilen, welche Seiten vorab gerendert werden sollen. Das ersetzt die bisherige Funktion von
<link rel="prerender"...>und ermöglicht Websites, eine Seite basierend auf Spekulationsregeln auf der Seite proaktiv vorab zu rendern. Diese können statisch auf den Seiten vorhanden sein oder dynamisch durch JavaScript eingeschleust werden, wenn es der Inhaber der Seite für angemessen hält.
In jedem dieser Fälle verhält sich ein Pre-Rendering so, als wäre die Seite in einem unsichtbaren Hintergrund-Tab geöffnet und wird dann „aktiviert“, indem der Vordergrund-Tab durch die vorab gerenderte Seite ersetzt wird. Wenn eine Seite aktiviert wird, bevor sie vollständig vorab gerendert wurde, befindet sich ihr aktueller Status im Vordergrund und wird weiter geladen. So können Sie sich trotzdem einen guten Vorsprung sichern.
Da die vorab gerenderte Seite im ausgeblendeten Zustand geöffnet wird, werden einige APIs, die aufdringliches Verhalten verursachen (z. B. Aufforderungen), in diesem Status nicht aktiviert, sondern verzögert, bis die Seite aktiviert wird. In den wenigen Fällen, in denen dies noch nicht möglich ist, wird das Pre-Rendering abgebrochen. Das Chrome-Team arbeitet daran, Gründe für den Abbruch des Pre-Renderings als API offenzulegen und die Funktionen der Entwicklertools zu verbessern, um die Identifizierung solcher Grenzfälle zu erleichtern.
Auswirkungen des Pre-Renderings
Das Pre-Rendering ermöglicht einen nahezu sofortigen Seitenaufbau, wie im folgenden Video gezeigt:
Die Beispielwebsite ist bereits eine schnelle Website, aber selbst damit können Sie sehen, wie das Pre-Rendering die Nutzererfahrung verbessert. Dies kann sich daher auch direkt auf die Core Web Vitals einer Website auswirken, da der LCP fast null ist, der CLS-Wert (CLS vor dem ersten Aufrufen erfolgt) und der INP verbessert werden, da der Ladevorgang abgeschlossen sein sollte, bevor der Nutzer mit der Anzeige interagiert.
Selbst wenn eine Seite aktiviert wird, bevor sie vollständig geladen ist, sollte der Seitenaufbau schneller geladen werden. Wenn während des Pre-Renderings ein Link aktiviert ist, wird die Pre-Rendering-Seite in den Hauptframe verschoben und weiter geladen.
Das Pre-Rendering verbraucht jedoch zusätzlichen Arbeitsspeicher und zusätzliche Netzwerkbandbreite. Achte darauf, nicht zu viel zu rendern, da dies zu Kosten von Nutzerressourcen führt. Du solltest sie nur dann vorab rendern, wenn die Wahrscheinlichkeit sehr hoch ist, dass die Seite aufgerufen wird.
Im Abschnitt Leistungsmessung finden Sie weitere Informationen dazu, wie Sie die tatsächlichen Auswirkungen auf die Leistung in Ihren Analysen messen können.
Vervollständigungen in der Adressleiste von Chrome ansehen
Im ersten Anwendungsfall können Sie sich die Vorhersagen von Chrome für URLs auf der Seite chrome://predictors ansehen:
Grüne Linien zeigen an, dass die Zuverlässigkeit so hoch ist, dass das Pre-Rendering ausgelöst wird. In diesem Beispiel ergibt die Eingabe von „s“ eine angemessene Konfidenz (gelb). Wenn Sie jedoch „sh“ eingeben, ist Chrome so sicher, dass Sie fast immer https://sheets.google.com aufrufen.
Dieser Screenshot wurde in einer relativ neuen Chrome-Installation erstellt und filtert Zero-Trust-Vorhersagen heraus. Wenn Sie jedoch Ihre eigenen Prädiktoren aufrufen, sehen Sie wahrscheinlich deutlich mehr Einträge und möglicherweise mehr Zeichen, die erforderlich sind, um ein ausreichend hohes Konfidenzniveau zu erreichen.
Diese Prädiktoren bestimmen auch, welche Optionen Ihnen in der Adressleiste möglicherweise aufgefallen sind:
Chrome aktualisiert seine Vorschläge kontinuierlich auf Grundlage deiner Eingabe und Auswahl.
- Bei einem Konfidenzniveau von mehr als 50 % (gelb angezeigt) stellt Chrome proaktiv eine Verbindung zur Domain her, die Seite wird jedoch nicht vorab gerendert.
- Bei einem Konfidenzniveau von mehr als 80 % (grün angezeigt) rendert Chrome die URL vorab.
Die Speculation Rules API
Bei der dritten Pre-Rendering-Option können Webentwickler JSON-Anweisungen in ihre Seiten einfügen, um den Browser darüber zu informieren, welche URLs vorab gerendert werden sollen:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["next.html", "next2.html"]
}
]
}
</script>
Oder durch Dokumentregeln (verfügbar ab Chrome 121), die Links im Dokument basierend auf href oder CSS-Selektoren vorab rendern:
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"selector_matches": ".do-not-prerender"}},
{ "not": {"selector_matches": "[rel=nofollow]"}}
]
}
}]
}
</script>
Eifr
Unterstützte Browser
- 121
- 121
- x
- x
Mit der Einstellung eagerness wird angegeben, wann Spekulationen ausgelöst werden sollen. Dies ist besonders nützlich für Dokumentregeln:
immediate:Wird verwendet, um so schnell wie möglich zu spekulieren, d. h. sobald die Spekulationsregeln befolgt werden.eager:Das Verhalten entspricht der Einstellungimmediate, soll aber in Zukunft zwischenimmediateundmoderateplatziert werden.moderate:Es werden Spekulationen angewendet, wenn Sie den Mauszeiger 200 Millisekunden lang auf einen Link bewegen (bzw. auf daspointerdown-Ereignis, wenn dieses früher erfolgt, und auf Mobilgeräten, wenn es keinhover-Ereignis gibt).conservative:spekuliert auf einen Zeiger oder Touchdown.
Die Standardeinstellung „eagerness“ für list-Regeln ist immediate. Die Optionen moderate und conservative können verwendet werden, um list-Regeln auf URLs zu beschränken, mit denen ein Nutzer interagiert, auf eine bestimmte Liste. In vielen Fällen sind document-Regeln mit einer entsprechenden where-Bedingung jedoch möglicherweise geeigneter.
Die Standardeinstellung „eagerness“ für document-Regeln ist conservative. Da ein Dokument viele URLs enthalten kann, sollten Sie immediate oder eager für document-Regeln mit Vorsicht verwenden (siehe auch den Abschnitt Beschränkungen für Chrome).
Welche eagerness-Einstellung Sie verwenden sollten, hängt von Ihrer Website ab. Bei einer schlanken, statischen Website kann es wenig kosten, mehr zu spekulieren, und bringt Nutzern Vorteile. Websites mit komplexeren Architekturen und schwereren Seitennutzlasten können Verschwendung reduzieren, indem weniger häufig spekuliert wird, bis Sie positivere Absichtssignale von Nutzenden zur Begrenzung von Verschwendung erhalten.
Die Option moderate ist ein Mittelweg, und viele Websites könnten von der folgenden Spekulationsregel profitieren, die alle Links, die durch Bewegen des Mauszeigers oder Mauszeigers nach unten scrollen, vorab als einfache und dennoch leistungsfähige Implementierung von Spekulationsregeln rendern würde:
<script type="speculationrules">
{
"prerender": [{
"where": {
"href_matches": "/*"
},
"eagerness": "moderate"
}]
}
</script>
Prefetch
Spekulationsregeln können auch verwendet werden, um Seiten vorab ohne vollständiges Pre-Rendering abzurufen. Dies ist oft ein guter erster Schritt auf dem Weg zum Pre-Rendering:
<script type="speculationrules">
{
"prefetch": [
{
"urls": ["next.html", "next2.html"]
}
]
}
</script>
Limits für Chrome
In Chrome gelten bestimmte Einschränkungen, um eine übermäßige Nutzung der Speculation Rules API zu verhindern:
| Eifr | Prefetch | Vorab rendern |
|---|---|---|
immediate / eager |
50 | 10 |
moderate / conservative |
2 (FIFO) | 2 (FIFO) |
Die Einstellungen „moderate“ und „conservative“, die von der Nutzerinteraktion abhängen, funktionieren in der FIFO-Methode (First In, First Out): Nach Erreichen des Limits führt eine neue Spekulation dazu, dass die älteste Spekulation abgebrochen und durch die neue ersetzt wird, um Arbeitsspeicher zu sparen. Eine abgebrochene Spekulation kann wieder ausgelöst werden, z. B. indem du den Mauszeiger noch einmal auf diesen Link bewegst. Dies führt dazu, dass diese URL erneut spekuliert wird und die älteste Spekulation verworfen wird. In diesem Fall hat die vorherige Spekulation alle im Cache speicherbaren Ressourcen für diese URL im Cache gespeichert, sodass eine weitere Spekulation weniger Kosten haben sollte. Deshalb wird der Grenzwert auf den moderaten Schwellenwert von 2 gesetzt. Statische Listenregeln werden nicht durch eine Nutzeraktion ausgelöst. Daher haben sie ein höheres Limit, da der Browser nicht erkennen kann, welche erforderlich sind und wann sie benötigt werden.
Die Limits für immediate und eager sind ebenfalls dynamisch. Wenn Sie ein URL-Skriptelement vom Typ list entfernen, schaffen Sie Kapazitäten, da die entfernten Spekulationen aufgehoben werden.
Chrome verhindert außerdem , dass Spekulationen unter bestimmten Bedingungen verwendet werden, darunter:
- Save Data (Daten speichern).
- Energiesparmodus: bei Aktivierung und niedrigem Akkustand.
- Arbeitsspeichereinschränkungen.
- Die Einstellung „Seiten vorab laden“ ist deaktiviert (diese Einstellung wird auch durch Chrome-Erweiterungen wie uBlock Origin explizit deaktiviert).
- Seiten werden in Tabs im Hintergrund geöffnet.
Außerdem rendert Chrome ursprungsübergreifende iFrames auf vorab gerenderten Seiten erst nach der Aktivierung.
All diese Bedingungen zielen darauf ab, die Auswirkungen von übermäßigen Spekulationen zu verringern, wenn sie sich schädlich für die Nutzer darstellen würden.
Spekulationsregeln auf einer Seite einbinden
Spekulationsregeln können statisch in den HTML-Code der Seite eingebunden oder mithilfe von JavaScript dynamisch in die Seite eingefügt werden:
- Statisch enthaltene Spekulationsregeln: Auf einer Nachrichten-Website oder in einem Blog wird der neueste Artikel möglicherweise vorab gerendert, wenn dies für einen großen Teil der Nutzer oft die nächste Navigation ist. Alternativ können auch Dokumentregeln mit
moderateoderconservativefür Spekulationen verwendet werden, um zu spekulieren, wenn Nutzer mit Links interagieren. - Dynamisch eingefügte Spekulationsregeln: Diese können auf der Anwendungslogik basieren, für den Nutzer personalisiert oder auf anderen Heuristiken basieren.
Diejenigen, die das dynamische Einfügen aufgrund von Aktionen wie dem Bewegen des Mauszeigers auf einen Link oder Klicken auf einen Link bevorzugen – wie es viele Bibliotheken in der Vergangenheit mit <link rel=prefetch> getan haben – sollten Sie sich mit Dokumentregeln befassen, da der Browser damit viele Ihrer Anwendungsfälle bewältigen kann.
Spekulationsregeln können entweder im <head> oder in <body> im Hauptframe hinzugefügt werden. Spekulationsregeln in Subframes werden nicht berücksichtigt, Spekulationsregeln auf vorab gerenderten Seiten werden erst angewendet, wenn die entsprechende Seite aktiviert wurde.
Der Speculation-Rules-HTTP-Header
Spekulationsregeln können auch mithilfe eines Speculation-Rules-HTTP-Headers übermittelt werden, anstatt sie direkt in den HTML-Code des Dokuments einzufügen. Dies ermöglicht eine einfachere Bereitstellung durch CDNs, ohne dass der Dokumentinhalt selbst geändert werden muss.
Der HTTP-Header Speculation-Rules wird mit dem Dokument zurückgegeben und verweist auf einen Speicherort in einer JSON-Datei, die die Spekulationsregeln enthält:
Speculation-Rules: "/speculationrules.json"
Für diese Ressource muss der richtige MIME-Typ verwendet werden. Wenn es sich um eine ursprungsübergreifende Ressource handelt, muss eine CORS-Prüfung bestehen.
Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *
Wenn du relative URLs verwenden möchtest, kannst du den "relative_to": "document"-Schlüssel in deine Spekulationsregeln aufnehmen. Andernfalls sind relative URLs relativ zur URL der JSON-Datei für Spekulationsregeln. Dies kann besonders nützlich sein, wenn Sie einige oder alle Links desselben Ursprungs auswählen müssen.
Spekulationsregeln und SPAs
Spekulationsregeln werden nur für vollständige Seitennavigationen unterstützt, die vom Browser verwaltet werden, nicht für Seiten mit Single Page Apps (SPA) oder App-Shell-Seiten. Bei dieser Architektur werden keine Dokumentabrufe verwendet, sondern API- oder Teilabrufe von Daten oder Seiten durchgeführt, die dann verarbeitet und auf der aktuellen Seite angezeigt werden. Die für diese sogenannten „weichen Navigationen“ benötigten Daten können außerhalb von Spekulationsregeln von der App vorab abgerufen, aber nicht vorab gerendert werden.
Spekulationsregeln können verwendet werden, um die Anwendung selbst von einer vorherigen Seite vorab zu rendern. So lassen sich die zusätzlichen Kosten für das anfängliche Laden bei einigen SPAs etwas ausgleichen. Routenänderungen innerhalb der App können jedoch nicht vorab gerendert werden.
Spekulationsregeln debuggen
Im entsprechenden Beitrag zum Debuggen von Spekulationsregeln findest du Informationen zu neuen Chrome-Entwicklertools, die dir beim Aufrufen und Debuggen dieser neuen API helfen.
Mehrere Spekulationsregeln
Außerdem können einer Seite mehrere Spekulationsregeln hinzugefügt und an die vorhandenen Regeln angehängt werden. Daher führen die folgenden unterschiedlichen Arten sowohl zum Pre-Rendering von one.html als auch zum two.html:
Liste der URLs:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["one.html", "two.html"]
}
]
}
</script>
Mehrere speculationrules:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["one.html"]
}
]
}
</script>
<script type="speculationrules">
{
"prerender": [
{
"urls": ["two.html"]
}
]
}
</script>
Mehrere Listen innerhalb eines Satzes von speculationrules
<script type="speculationrules">
{
"prerender": [
{
"urls": ["one.html"]
},
{
"urls": ["two.html"]
}
]
}
</script>
No-Vary-Search-Support
Beim Vorabruf oder Pre-Rendering einer Seite können bestimmte URL-Parameter (auch als Suchparameter bezeichnet) für die tatsächlich vom Server bereitgestellte Seite unwichtig sein. Sie werden nur vom clientseitigen JavaScript verwendet.
UTM-Parameter werden in Google Analytics beispielsweise zur Kampagnenanalyse verwendet, führen aber normalerweise nicht dazu, dass verschiedene Seiten vom Server gesendet werden. Das bedeutet, dass page1.html?utm_content=123 und page1.html?utm_content=456 dieselbe Seite vom Server übermitteln, sodass dieselbe Seite aus dem Cache wiederverwendet werden kann.
Ebenso können Anwendungen andere URL-Parameter verwenden, die nur clientseitig verarbeitet werden.
Mit dem Vorschlag No-Vary-Search kann ein Server Parameter angeben, die nicht zu einem Unterschied bei der bereitgestellten Ressource führen. So kann ein Browser zuvor im Cache gespeicherte Versionen eines Dokuments wiederverwenden, die sich nur durch diese Parameter unterscheiden. Dies wird in Chrome und in Chromium-basierten Browsern nur für Spekulationen zur Prefetch-Navigation unterstützt.
Die Verwendung von expects_no_vary_search wird für Spekulationsregeln unterstützt, um anzugeben, wo ein No-Vary-Search-HTTP-Header voraussichtlich zurückgegeben wird. So können Sie unnötige Downloads vermeiden.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["/products*"],
"expects_no_vary_search": "params=(\"id\")"
}]
}
</script>
<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>
In diesem Beispiel ist der HTML-Code der ersten Seite /products für die Produkt-IDs 123 und 124 identisch. Die Seiteninhalte unterscheiden sich jedoch letztendlich aufgrund des clientseitigen Renderings, bei dem Produktdaten mit dem Suchparameter id abgerufen werden. Wir rufen diese URL also vorab ab und sie sollte einen No-Vary-Search-HTTP-Header zurückgeben, der darauf hinweist, dass die Seite für jeden id-Suchparameter verwendet werden kann.
Wenn der Nutzer jedoch auf einen der Links klickt, bevor der Prefetch abgeschlossen ist, hat der Browser die /products-Seite möglicherweise nicht erhalten. In diesem Fall weiß der Browser nicht, ob der HTTP-Header No-Vary-Search enthalten sein wird. Der Browser kann dann entscheiden, ob der Link noch einmal abgerufen werden soll oder ob er einen No-Vary-Search-HTTP-Header enthält, bis der Prefetch abgeschlossen ist. Mit der Einstellung expects_no_vary_search weiß der Browser, dass die Seitenantwort voraussichtlich einen No-Vary-Search-HTTP-Header enthält, und kann darauf warten, dass der Prefetch abgeschlossen ist.
Einschränkungen für Spekulationsregeln und zukünftige Verbesserungen
Spekulationsregeln sind auf Seiten beschränkt, die im selben Tab geöffnet werden. Wir arbeiten jedoch daran, diese Einschränkungen zu verringern. Das Pre-Rendering ist standardmäßig auf Seiten mit derselben Herkunft beschränkt.
Das Pre-Rendering von ursprungsübergreifenden Seiten derselben Website (z. B. könnte https://a.example.com eine Seite auf https://b.example.com vorab rendern). Um dies zu verwenden, muss die vorab gerenderte Seite (in diesem Beispiel https://b.example.com) durch Einfügen eines Supports-Loading-Mode: credentialed-prerender-HTTP-Headers aktiviert werden. Andernfalls wird das Pre-Rendering durch Chrome abgebrochen.
In zukünftigen Versionen ist es auch möglich, das Pre-Rendering für ursprungsübergreifende Seiten zu erlauben, bei denen die Website mit einem ähnlichen Supports-Loading-Mode: uncredentialed-prerender-HTTP-Header aktiviert wird, und das Pre-Rendering auf neuen Tabs zu aktivieren.
Unterstützung der Detect Speculation Rules API
Sie können die Unterstützung der Speculation Rules API mithilfe von Standard-HTML-Prüfungen erkennen:
if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
console.log('Your browser supports the Speculation Rules API.');
}
Spekulationsregeln dynamisch über JavaScript hinzufügen
Hier ist ein Beispiel für das Hinzufügen einer prerender-Spekulationsregel mit JavaScript:
if (HTMLScriptElement.supports &&
HTMLScriptElement.supports('speculationrules')) {
const specScript = document.createElement('script');
specScript.type = 'speculationrules';
specRules = {
prerender: [
{
urls: ['/next.html'],
},
],
};
specScript.textContent = JSON.stringify(specRules);
console.log('added speculation rules to: next.html');
document.body.append(specScript);
}
Auf dieser Demoseite für das Pre-Rendering können Sie sich eine Demo des Pre-Renderings mit der Speculation Rules API mit JavaScript-Einfügung ansehen.
Spekulationsregeln abbrechen
Das Entfernen von Spekulationsregeln führt dazu, dass das Pre-Rendering abgebrochen wird. Zu diesem Zeitpunkt sind jedoch wahrscheinlich bereits Ressourcen für die Initiierung des Pre-Renderings ausgegeben worden. Daher wird empfohlen, kein Pre-Rendering vorzunehmen, wenn die Wahrscheinlichkeit besteht, dass das Pre-Rendering abgebrochen werden muss.
Spekulationsregeln und Content Security Policy
Da Spekulationsregeln ein <script>-Element verwenden, auch wenn es nur JSON enthält, müssen sie in die script-src Content-Security-Policy aufgenommen werden, wenn die Website dieses Element verwendet – entweder mit einem Hash oder einer Nonce.
script-src kann eine neue inline-speculation-rules hinzugefügt werden, damit aus Hash- oder nicht erzwungenen Skripts eingeschleuste <script type="speculationrules">-Elemente unterstützt werden. Die im ursprünglichen HTML-Code enthaltenen Regeln werden nicht unterstützt. Daher müssen Regeln für Websites, die eine strenge CSP verwenden, von JavaScript eingeschleust werden.
Pre-Rendering erkennen und deaktivieren
Das Pre-Rendering ist in der Regel ein positives Erlebnis für die Nutzer, da es ein schnelles Rendern der Seite ermöglicht – oft sofort. Davon profitieren sowohl Nutzer als auch Websiteinhaber, da vorab gerenderte Seiten eine bessere Nutzererfahrung bieten, was sonst nur schwer zu erreichen ist.
Es kann jedoch Fälle geben, in denen Sie kein Pre-Rendering von Seiten wünschen, etwa wenn sich der Status von Seiten ändert – entweder auf Grundlage der ersten Anfrage oder basierend auf dem JavaScript, das auf der Seite ausgeführt wird.
Pre-Rendering in Chrome aktivieren und deaktivieren
Das Pre-Rendering ist nur für Chrome-Nutzer mit der Einstellung „Seiten vorab laden“ in chrome://settings/performance/ aktiviert. Außerdem ist das Pre-Rendering auch auf Geräten mit wenig Arbeitsspeicher oder im Betriebssystem „Datensparmodus“ oder „Energiesparmodus“ deaktiviert. Weitere Informationen finden Sie im Abschnitt Chrome-Limits.
Serverseitiges Pre-Rendering erkennen und deaktivieren
Vorab gerenderte Seiten werden mit dem HTTP-Header Sec-Purpose gesendet:
Sec-Purpose: prefetch;prerender
Für vorabgerufene Seiten, die die Speculation Rules API verwenden, wird dieser Header auf prefetch gesetzt:
Sec-Purpose: prefetch
Server können basierend auf diesem Header antworten, Spekulationsanfragen protokollieren, andere Inhalte zurückgeben oder ein Pre-Rendering verhindern. Wird ein nicht erfolgreicher Antwortcode zurückgegeben, also kein 200- oder 304-Statuscode, wird die Seite nicht vorab gerendert und die Prefetch-Seite wird verworfen.
Wenn Sie nicht möchten, dass eine bestimmte Seite vorab gerendert wird, können Sie das am besten so vermeiden. Für eine optimale Darstellung wird jedoch empfohlen, stattdessen das Pre-Rendering zuzulassen und mit JavaScript Aktionen zu verzögern, die erst dann erfolgen, wenn die Seite tatsächlich angezeigt wird.
Pre-Rendering in JavaScript erkennen
Die document.prerendering API gibt true zurück, während die Seite vorab gerendert wird. Dies kann von Seiten verwendet werden, um bestimmte Aktivitäten während des Pre-Renderings zu verhindern oder zu verzögern, bis die Seite tatsächlich aktiviert wird.
Sobald ein vorab gerendertes Dokument aktiviert wurde, wird activationStart von PerformanceNavigationTiming auf einen Wert ungleich null gesetzt, der die Zeit zwischen dem Start des Pre-Renderings und der tatsächlichen Aktivierung des Dokuments darstellt.
Sie können eine Funktion wie die folgende verwenden, um Seiten mit Pre-Rendering und Pre-Rendering zu prüfen:
function pagePrerendered() {
return (
document.prerendering ||
self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
);
}
Am einfachsten kannst du prüfen, ob eine Seite vollständig oder teilweise vorab gerendert wurde, indem du die Entwicklertools öffnest, nachdem die Seite aktiviert wurde, und performance.getEntriesByType('navigation')[0].activationStart in die Console eingibst. Wenn ein Wert ungleich null zurückgegeben wird, wissen Sie, dass die Seite vorab gerendert wurde:
Wenn die Seite von dem Nutzer aktiviert wird, der die Seite aufruft, wird das prerenderingchange-Ereignis im document ausgelöst. Damit können dann Aktivitäten aktiviert werden, die zuvor standardmäßig beim Seitenaufbau gestartet wurden, aber verzögert werden sollen, bis der Nutzer die Seite tatsächlich sieht.
Mithilfe dieser APIs kann Frontend-JavaScript vorab gerenderte Seiten erkennen und entsprechend darauf reagieren.
Auswirkungen auf Analytics
Mit Analytics lassen sich beispielsweise Seitenaufrufe und Ereignisse mit Google Analytics messen. Oder durch Messung der Leistungsmesswerte von Seiten mit Real User Monitoring (RUM).
Seiten sollten nur vorab gerendert werden, wenn die Wahrscheinlichkeit hoch ist, dass sie vom Nutzer geladen werden. Aus diesem Grund werden die Pre-Rendering-Optionen in der Chrome-Adressleiste nur angezeigt, wenn die Wahrscheinlichkeit so hoch ist (mehr als 80% der Zeit).
Insbesondere bei Verwendung der Speculation Rules API können sich vorab gerenderte Seiten jedoch auf die Analyse auswirken. Außerdem müssen Websiteinhaber möglicherweise zusätzlichen Code hinzufügen, um Analysen nur für vorab gerenderte Seiten bei der Aktivierung zu ermöglichen, da nicht alle Anbieter von Analysen dies standardmäßig tun.
Um dies zu erreichen, kann ein Promise verwendet werden, das auf das prerenderingchange-Ereignis wartet, wenn ein Dokument vorab gerendert wird, oder sofort aufgelöst wird, wenn es jetzt so aussieht:
// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
if (document.prerendering) {
document.addEventListener('prerenderingchange', resolve, {once: true});
} else {
resolve();
}
});
async function initAnalytics() {
await whenActivated;
// Initialise your analytics
}
initAnalytics();
Ein alternativer Ansatz besteht darin, Aktivitäten zu verzögern, bis die Seite zum ersten Mal sichtbar wird. Dies würde sowohl den Pre-Rendering-Fall abdecken als auch das Öffnen von Tabs im Hintergrund (z. B. durch einen Rechtsklick und Öffnen in einem neuen Tab):
// Set up a promise for when the page is first made visible
const whenActivated = new Promise((resolve) => {
if (document.hidden) {
document.addEventListener('visibilitychange', resolve, {once: true});
} else {
resolve();
}
});
async function initAnalytics() {
await whenActivated;
// Initialise your analytics
}
initAnalytics();
Dies kann bei Analysen und ähnlichen Anwendungsfällen sinnvoll sein. In anderen Fällen kann es jedoch sinnvoll sein, mehr Inhalte für diese Fälle zu laden. In diesem Fall können Sie document.prerendering und prerenderingchange verwenden, um ein spezielles Targeting auf Pre-Rendering-Seiten vorzunehmen.
Leistung messen
Für die Messung von Leistungsmesswerten sollte das Analytics-Team überlegen, ob es besser ist, dies anhand der Aktivierungszeit und nicht anhand der Seitenladezeit zu messen, die von den Browser-APIs gemeldet werden.
Die Core Web Vitals, die von Chrome im Bericht zur Nutzererfahrung in Chrome gemessen werden, dienen dazu, die Nutzererfahrung zu messen. Sie werden also anhand der Aktivierungszeit gemessen. Dies führt häufig zu einem LCP-Wert von 0 Sekunden, was eine hervorragende Möglichkeit zur Verbesserung der Core Web Vitals darstellt.
Seit Version 3.1.0 wurde die web-vitals-Bibliothek aktualisiert, um vorab gerenderte Navigationen genauso zu verarbeiten wie Core Web Vitals. In dieser Version werden auch vorab gerenderte Navigationen für diese Messwerte im Attribut Metric.navigationType gemeldet, wenn die Seite vollständig oder teilweise vorab gerendert wurde.
Pre-Renderings messen
Ob eine Seite vorab gerendert wird, kann mit einem activationStart-Eintrag ungleich null von PerformanceNavigationTiming gesehen werden. Dies kann dann mit einer benutzerdefinierten Dimension oder ähnlich beim Logging der Seitenaufrufe protokolliert werden, z. B. mit der oben beschriebenen pagePrerendered-Funktion:
// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');
Auf diese Weise können Sie in Ihren Analysen sehen, wie viele Navigationen im Vergleich zu anderen Navigationstypen vorab gerendert werden. Außerdem können Sie Leistungsmesswerte oder Geschäftsmesswerte mit diesen verschiedenen Navigationstypen korrelieren. Schnellere Seiten führen zu zufriedeneren Nutzern, was oft deutliche Auswirkungen auf die Geschäftstätigkeit hat, wie unsere Fallstudien zeigen.
Wenn Sie die geschäftlichen Auswirkungen des Pre-Renderings von Seiten für die sofortige Navigation messen, können Sie entscheiden, ob es sich lohnt, mehr in diese Technologie zu investieren, damit mehr Navigationen vorab gerendert werden können, oder untersuchen, warum Seiten nicht vorab gerendert werden.
Trefferquoten messen
Es ist nicht nur wichtig, die Auswirkungen von Seiten zu messen, die nach einem Pre-Rendering besucht werden, sondern auch Seiten, die vorab gerendert und nicht danach besucht werden. Dies könnte bedeuten, dass du zu viel vorab renderst und wertvolle Ressourcen des Nutzers ohne Mehrwert aufbrauchst.
Dies kann gemessen werden, indem ein Analyseereignis ausgelöst wird, wenn Spekulationsregeln eingefügt werden – nachdem geprüft wurde, ob der Browser Pre-Rendering mit HTMLScriptElement.supports('speculationrules') unterstützt –, um anzuzeigen, dass ein Pre-Rendering angefordert wurde. Auch wenn ein Pre-Rendering angefordert wurde, bedeutet dies nicht, dass ein Pre-Rendering gestartet oder abgeschlossen wurde. Wie bereits erwähnt, ist ein Pre-Rendering ein Hinweis für den Browser und unter Umständen werden Seiten in Bezug auf Nutzereinstellungen, die aktuelle Arbeitsspeichernutzung oder andere Heuristiken nicht vorab gerendert.
Anschließend können Sie die Anzahl dieser Ereignisse mit den tatsächlichen Pre-Rendering-Seitenaufrufen vergleichen. Alternativ können Sie bei der Aktivierung ein anderes Ereignis auslösen, wenn dies den Vergleich erleichtert.
Anhand der Differenz zwischen diesen beiden Zahlen lässt sich dann die "Erfolgsrate" annähern. Bei Seiten, auf denen Sie die Speculation Rules API zum Pre-Rendering der Seiten verwenden, können Sie die Regeln entsprechend anpassen, um eine hohe Trefferrate aufrechtzuerhalten. So wird das Gleichgewicht zwischen der Verbrauchung von Nutzerressourcen für die Unterstützung und einer unnötigen Nutzung gewahrt.
Beachte, dass Pre-Rendering durch das Pre-Rendering der Adressleiste und nicht nur durch deine Spekulationsregeln stattfinden kann. Wenn du sie unterscheiden möchtest, kannst du das document.referrer prüfen. Dieses ist für die Adressleistennavigation leer, einschließlich vorab gerenderter Navigationen in der Adressleiste.
Sieh dir auch Seiten ohne Pre-Rendering an, da dies ein Hinweis darauf sein kann, dass diese Seiten nicht für das Pre-Rendering geeignet sind, selbst wenn die Adressleiste angezeigt wird. Das bedeutet möglicherweise, dass Sie von dieser Leistungssteigerung nicht profitieren. Das Chrome-Team möchte zusätzliche Tools hinzufügen, um die Berechtigung für das Pre-Rendering zu testen, die möglicherweise ähnlich dem bfcache-Testtool sind. Außerdem möchte das Chrome-Team möglicherweise eine API hinzufügen, um aufzuzeigen, warum ein Pre-Rendering fehlgeschlagen ist.
Auswirkungen auf Erweiterungen
Weitere Informationen finden Sie im Beitrag Chrome Extensions: Extending API to support Instant Navigation (Chrome-Erweiterungen: Erweiterung der API zur Unterstützung der Instant Navigation). Dort werden einige weitere Punkte aufgeführt, die Erweiterungsautoren bei vorab gerenderten Seiten berücksichtigen müssen.
Feedback
Pre-Rendering wird derzeit vom Chrome-Team aktiv entwickelt und es gibt viele Pläne, den Umfang der in Chrome 108 verfügbaren Funktionen zu erweitern. Wir freuen uns über Feedback zum GitHub-Repository oder über unseren Issue Tracker und freuen uns auf die Fallstudien zu dieser spannenden neuen API.
Weitere Informationen
- Fehlerbehebung bei Spekulationsregeln
- Jetzt neu: NoState Prefetch
- Speculation Rules API
- GitHub-Repository für Navigationsspekulationen
- Chrome-Erweiterungen: Erweiterung der API zur Unterstützung der Instant Navigation
Danksagungen
Miniaturansicht von Marc-Olivier Jodoin auf Unsplash