Sofortiges Laden von Seiten mit Speculation Rules
Erfahren Sie, wie Sie die Core Web Vitals verbessern können, indem Sie Seiten mit der neuen Speculation Rules API sofort laden lassen
Core Web Vitals sofort verbessern mit der 'Speculation Rules API'
Haben Sie sich jemals gefragt, warum manche Seiten sofort zu laden scheinen? Das liegt wahrscheinlich daran, dass diese Seite Speculation Rules implementiert hat!
Die Speculation Rules API verbessert die Geschwindigkeit zukünftiger Seitenladevorgänge in Multi-Page-Applications (MPAs) durch Prefetching oder sogar Prerendering. Entwickler können konfigurieren, wie Speculation Rules dem Browser vorschlagen sollen, Dokumente für schnellere (oder sofortige) Seitenladevorgänge vorab abzurufen oder zu rendern. Speculation Rules ersetzen ältere Techniken wie `<link rel="prefetch">` für das Prefetching von Ressourcen oder das veraltete Chrome-only Feature `<link rel="prerender">`.
Speculation Rules arbeiten auf Dokumentebene, was sie für MPAs geeignet macht, die vollständige Seitennavigationen beinhalten. Single-Page-Applications (SPAs), die hauptsächlich API-Aufrufe oder partielle Inhaltsaktualisierungen verwenden, würden von dieser API für ihre internen Routenänderungen nicht so sehr profitieren. Dennoch können Speculation Rules auch SPAs zugute kommen, indem sie den Anfangszustand der Anwendung von einer Landingpage aus vorrendern, was die anfängliche Ladezeit potenziell ausgleichen kann.
Speculation Rules Schnellstart
Wissen Sie schon, was Speculation Rules sind? Großartig! Hier sind einige sofort einsatzbereite Schnipsel für Sie, um sofort loszulegen. Wählen Sie einfach den richtigen Schnipsel für Sie aus und platzieren Sie ihn im <head> Ihrer Seite (fühlen Sie sich frei, preload in prefetch und oder die eagerness zu ändern)!
<!--
WordPress Speculation Rules von corewebvitals.io
prefetcht alle internen Links
überspringt Links, die wp-login, wp-admin, wp content entsprechen
überspringt Links, die das nofollow-Attribut haben
überspringt Links, die einen Query-String haben, zum Beispiel: /search->
<script type="speculationrules">
{
"prefetch": [{
"source": "document",
"where": {
"and": [{ "href_matches": "\/*"},{ "not": { "href_matches": [ "\/wp-login.php", "\/wp-admin\/*", "\/*\\?*", "\/wp-content\/*", ] }
},{ "not": { "selector_matches": "a[rel~=\"nofollow\"]" }
}]
},
"eagerness": "moderate"
}]
}
</script> <!-- Data-preload ausgelöste Speculation Rules von corewebvitals.io -->
<script type="speculationrules">
{
"prefetch": [{
"source": "document",
"where": {
"selector_matches": "a[data-preload]"
},
"eagerness": "moderate"
}]
}
</script> Tipp: Wenn Sie schnell Ihre eigenen Speculation Rules erstellen müssen, warum probieren Sie nicht den Speculation Rules Generator aus?
Vorteile von Speculation Rules
Verbesserte User Experience (UX): Durch die Vorhersage und das Vorladen von Inhalten stellen Speculation Rules nahezu sofortige Seitenladevorgänge sicher, wodurch sich die Navigation für Benutzer nahtlos anfühlt. Dies konkurriert mit der Leistung von Single-Page-Applications auch für traditionelle Multi-Page-Websites ohne die Komplexität und Javascript-Abhängigkeit. Schnellere Ladezeiten bedeuten ein besseres Surferlebnis, was wahrscheinlich die Benutzerbindung erhöht und die Absprungraten reduziert.
SEO-Vorteile: Da verbesserte Seitengeschwindigkeit ein direkter Rankingfaktor ist und eine bessere Time to First Byte zu einem besseren Largest Contentful Paint führt, wird die Implementierung von Speculation Rules zwangsläufig die Core Web Vitals verbessern und Ihnen diesen Pagespeed-Bonus geben.
Reduzierte Komplexität: Nahezu sofortige Seitenladevorgänge waren früher durch die Verwendung einer SPA oder das Schreiben benutzerdefinierter Prefetch-Logik für MPAs möglich.
Für viele Anwendungsfälle ist der Nachteil einer SPA die anfängliche Boot-Up-Zeit, die beträchtlich sein kann, da sie stark auf JavaScript angewiesen sind, und die erhöhte Komplexität im Vergleich zu einer MPA. Speculation Rules haben diese Probleme nicht. Dies macht schnelles Laden für eine breitere Palette von Websites erreichbar, insbesondere für inhaltsorientierte.
Die API vereinfacht auch den Prozess der Entscheidung, welche Seiten vorgerendert werden sollen, indem sie einen Großteil der Logik an den Browser delegiert. Dies ist eine enorme Verbesserung gegenüber früheren Methoden, die auf JavaScript angewiesen waren, um diese Prüfungen durchzuführen und Seiten zum Vorladen einzufügen. Browser können nativ den Benutzerkontext berücksichtigen, wie z. B. wenig Speicher auf mobilen Geräten oder den Batteriesparmodus, wenn sie entscheiden, ob sie vorrendern sollen. Diese dynamische Anpassung hilft, Benutzerressourcen zu schonen und sorgt für ein reibungsloseres Erlebnis auch unter Einschränkungen.
Andere Vorteile: Der Speculation-Rules HTTP-Header ermöglicht eine einfachere Bereitstellung über Content Delivery Networks (CDNs), wodurch die Notwendigkeit entfällt, den Dokumentinhalt direkt zu ändern. Granulare Kontrolle mit Dokumentregeln ermöglicht es Entwicklern, genaue Bedingungen für das Prefetching oder Prerendering basierend auf URL-Mustern oder CSS-Selektoren zu definieren. Dies reduziert die manuelle URL-Spezifikation und ermöglicht seitenweite Speculation-Regets. Die Einstellung "Eagerness" bietet eine fein abgestimmte Kontrolle darüber, wann Spekulationen stattfinden, und gleicht die Vorladegeschwindigkeit mit dem Ressourcenverbrauch ab. Dies hilft, unnötiges Vorladen zu reduzieren und Ressourcenverschwendung zu verhindern.
Speculation Rules Mechanik
Speculation Rules werden unter Verwendung einer JSON-Struktur definiert und können auf zwei Arten implementiert werden:
- Inline-Skript: Fügen Sie das JSON innerhalb eines `<script type="speculationrules">` Tags ein, entweder im `<head>` oder `<body>` des Haupt-HTML-Dokuments.
- HTTP-Header: Liefern Sie Regeln unter Verwendung des `Speculation-Rules` HTTP-Headers in der Antwort des Dokuments aus. Dieser Header verweist auf eine JSON-Datei, die die Regeln enthält, was CDN-Bereitstellungen erleichtert, ohne den HTML-Inhalt direkt zu ändern.
Die JSON-Struktur verwendet "prefetch" und "prerender" Arrays, um Regeln für jeden spekulativen Ladetyp zu enthalten. Jede Regel kann verschiedene Quellen verwenden: entweder eine Liste von URLs oder Dokumentregeln.
- urls (eine Liste von URLs) Ein Array von URLs zum Vorabrufen oder Vorrendern.
- where (Dokumentregeln) Ein Objekt, das Bedingungen verwendet, um zu bestimmen, welche Links auf der Seite vorabgerufen oder vorgerendert werden sollen.
Jede Regel ist als Objekt definiert, das Eigenschaften enthält wie:
- requires Ein Array von Strings, um Einschränkungen für Spekulationen festzulegen. Derzeit ist der einzige gültige String "anonymous-client-ip-when-cross-origin", was angibt, dass ein Cross-Origin Prefetch die IP-Adresse des Clients anonymisieren sollte.
- target_hint Ein String, der einen Hinweis auf den navigierbaren Zielnamen gibt, der es dem User-Agent ermöglicht, den Ladeprozess zu optimieren. Er hat keine normativen Auswirkungen außer ein Hinweis zu sein.
- referrer_policy Eine Referrer-Policy, die auf vorabgerufene oder vorgerenderte URLs angewendet werden soll.
- relative_to (Nur für "list" Quelle) Gibt an, ob die im "urls" Array bereitgestellten URLs relativ zur Basis-URL des Dokuments ("document") oder zum Speicherort der Speculation-Rules-JSON-Datei ("ruleset") sind.
- eagerness Steuert, wie aggressiv der Browser vorabrufen oder vorrendern soll. Die verfügbaren Einstellungen sind "immediate", "eager", "moderate" und "conservative", jede mit unterschiedlichen Auslösern.
- expects_no_vary_search Ein String, der verwendet wird, um einen URL-Suchvarianz-Hinweis zu geben, der es Entwicklern ermöglicht zu signalisieren, ob die spekulierte URL eine andere Antwort basierend auf den Suchparametern haben soll. .
Schließlich hat jede Regel eine Eagerness-Einstellung, mit der Sie definieren können, wann Spekulationen ausgeführt werden sollen, wobei getrennt wird, wann spekuliert werden soll, von welchen URLs Spekulationen durchgeführt werden sollen. Die Eagerness-Einstellung ist sowohl für Listen- als auch für Dokumentquellenregeln verfügbar und hat vier Einstellungen: immediate, eager, moderate, und conservative.
- immediate: Dies wird verwendet, um so schnell wie möglich zu spekulieren, sobald die Speculation Rules beobachtet werden.
- eager: Dies verhält sich derzeit identisch mit der Einstellung immediate, aber in der Zukunft wird es irgendwo zwischen immediate und moderate platziert werden.
- moderate: Dies führt Spekulationen durch, wenn Sie mit der Maus über einen Link fahren für 200 Millisekunden (oder beim Pointerdown-Event, wenn das früher ist, und auf Mobilgeräten, wo es kein Hover-Event gibt).
- conservative: Dies spekuliert bei Pointer- oder Touch-Down.
Prefetch oder Prerender
Die Speculation Rules API unterstützt zwei Hauptformen des spekulativen Ladens: Prefetching und Prerendering. Obwohl beide Techniken zu schnelleren Seitenladevorgängen führen können, unterscheiden sie sich in ihrer Komplexität und ihrem Ressourcenverbrauch.
- Prefetching, ist die 'leichtere Form' des spekulativen Ladens. Es lädt das HTML der Ziel-URL herunter und cached es, ohne die Seite oder ihre Unterressourcen zu rendern. Dieser Ansatz verbessert hauptsächlich die Time To First Byte. Eine verbesserte Time to First Byte führt zu besseren Paint-Metriken wie dem Largest Contentful Paint und First Contentful Paint.
- Prerendering macht viel mehr als nur das HTML herunterzuladen. Es lädt das HTML, alle Unterressourcen und rendert die gesamte Seite in einem versteckten, unsichtbaren Tab. Bei der Navigation zu dieser Seite führt dies zu einer nahezu sofortigen Anzeige. Diese Techniken verbessern den Largest Contentful Paint auf mehr Arten als nur durch Verbesserung der Time to First Byte. Es lädt und rendert auch das LCP-Element. Prerendering kann auch den Cumulative Layout Shift eliminieren, da Ressourcendimensionen bereits nach dem Prerendering bekannt sind.
Was ist also besser? Prerendering oder Prefetching? Das hängt von der Seite und dem 'durchschnittlichen Besucher' ab. Während Prerendering schneller sein mag, verbraucht die Wahl konstruktionsbedingt auch viel mehr Ressourcen, sowohl auf dem Client als auch auf dem Server. Die Wahl für Prerendering oder Prefetching hängt ab von:
- Gerätefunktionen des Benutzers: Prerendering ist möglicherweise nicht die beste Wahl, wenn ein hoher Prozentsatz der Besucher Geräte mit begrenztem Speicher verwendet
- Spezifität der Prerender- oder Prefetch-Regel. 'Einige Links werden wahrscheinlicher angeklickt und einige Seiten konvertieren wahrscheinlicher' Diese Seiten sind perfekte Kandidaten für eine Prerender-Regel. Andere Seiten sind möglicherweise besser für Prefetch geeignet.
CoreWebVitals.io möchte vor übermäßigem Prerendering warnen, aufgrund seiner Ressourcenanforderungen, insbesondere auf mobilen Geräten oder langsameren Verbindungen. Die potenziellen Vorteile des Prerenderings müssen gegen das Risiko einer Leistungsverschlechterung und Ressourcenverschwendung abgewogen werden.
Die richtige 'Eagerness' einstellen - der Spagat
Welche Eagerness-Einstellung verwendet werden soll, hängt von Ihrer Website ab. Für eine sehr einfache statische Website kann eifrigeres Spekulieren wenig kosten und für Benutzer vorteilhaft sein. Websites mit komplexeren Architekturen und schwereren Seiten-Payloads ziehen es möglicherweise vor, Verschwendung zu reduzieren, indem sie seltener spekulieren, bis Sie ein positiveres Absichtssignal von Benutzern erhalten, um Verschwendung zu begrenzen.
Die Eagerness-Einstellung in der Speculation Rules API beeinflusst, wann ein Browser Inhalte basierend auf der vorhergesagten Benutzernavigation vorabrufen oder vorrendern soll. Diese Einstellung bietet einen Kompromiss zwischen der Maximierung der Vorladevorteile und der Minimierung der Ressourcenverschwendung.
Die Standard-Eagerness für Listenregeln ist immediate. Die Optionen moderate und conservative können verwendet werden, um Listenregeln auf URLs zu beschränken, mit denen ein Benutzer interagiert. In vielen Fällen können Dokumentregeln mit einer geeigneten Where-Bedingung angemessener sein.
Die Standard-Eagerness für Dokumentregeln ist conservative. Da ein Dokument aus vielen URLs bestehen kann, sollte die Verwendung von immediate oder eager für Dokumentregeln mit Vorsicht erfolgen.
Die Wahl der Eagerness hängt von der Struktur der Website, den Verhaltensmustern der Benutzer und der Einschätzung des Entwicklers hinsichtlich des potenziellen Ressourcenverbrauchs gegenüber den Vorteilen für die Benutzererfahrung ab. Zum Beispiel könnte eine einfache statische Seite von einer "eager" Einstellung profitieren, was zu schnelleren Ladezeiten führt. Umgekehrt können Websites mit komplexen Architekturen und anspruchsvollen Seiten-Payloads einen weniger aggressiven "moderate" oder "conservative" Ansatz wählen, um die Ressourcennutzung zu begrenzen, bis eine klarere Benutzerabsicht erkannt wird.
Bei der Konfiguration der Eagerness sollten Entwickler Benutzererfahrung, Ressourcenkosten und Browserbeschränkungen berücksichtigen. Übermäßige Spekulation kann die Bandbreite, den Speicher und die CPU des Benutzers belasten und die Leistung potenziell beeinträchtigen, insbesondere in eingeschränkten Netzwerken oder Geräten. Chrome erzwingt Grenzen für gleichzeitig vorabgerufene und vorgerenderte Seiten, um Überbeanspruchung zu mindern. Darüber hinaus können Faktoren wie benutzerkonfigurierte Data Saver-Modi, niedrige Batteriestände oder Browsererweiterungen Speculation Rules außer Kraft setzen und die Ressourcenschonung priorisieren.
Speculation Rules prüfen und debuggen
Um auf Speculation Rules auf einer Seite zu prüfen, öffnen Sie die Chrome DevTools, gehen Sie zum Bereich Anwendung, und navigieren Sie zu Hintergrunddienste > Spekulative Ladevorgänge > Spekulationen. (Öffnen Sie das Spekulationen-Fenster, bevor Sie die Seite laden, die Sie debuggen möchten) Dieses Panel bietet Informationen über:
- Die Anzahl erfolgreicher Spekulationen.
- Einzelne URLs, die vorgerendert oder vorabgerufen werden.
- Der Status jeder Spekulation.
Der Netzwerk-Track im Leistungs-Panel zeigt die Netzwerkaktivität im Zusammenhang mit vorgerenderten Ressourcen an, ohne den DevTools-Kontext wechseln zu müssen. Darüber hinaus können Sie den DevTools-Kontext auf eine vorgerenderte Seite umschalten, um sie wie eine normale Seite zu inspizieren.
Überwachung und Analyse von Speculation Rules
- Real User Monitoring (RUM): Nutzen Sie RUM-Tools, um die tatsächliche Benutzererfahrung zu messen. Beobachten Sie Metriken wie Largest Contentful Paint (LCP), um die Auswirkungen von Speculation Rules auf Seitenladezeiten zu bewerten. Suchen Sie nach Verbesserungen im LCP für vorgerenderte Seiten im Vergleich zu nicht vorgerenderten Seiten.
- A/B Testing: Führen Sie A/B-Tests durch, um verschiedene Speculation-Rule-Konfigurationen zu vergleichen und das optimalste Setup für Ihre spezifische Website und Benutzerbasis zu identifizieren.
Überlegungen - die schlechten Dinge
Ressourcenverbrauch: Übermäßige Spekulation kann sich negativ auf Bandbreite, Speicher und CPU-Auslastung auswirken.
Browser-Kompatibilität: Nicht alle Browser unterstützen die Speculation Rules API vollständig, prüfen Sie also auf Browserkompatibilität vor der Implementierung.
Datenschutz: Entwickler sollten darauf achten, wie Speculation Rules Surfverhalten von Benutzern offenbaren könnten, und angemessene Datenschutzmaßnahmen implementieren.
Die Speculation Rules API bietet einen leistungsstarken Ansatz zur Verbesserung der Leistung und Benutzererfahrung von Webanwendungen. Durch das Verständnis ihrer Mechanik, Vorteile und Überlegungen können Entwickler diese API nutzen, um schnellere und ansprechendere Websites zu erstellen.
Speculation Rules WordPress Code
Das WordPress Core Performance Team hat ein Speculation Rules Plugin erstellt, das das Hinzufügen von Dokumentregelunterstützung zu jeder WordPress-Site zu einer Ein-Klick-Angelegenheit macht. Das Plugin bietet zwei Gruppen von Einstellungen:
- Speculation Mode: Wählen Sie zwischen prefetch und prerender. Prerendering führt zu schnelleren Ladezeiten als Prefetching. Jedoch könnte Prefetching eine sicherere Wahl für interaktive Inhalte sein.
- Eagerness: Wählen Sie zwischen conservative (typischerweise bei Klick), moderate (typischerweise bei Hover), oder eager (beim geringsten Vorschlag). Die Eagerness-Einstellung bestimmt, wie schnell spekulative Ladevorgänge ausgelöst werden.
