Heutzutage sind Webseiten voll mit Bildern, Videos und interaktiven Elementen, die das Nutzererlebnis verbessern sollen. Diese Elemente können jedoch die Ladezeit deiner Seite verlangsamen.
Während sich die Technologie weiterentwickelt, bleibt ein Ziel konstant: die Leistung. Jeder hofft, dass seine Webseiten blitzschnell geladen werden.
Eine Möglichkeit, Webseiten schneller zu laden, ist, sie vorzuladen, bevor ein Nutzer sie ansteuert.
Eine kurze Geschichte des Prerendering
2011 führte das Chromium-Team mit dem <link rel="prerender" … >-Tag eine frühe Form des Prerenderings in den Chrome-Browser ein.
Damit konnten Entwickler den Browsern mitteilen, welche Seite(n) ein Nutzer als Nächstes besuchen könnte. Der Browser holte und renderte diese Seiten dann im Hintergrund und verkürzte so die Ladezeit, wenn der Nutzer zu diesen Seiten navigierte.
Trotz ihrer Vorteile verbrauchte diese frühe Implementierung des Prerendering viel Bandbreite und CPU-Ressourcen und konnte zu Datenschutzproblemen führen, wenn die Nutzer/innen die vorberechneten Seiten nicht besuchten. Außerdem musstest du manuell auswählen, welche Links vorberechnet werden sollten, was nicht immer effektiv oder praktikabel war.
Um einige dieser Bedenken auszuräumen, hat Chrome das Prerendering mit dem Link rel=prerender zugunsten der NoState Prefetch-Methode abgeschafft, bei der Ressourcen für eine Seite abgerufen werden, ohne dass JavaScript oder andere potenziell in die Privatsphäre eingreifende Aktionen ausgeführt werden.
Die NoState Prefetch-Methode verbesserte das Laden von Ressourcen, konnte aber nicht wie ein vollständiger Prerender ein sofortiges Laden der Seite bewirken.
Einführung der Spekulationsregeln-API
Die Speculation Rules API ist eine neue experimentelle JSON-definierte API, die URLs spekulativ vorlädt, bevor sie angesteuert werden, was zu schnelleren Rendering-Zeiten und einem besseren Nutzererlebnis führt.
Die API ermöglicht es Entwicklern, Regeln mit einer im JSON-Format definierten Struktur innerhalb einer script type="speculationrules" zu konfigurieren, anhand derer der Browser entscheiden kann, welche URLs vorgerendert werden sollen.
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["firstpage.html", "secondpage.html"]
}
]
}
</script>Das Gleiche gilt für das Prefetching, das oft ein guter erster Schritt auf dem Weg zum Prerendering sein kann:
<script type="speculationrules">
{
"prefetch": [
{
"urls": ["firstpage.html", "secondpage.html"]
}
]
}
</script>Die obigen Codeschnipsel zeigen, wie die Speculation Rules API funktioniert, indem eine Liste von URLs angegeben wird, die vorabgerufen oder vorgerendert werden sollen.
Kürzlich kündigte Google neue Verbesserungen an der Speculation Rules API an, die nun die Möglichkeit der automatischen Linkfindung mithilfe von Dokumentenregeln bietet. Dabei werden URLs auf der Grundlage einer where Bedingung aus dem Dokument abgerufen.
<script type="speculationrules">
{
"prerender": [
{
"source": "document",
"where": {
"and": [
{
"href_matches": "/*"
},
{
"not": {
"href_matches": [
"/wp-login.php",
"/wp-admin/*"
]
}
}
]
},
"eagerness": "moderate"
}
]
}
</script>In diesem Codeschnipsel werden alle URLs auf der Seite für das Prerendering berücksichtigt, mit Ausnahme derer, die zu den WordPress Login- und Admin-Seiten führen. Außerdem legst du eine Stufe von eagerness fest – eager (sofort), moderate (bei einem Hover von 200ms) und conservative (bei Mausberührung oder Touchdown).
Alternativ oder in Verbindung mit href können auch CSS-Selektoren verwendet werden, um Links auf der aktuellen Seite zu finden:
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"and": [
{ "selector_matches": ".prerender" },
{ "not": {"selector_matches": ".do-not-prerender"}}
]
},
"eagerness": "moderate"
}]
}
</script>Wenn du die Speculation Rules API verwendest, kannst du sie mit den Hintergrunddiensten für spekulative Lasten in der Chrome-Anwendungsregisterkarte überprüfen, wenn du die Seite inspizierst.
Es gibt noch mehr davon – wir werden sie im Abschnitt Debugging untersuchen.
Browser-Unterstützung
Die Speculation Rules API wird in modernen Chromium-basierten Browsern, einschließlich Chrome und Edge, ab bestimmten Versionen unterstützt.
Dadurch wird sichergestellt, dass Nutzer/innen mit unterstützten Browsern von schnelleren Ladezeiten profitieren können, während Nutzer/innen anderer Browser keine negativen Auswirkungen zu spüren bekommen, da die API ein progressives Verbesserungswerkzeug ist.
Das Speculative Loading WordPress Plugin
Um die Vorteile der Speculation Rules API in WordPress zu nutzen, hat das WordPress Performance Team (zu dem auch Entwickler von Google gehören) kürzlich das Speculative Loading Plugin veröffentlicht. Dieses Plugin ermöglicht das spekulative Laden von auf der Seite verlinkten Frontend-URLs.
Bisher wurde das Plugin nur wenig genutzt, da sich die API noch in der Anfangsphase befindet, aber es gab bereits einige positive Bewertungen.
Standardmäßig ist das Plugin so konfiguriert, dass es WordPress-Frontend-URLs vorlädt, wenn der Nutzer mit dem Mauszeiger über einen relevanten Link fährt. Dies kann über den Abschnitt Speculative Loading unter Einstellungen > Lesen angepasst werden.
Das bedeutet, dass alle URLs, die auf der Seite verlinkt sind, mit einer eagerness Konfiguration von moderate vorgeladen werden, die normalerweise ausgelöst wird, wenn der Nutzer mit dem Mauszeiger über einen Link fährt. Du musst also nach der Aktivierung des Plugins nichts weiter tun; es funktioniert einfach von Haus aus.
Wenn du zum Beispiel das Plugin Speculative Loading bereits auf einer WordPress-Website installiert hast. Verwende die Chrome DevTools, um die Seite zu untersuchen, und klicke auf die Registerkarte Elemente. Wenn du nach unten scrollst, wirst du feststellen, dass script type="speculationrules" bereits mit den verschiedenen Spekulationsregeln für dich angelegt wurde.
Es verwendet eine Regex, um Links festzulegen, die vorgeladen werden sollen, legt Links fest, die nicht vorgeladen werden sollen, und legt die Eile fest. In den folgenden Abschnitten werden diese Regeln im Detail erklärt.
Limits zur Vermeidung von Überbeanspruchung
Chrome hat Beschränkungen eingeführt, um eine übermäßige Nutzung der API zu verhindern:
| Eifrigkeit | Prefetch | Prerender |
| sofort/eifrig | 50 | 10 |
| gemäßigt/konservativ | 2 (FIFO) | 2 (FIFO) |
Sie verhindern eine Überbeanspruchung durch verschiedene Einstellungen, die auf Dringlichkeit und Benutzerinteraktion basieren.
immediateundeager– Sie sind nicht von Benutzeraktionen abhängig und haben daher höhere Grenzen. Sie ermöglichen eine dynamische Kapazitätsanpassung, indem sie ältere Spekulationen entfernen.moderateundconservative– Im Gegensatz dazu sind diese Einstellungen benutzergesteuert und folgen einem First In, First Out (FIFO) Prinzip mit einer Obergrenze von 2, wobei die ältesten Spekulationen durch neue ersetzt werden, um Speicherplatz zu sparen.
Bestimmte URLs am Prefetching und Prerendering hindern
Es ist wichtig zu wissen, dass WP-Admin-Routen standardmäßig vom Prerendering und Prefetching ausgeschlossen sind. Als WordPress-Entwickler kannst du selbst festlegen, welche Routen du priorisieren möchtest.
Du kannst die Regeln für die URLs, die spekulativ vorgeladen werden sollen, mit dem Filter plsr_speculation_rules_href_exclude_paths anpassen.
Das folgende Codebeispiel stellt sicher, dass URLs wie https://wordpresssite.com/cart/ oder https://wordpresssite.com/cart/book/ vom Prefetching und Prerendering ausgeschlossen werden:
<?php
add_filter(
'plsr_speculation_rules_href_exclude_paths',
function ( $exclude_paths ) {
$exclude_paths[] = '/cart/*';
return $exclude_paths;
}
);Manchmal möchtest du vielleicht eine URL vom Prerendering ausschließen und zulassen, dass sie vorabgeruft wird. Zum Beispiel sollte eine Seite mit clientseitigem JavaScript zur Aktualisierung des Benutzerstatus wahrscheinlich nicht vorgerendert werden, aber es wäre sinnvoll, sie vorabgeruft.
Zu diesem Zweck erhält der Filter plsr_speculation_rules_href_exclude_paths den aktuellen Modus (entweder prefetch oder prerender), um bedingte Ausschlüsse zu ermöglichen.
So können wir z. B. sicherstellen, dass URLs wie https://wordpresssite.com/products/ nicht vorgeroutet werden können, während wir gleichzeitig zulassen, dass sie vorgeroutet werden.
<?php
add_filter(
'plsr_speculation_rules_href_exclude_paths',
function ( array $exclude_paths, string $mode ): array {
if ( 'prerender' === $mode ) {
$exclude_paths[] = '/products/*';
}
return $exclude_paths;
}
);Debuggen von Spekulationsregeln für WordPress-Websites
Das Debuggen von Spekulationsregeln kann knifflig sein, da pregerenderte Seiten in einem separaten Renderer gerendert werden – wie ein versteckter Hintergrund-Tab, der bei Aktivierung den aktuellen Tab ersetzt. Das Chrome-Team hat viel Arbeit in die DevTools gesteckt, damit du mit ihnen debuggen kannst.
In den Chrome DevTools navigierst du zum Reiter Anwendungen und scrollst dann nach unten zum Reiter Spekulative Lasten. Hier findest du Details über die Spekulation, die vorberechneten URLs, die fehlgeschlagenen URLs und vieles mehr.
Hier siehst du, dass fünf Links auf der Seite basierend auf den URLs, die den im JSON der Spekulationsregeln festgelegten Regeln entsprechen, vorberechnet werden können (siehe unten). Beachte, dass du nicht alle URLs auflisten musst; die Dokumentregeln ermöglichen es dem Browser, diese von den gleichen Ursprungslinks auf der Seite zu übernehmen.
Der „Status“ einiger Links wird als „Nicht ausgelöst“ angezeigt – der Prerender-Prozess für diese Links hat noch nicht begonnen. Wenn du jedoch mit dem Mauszeiger über die Links auf der Seite fährst, siehst du, wie sich der Status ändert, wenn die einzelnen URLs prerendered werden.
Denke daran, dass Chrome Grenzen für die Vorberechnung festgelegt hat, darunter maximal zwei Vorberechnungen für moderate eagerness. Wenn wir also mit dem Mauszeiger über den dritten Link fahren, sehen wir den Grund für das Scheitern dieser URL:
Es ist auch möglich, den Renderer, der von den DevTools-Panels verwendet wird, mit dem Dropdown-Menü oben rechts zu wechseln oder indem du eine URL im oberen Teil des Panels auswählst und Inspect wählst:
Dieses Dropdown-Menü (und der gewählte Wert) wird von allen anderen Panels genutzt, z. B. dem Netzwerk-Panel, in dem du sehen kannst, dass die angeforderte Seite die vorberechnete ist:
Oder im Elemente-Bedienfeld kannst du den Inhalt der Seite sehen:
Genauso wie du pregerenderte Seiten debuggen kannst, kannst du auch Seiten prefetchen. Achte beim Plugin „Spekulatives Laden“ darauf, dass du Prefetch als Spekulationsmodus auswählst.
Wenn du jetzt die Seite mit DevTools untersuchst und zur Registerkarte „Spekulatives Laden“ navigierst, lautet die Aktion für die verschiedenen URLs „Prefetch“, und auch die Regeln ändern sich.
Wenn du zur Registerkarte Netzwerk navigierst, nachdem du den Mauszeiger über einen Link bewegt hast, werden die Prefetch-Ressourcen als letztes angezeigt, wie du an der Spalte Typ erkennen kannst. Diese werden mit der niedrigsten Priorität abgerufen, da sie für zukünftige Navigationen bestimmt sind und Chrome den Ressourcen der aktuellen Seite Priorität einräumt.
Leistungsvergleich
Bis hierhin haben wir dir erklärt was das „Speculative Loading“-Plugin macht und wie es funktioniert. Genug der Theorie; lass uns die Leistung von zwei identischen Websites auf demselben Server (Kinsta’s WordPress Hosting) vergleichen.
Dazu habe ich zwei WordPress-Seiten mit dem MyKinsta-Dashboard auf demselben Rechenzentrum (Iowa (US Central), das mit Googles C3D VMs geboostet wird) und ohne Installation eines anderen Plugins für beide Seiten erstellt.
Die „Bare-Site“ ist ohne das Plugin, während für die „Speculative-Site“ das Plugin „Speculative Loading“ im WordPress-Dashboard installiert und aktiviert ist.
Es ist wichtig zu wissen, dass die Speculative Rules API nur die Ladezeit der nächsten Seite, die du aufrufen willst, verbessert – du kannst dies nicht anhand allgemeiner Website-Performance-Tools wie Lighthouse beurteilen.
Wir würden die Seitengeschwindigkeit testen, indem wir eine Seite von einem bestimmten internen Link auf den beiden Websites laden und die Registerkarte Netzwerk des Chrome DevTools verwenden, wenn du die Website inspizierst, um die Ladezeit und andere Informationen zu sehen.
Bei der „Bare-Site“ merkst du, dass das Laden länger dauert, da der gesamte Ladevorgang unterwegs stattfindet und der DOM-Inhalt gerade erst geladen wird:
Bei einer „Speculative-Site“ hingegen wurden die DOM-Inhalte bereits über die Speculative API geladen und zwischengespeichert.
Der Unterschied zwischen den beiden Seiten mag sehr gering erscheinen. In diesem Fall beträgt der Unterschied etwa 0,22 s, aber bei einer großen Website mit mehr Inhalten wird man einen deutlichen Unterschied bemerken.
Auswirkungen der Speculative Rules API auf die Analytik
Analytics ist wichtig, um die Nutzung der Website durch Seitenaufrufe und Ereignisse zu verfolgen und die Leistung durch Real User Monitoring (RUM) zu bewerten. Es ist wichtig zu wissen, dass das Prerendering die Analysen beeinflussen kann.
Wenn du zum Beispiel die Speculation Rules API verwendest, kann es sein, dass zusätzlicher Code erforderlich ist, um Analytics nur dann zu aktivieren, wenn die pregerenderten Seiten tatsächlich aufgerufen werden. Obwohl Google Analytics, Google Publisher Tag (GPT) und Google AdSense das Tracking verzögern, bis eine Seite aktiv ist, tun dies nicht alle Anbieter standardmäßig.
Deshalb kann ein Promise so eingerichtet werden, dass die Analyse erst bei der Aktivierung der Seite aktiviert wird:
// Promise to activate analytics on page activation for prerendered pages
const whenActivated = new Promise((resolve) => {
if (document.prerendering) {
document.addEventListener('prerenderingchange', resolve);
} else {
resolve();
}
});
async function initAnalytics() {
await whenActivated;
// Initialize analytics
}
initAnalytics();Zusammenfassung
Dieser Artikel erklärt, was die Speculative Rules API ist, wie sie funktioniert und wie du sie auf einer WordPress-Website nutzen kannst. Es handelt sich zwar noch um eine experimentelle Funktion, aber sie wird allmählich von vielen genutzt.
Noch sind die Spekulationsregeln auf Seiten innerhalb desselben Tabs beschränkt, aber es wird daran gearbeitet, diese Einschränkungen zu verringern.
Es ist auch wichtig zu wissen, dass ein großer Teil der Leistung deiner Website von der Qualität deines Hostings abhängt. Wir bei Kinsta sind dafür bekannt, erstklassiges WordPress-Hosting mit Dutzenden von Premium-Funktionen anzubieten.
Unsere Infrastruktur ist vollständig containerisiert und wird ausschließlich von der Google Cloud Platform im Google Premium Tier Netzwerk betrieben. Dadurch können wir dir eine große Auswahl der schnellsten Datenserver, unglaubliche Leistung, Caching auf Serverebene, dedizierte Ressourcen und verbesserte Sicherheit bieten.
Schau dir an, was unsere Kunden sagen, oder kontaktiere uns, um mehr über unsere Managed-Hosting-Lösung und ihre Vorzüge zu erfahren.
Was denkst du über die Speculative Rules API und ihre Einführung in WordPress? Teile sie in den Kommentaren unten mit!
Schreibe einen Kommentar