Jedes Mal, wenn ein Nutzer Ihre Webseite besucht, beginnt für ihn ein Wettlauf um den schnellstmöglichen Erhalt von Inhalten. Die Performance ist ein kritischer Faktor, der beeinflusst, wie Besucher mit Ihrer Website interagieren. Manch einer könnte meinen, dass die Übertragung von Inhalten über den Globus eine erhebliche Latenzzeit mit sich bringt, aber seit einiger Zeit nähern sich die Netzwerk-Übertragungsgeschwindigkeiten ihren theoretischen Grenzen. Zum Vergleich: Die Daten von Cloudflare können die 11.000 Kilometer lange Hin- und Rückreise zwischen New York und London in etwa 76 Millisekunden zurücklegen – schneller als ein Wimpernschlag.
Aufgrund der Komplexität der Verarbeitung von Anfragen, Antworten und Konfigurationen kommt es jedoch immer wieder zu Verzögerungen beim Laden von Webseiten. Zusätzlich zu den Fortschritten beim Verbindungsaufbau, der Komprimierung, der Hardware und der Software haben wir eine neue Möglichkeit entwickelt, die Latenzzeit beim Laden von Seiten zu reduzieren, indem wir vorhersehen, wie Besucher mit einer bestimmten Webseite interagieren werden.
Heute freuen wir uns sehr, Ihnen die neueste Innovation in Sachen Geschwindigkeit vorstellen zu können: Speed Brain. Sie stützt sich auf die Speculation Rules-API, um den Inhalt der wahrscheinlichen nächsten Navigationen des Nutzers vorab abzurufen. Das Hauptziel von Speed Brain ist es, eine Webseite in den Browser-Cache herunterzuladen, bevor ein Nutzer zu ihr navigiert, sodass Seiten fast sofort geladen werden, wenn die eigentliche Navigation stattfindet.
Unser erster Ansatz verwendet ein konservatives Modell, das statische Inhalte für die nächste Seite vorab abruft, wenn ein Nutzer ein Touch- oder Klickereignis auslöst. Bis zum vierten Quartal 2024 und bis 2025 werden wir aggressivere Spekulationsmodelle wie spekulatives Prerendering (die Seite wird nicht nur vor der Navigation abgerufen, sondern vollständig gerendert) anbieten, um ein noch schnelleres Erlebnis zu bieten. Schließlich wird Speed Brain lernen, wie man die Latenz für Ihre statische Website ohne jegliche Konfiguration eliminiert und mit Browsern zusammenarbeitet, um sicherzustellen, dass sie so schnell wie möglich geladen wird.
Stellen Sie sich zur Veranschaulichung eine E-Commerce-Website vor, auf der Kleidung verkauft wird. Anhand der Erkenntnisse aus unseren globalen Anfrageprotokollen können wir mit hoher Genauigkeit vorhersagen, dass ein typischer Besucher auf der übergeordneten Seite „Herren > Kleidung“ wahrscheinlich auf „Hemden“ klicken wird. So können wir statische Inhalte wie Bilder bereitstellen, bevor der Kunde überhaupt auf den Link „T-Shirts“ klickt. Dadurch wird die Seite sofort geladen, wenn der Kunde darauf klickt. Kürzliche durchgeführte Tests unserer aggressiven Lademodell-Implementierung haben gezeigt, dass der Largest Contentful Paint (Largest Contentful Paint, LCP), also die Zeit, die das größte sichtbare Element (z. B. ein Bild, ein Video oder ein Textblock) zum Laden und Rendern im Browser benötigt, um bis zu 75 % reduziert werden konnte.
Das beste an all dem? Wir machen Speed Brain für alle Tarifstufen sofort und kostenlos verfügbar. Aktivieren Sie einfach die Speed Brain-Funktion für Ihre Website über das Dashboard oder die API. Es wird sich wie Magie anfühlen, aber hinter den Kulissen steckt eine Menge clevere Technik.
Wir haben Speed Brain bereits standardmäßig für alle kostenlosen Domains aktiviert und stellen bei erfolgreichen Prefetches eine Reduzierung des LCP um 45 % fest. Für Pro-, Business- und Enterprise-Domains muss Speed Brain manuell aktiviert werden. Falls Sie dies noch nicht getan haben, empfehlen wir Ihnen dringend, auch Real User Measurements (RUM) über Ihr Dashboard zu aktivieren, damit Sie die neue und verbesserte Performance Ihrer Webseite sehen können. Als Bonus hilft uns die Aktivierung von RUM für Ihre Domain, in naher Zukunft verbesserte und individuelle Prefetching- und Prerendering-Regeln für Ihre Website bereitzustellen!
Die Funktionsweise von Browsern auf einen Blick
Bevor wir darauf eingehen, wie Speed Brain dazu beitragen kann, Inhalte außergewöhnlich schnell zu laden, müssen wir uns zunächst die Komplexität des Ladens von Inhalten in Browsern vergegenwärtigen. Jedes Mal, wenn ein Nutzer Ihre Webseite aufruft, muss eine Reihe von Anfrage- und Antwortzyklen durchlaufen werden.
Nachdem der Browser eine sichere Verbindung mit einem Server hergestellt hat, sendet er eine HTTP-Anfrage, um das Basisdokument der Webseite abzurufen. Der Server verarbeitet die Anfrage, erstellt das erforderliche HTML-Dokument und sendet es in der Antwort an den Browser zurück.
Wenn der Browser ein HTML-Dokument empfängt, beginnt er sofort mit dem Parsing des Inhalts. Während dieses Prozesses kann es auf Verweise auf externe Ressourcen wie CSS-Dateien, JavaScript, Bilder und Schriftarten stoßen. Diese untergeordneten Ressourcen sind für die korrekte Darstellung der Seite unerlässlich, sodass der Browser zusätzliche HTTP-Anfragen ausgibt, um sie abzurufen. Wenn diese Ressourcen jedoch im Cache des Browsers verfügbar sind, kann der Browser sie lokal abrufen, wodurch die Latenzzeit des Netzwerks erheblich reduziert und die Seitenladezeiten verbessert werden.
Während der Browser HTML, CSS und JavaScript verarbeitet, beginnt die Rendering-Engine, die Inhalte auf dem Bildschirm darzustellen. Sobald die visuellen Elemente der Seite angezeigt werden, führen Benutzerinteraktionen wie das Anklicken eines Links dazu, dass der Browser einen Großteil dieses Prozesses neu startet, um neuen Inhalt für die nächste Seite abzurufen. Dieser Arbeitsablauf ist typisch für jede Browsersitzung: Während die Nutzer navigieren, ruft der Browser kontinuierlich neue oder nicht zwischengespeicherte Ressourcen ab und rendert sie, wodurch eine Verzögerung entsteht, bevor die neue Seite vollständig geladen wird.
Nehmen wir das oben beschriebene Beispiel eines Nutzers, der auf einer Shopping-Website navigiert. Wenn der Kunde von der Homepage über den „Herren“-Bereich der Website zum Bereich „Kleidung“- und dann zum „Hemden“-Bereich wechselt, kann sich die Zeit, die er für das Abrufen jeder dieser nachfolgenden Seiten verbringt, summieren und dazu beitragen, dass der Käufer die Website verlässt, bevor er die Transaktion abschließt.
Im Idealfall würden die vorbereiteten und gerenderten Seiten im Browser zum Zeitpunkt des Anklickens der Links einen Großteil der Netzwerklatenz eliminieren, sodass der Browser die Inhalte sofort laden kann und ein reibungsloseres Nutzererlebnis gewährleistet ist.
Moment einmal, das kommt mir bekannt vor (wie kam es zur Entwicklung von Speed Brain?)
Wir wissen, was Sie sich denken. Prefetching gibt es schon seit Jahren. In der Vergangenheit gab es sogar bereits mehrere Ansätze für spekulatives Prefetching. Das haben Sie alles schon einmal gehört. Inwiefern ist das jetzt anders?
Sie haben natürlich recht. Im Laufe der Jahre haben Entwickler und Browserhersteller ständig versucht, die Seitenladezeiten zu optimieren und die Nutzererfahrung im gesamten Web zu verbessern. Es wurden zahlreiche Techniken entwickelt, die sich über verschiedene Schichten des Internet -Stacks erstrecken von der Optimierung der Konnektivität auf der Netzwerkschicht bis hin zum Vorladen von Anwendungsinhalten in größerer Nähe zum Client.
Frühes Prefetching: Mangel an Daten und Flexibilität
Web Prefetching ist eine solche Technik, die es schon seit mehr als einem Jahrzehnt gibt. Sie beruht auf der Annahme, dass bestimmte untergeordnete Ressourcen wahrscheinlich in naher Zukunft benötigt werden; warum sie also nicht proaktiv abrufen? Das kann alles sein, von HTML-Seiten bis hin zu Bildern, Stylesheets oder Skripten, die der Nutzer beim Navigieren durch eine Website benötigen könnte. Tatsächlich ist das Kernkonzept der spekulativen Ausführung nicht neu. Es handelt sich um eine allgemeine Technik, die seit Jahren in verschiedenen Bereichen der Informatik eingesetzt wird, wobei die Sprungvorhersage in CPUs als bestes Beispiel gilt.
In den frühen Tagen des Internets entstanden mehrere benutzerdefinierte Prefetching-Lösungen zur Steigerung der Performance. So stellte Google 2005 den Google Web Accelerator vor, eine clientseitige Anwendung, die das Surfen für Breitbandnutzer beschleunigen sollte. Obwohl das Projekt innovativ war, war es aufgrund von Datenschutz- und Kompatibilitätsproblemen nur von kurzer Dauer (wir werden weiter unten beschreiben, wie sich Speed Brain davon unterscheidet). Dem Predictive Prefetching fehlten damals die Dateneinblicke und die API-Unterstützung, um das Verhalten der Nutzer zu erfassen, insbesondere bei sensiblen Aktionen wie Löschungen oder Käufen.
Statische Listen und manueller Aufwand
Traditionell wurde das Prefetching durch die Verwendung des Attributs <link rel="prefetch"> als einem der Resource Hints erreicht. Die Entwickler mussten das Attribut auf jeder Seite manuell für jede Ressource angeben, die der Browser im Voraus abrufen und im Speicher zwischenspeichern sollte.Dieser manuelle Aufwand war nicht nur mühsam, sondern den Entwicklern fehlte auch oft der Einblick in die Ressourcen, die vorab geholt werden sollten, was die Qualität der von ihnen angegebenen Hinweise minderte.
In ähnlicher Weise bietet Cloudflare seit 2015 eine URL-Prefetching-Funktion an. Anstatt die Daten im Browser-Cache vorab abzurufen, können Kunden mit Cloudflare eine statische Liste von Ressourcen vorab in den CDN-Cache abrufen. Diese Funktion ermöglicht es, Ressourcen schon vor dem Zeitpunkt abzurufen, an dem sie tatsächlich benötigt werden, d. h. in der Regel während der Leerlaufzeit oder wenn die Netzwerkbedingungen günstig sind. Allerdings gelten für das CDN-Prefetching ähnliche Bedenken, da die Kunden für jede Seite, die sie besitzen, manuell entscheiden müssen, welche Ressourcen für das Prefetching in Frage kommen. Bei einer Fehlkonfiguration kann das Prefetching von statischen Links zu einer Verlangsamung und dazu führen, dass sich die Ladezeit von Webseite tatsächlich verschlechtert.
Server Push und damit verbundene Probleme
„Server Push“ von HTTP/2 war ein weiterer Versuch, die Webperformance zu verbessern, indem Ressourcen an den Client übertragen wurden, bevor sie angefordert wurden. Theoretisch würde dies die Latenzzeit verringern, da zusätzliche Roundtrips für zukünftige Assets entfallen. Die Server-zentrierte, diktatorische Art des „Pushens" von Ressourcen an den Client warf jedoch erhebliche Probleme auf, vor allem aufgrund des fehlenden Kontexts darüber, was bereits im Browser zwischengespeichert war. Dadurch wurde nicht nur Bandbreite verschwendet, sondern es bestand auch die Gefahr, dass die Bereitstellung kritischer Ressourcen wie Basis-HTML und CSS aufgrund von Wettlaufsituationen bei Browserabrufen beim Rendern der Seite verlangsamt wurde. Die vorgeschlagene Lösung mit „Cache Digests“, die Server über den Inhalt des Client-Cache informiert hätte, fand nie breite Anwendung, sodass die Server Ressourcen blindlings pushen können. Im Oktober 2022 entfernte Google Chrome die Server Push-Unterstützung, und im September 2024 zog Firefox nach.
Ein Schritt vorwärts mit Early Hints
Als Nachfolger wurde Early Hints 2017 spezifiziert, aber erst 2022 weit verbreitet, als wir mit Browsern und wichtigen Kunden zusammenarbeiteten, um es zu implementieren. Es bietet eine effizientere Alternative, indem es den Clients „Hinweise“ darauf gibt, welche Ressourcen geladen werden sollen, und so eine bessere Priorisierung je nach den Bedürfnissen des Browsers ermöglicht. Konkret sendet der Server den HTTP-Statuscode „103 Early Hints“ mit einer Liste der wichtigsten Seitenelemente, die der Browser laden soll, während die Hauptantwort noch in Vorbereitung ist. Dies verschafft dem Browser einen Vorsprung beim Abrufen wichtiger Ressourcen und vermeidet überflüssiges Vorladen, wenn Assets bereits im Cache gespeichert sind. Obwohl sich Early Hints (noch) nicht an das Verhalten von Nutzern oder dynamische Seitenbedingungen anpasst, beschränkt sich seine Verwendung in erster Linie auf das Vorladen bestimmter Assets und nicht auf vollständige Webseiten insbesondere in Fällen, in denen die HTML-Erzeugung über eine lange Server-„Denkzeit“ erfolgt.
Mit der Weiterentwicklung des Web werden Tools, die komplexe, dynamische Nutzerinteraktionen bewältigen können, immer wichtiger, um die Performance-Gewinne der spekulativen Ausführung mit ihren potenziellen Nachteilen für Endnutzer in Einklang zu bringen. Cloudflare bietet seit Jahren Performance-basierte Lösungen an, die sich an das Verhalten der Nutzer anpassen und dafür sorgen, dass Geschwindigkeit und Korrektheit von Entscheidungen im gesamten Internet in eine gesunde Balance gebracht werden, wie Argo Smart Routing, Smart Tiered Cache und Smart Placement. Heute machen wir einen weiteren Schritt in Richtung eines anpassungsfähigen Frameworks für die blitzschnelle Bereitstellung von Inhalten.
Hier kommt Speed Brain ins Spiel: Was zeichnet es aus?
Speed Brain bietet einen robusten Ansatz für die Implementierung von prädiktiven Prefetching-Strategien direkt im Browser, basierend auf dem von unseren Servern zurückgesendeten Regelsatz. Aufbauend auf den Erkenntnissen aus früheren Versuchen verlagert es die Verantwortung für die Ressourcenvorhersage auf den Client und ermöglicht so dynamischere und personalisierte Optimierungen auf der Grundlage der Interaktion des Nutzers – z. B. wenn er mit dem Mauszeiger über einen Link fährt – und seiner Gerätefähigkeiten. Anstatt dass der Browser tatenlos darauf wartet, dass die nächste Webseite vom Benutzer angefordert wird, nimmt er Hinweise daran, wie ein Benutzer mit einer Seite interagiert, und beginnt, nach der nächsten Webseite zu fragen, bevor der Benutzer auf einen Link geklickt hat.
Hinter den Kulissen wird all diese Magie durch die Speculation Rules-API ermöglicht, einen neuen Google-Standard im Bereich der Webperformance. Wenn das Speed Brain-Feature von Cloudflare aktiviert ist, wird ein HTTP-Header namens Speculation-Rules den Antworten von Webseite hinzugefügt. Der Wert für diesen Header ist eine URL, die eine meinungsbasierte Regelkonfiguration hostet. Diese Konfiguration weist den Browser an, Prefetch-Anfragen für zukünftige Navigationen zu initiieren. Speed Brain verbessert die Seitenladezeit für die erste besuchte Seite einer Webseite nicht, kann sie aber für nachfolgende Webseiten derselben Website verbessern.
Die Idee scheint einfach zu sein, aber das Prefetching bringt Herausforderungen mit sich, da einige vorab abgerufene Inhalte möglicherweise nie verwendet werden. Mit der ersten Version von Speed Brain haben wir eine Lösung mit Leitplanken entwickelt, die zwei wichtige, aber unterschiedliche Probleme angeht, die frühere Spekulationsbemühungen ausgebremst haben – veraltete Prefetch-Konfiguration und inkorrektes Prefetching. Die Konfiguration der Speculation Rules-API , die wir für diese erste Version gewählt haben, wurde sorgfältig entwickelt, um ein ausgewogenes Maß an Sicherheit beim Prefetching zu gewährleisten und gleichzeitig die breite Anwendbarkeit der Regeln für die gesamte Website zu gewährleisten.
Veraltete Prefetch-Konfiguration
Da sich Websites im Laufe der Zeit unweigerlich verändern, sind statische Prefetch-Konfigurationen oft veraltet, was zu ineffizientem oder ineffektivem Prefetching führt. Das galt insbesondere für Techniken wie das Attribut rel=prefetch oder statische CDN-Prefetching-URL-Sätze, bei denen die Entwickler relevante prefetchbare URL-Listen für jede Seite ihrer Website manuell pflegen mussten. Die meisten statischen Prefetch-Listen basieren auf der Intuition der Entwickler und nicht auf realen Navigationsdaten der Nutzer, wobei möglicherweise wichtige Prefetch-Möglichkeiten übersehen werden oder Ressourcen für unnötige Prefetches verschwendet werden.
Falsches Prefetching
Da Prefetch-Anfragen genau wie normale Anfragen sind, nur mit einem `sec-purpose`-HTTP-Anfrage-Header, verursachen sie bei Client, Netzwerk und Server den gleichen Mehraufwand. Der entscheidende Unterschied besteht jedoch darin, dass Prefetch-Anfragen das Verhalten des Nutzers vorwegnehmen und die Antwort möglicherweise nicht verwendet wird, sodass der gesamte Aufwand verschwendet sein könnte. Aus diesem Grund ist die Genauigkeit des Prefetching extrem wichtig, d.h. die Maximierung des Prozentsatzes der Prefetching-Seiten, die vom Nutzer tatsächlich angezeigt werden. Falsches Prefetching kann zu Ineffizienzen und unnötigen Kosten führen, z. B. durch das Zwischenspeichern von Ressourcen, die nicht angefordert werden, oder durch die Verschwendung von Bandbreite und Netzwerkressourcen, was besonders in mobilen Netzwerken mit Gebühren oder in Umgebungen mit geringer Bandbreite kritisch ist.
Leitplanken
Mit der ersten Version von Speed Brain haben wir eine Lösung mit wichtigen Leitplanken zur Vermeidung von Nebeneffekten entwickelt, die das Risiko einer veralteten Prefetch-Konfiguration vollständig ausschließt und das Risiko eines falschen Prefetchings minimiert. Diese nachvollziehbare Konfiguration wird durch die Nutzung der Dokumentregeln (Document Rules) und der Eagerness-Einstellungen der Speculation Rules-API erreicht. Die von uns gewählte Konfiguration sieht wie folgt aus:
{
"prefetch": [{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*", "relative_to": "document" },
]
},
"eagerness": "conservative"
}]
}
Document Rules
Document Rules, angegeben durch "source": "document" und den Schlüssel "where" in der Konfiguration, ermöglicht die dynamische Anwendung von Prefetching auf die gesamte Webseite. Dadurch wird eine vordefinierte statische URL-Liste für das Prefetching überflüssig. Das Problem veralteter Prefetch-Konfigurationen, wird damit beseitigt, da die für das Prefetching in Frage kommenden Links auf der Grundlage der aktiven Seitenstruktur ermittelt werden.
Unsere Verwendung von „relative_to“: „document“ in der where-Klausel weist den Browser an, das Prefetching auf Links zu derselben Website zu beschränken. Dies hat den zusätzlichen Vorteil, dass unsere Implementierung herkunftsübergreifende Prefetches vermeidet, um Auswirkungen auf die Privatsphäre der Nutzer zu vermeiden, da sie ihnen nicht durch das Web folgt.
Eagerness
Eagerness steuert, wie aggressiv der Browser Inhalte vorab abruft. Es gibt vier mögliche Einstellungen:
immediate (sofort): sofort: Wird so schnell wie möglich beim Laden der Seite verwendet – in der Regel beginnt der Browser, sobald er den Wert der Regel sieht, mit dem Prefetch der nächsten Seite.
eager (eifrig): Identisch mit der obigen sofortigen Einstellung, aber der Prefetch-Trigger verlässt sich zusätzlich auf leichte Interaktionen mit Nutzern, wie das Bewegen des Cursors in Richtung des Links (bald verfügbar).
moderate (moderat): Führt einen Prefetching durch, wenn Sie den Pointer länger als 200 Millisekunden über einen Link halten (oder beim Pointerdown-Ereignis, wenn das früher der Fall ist, und auf Mobilgeräten, wo es kein Hover-Event gibt).
conservative (konservativ): Ruft Prefetches beim Pointer oder Touch-Down auf dem Link ab.
Unsere erste Version von Speed Brain nutzt den konservativen Eagerness-Wert, um das Risiko eines falschen Prefetchings zu minimieren, das zu unbeabsichtigter Ressourcenverschwendung führen kann, und macht Ihre Websites gleichzeitig spürbar schneller. Wir verlieren zwar die potenziellen Performanceverbesserungen, die aggressiveren Eagerness-Einstellungen bieten, aber wir haben diesen vorsichtigen Ansatz gewählt, um die Sicherheit für unsere Nutzer zu priorisieren. Für die Zukunft planen wir, dynamischere Eifer-Einstellungen für Websites zu erforschen, die von einer liberaleren Einstellung profitieren könnten, und wir werden unsere Regeln auch auf das Prerendering erweitern.
Eine weitere wichtige Sicherheitsmaßnahme besteht darin, dass wir Prefetch-Anfragen nur für statische Inhalte akzeptieren, die bereits in unserem CDN-Cache gespeichert sind. Wenn die Inhalte nicht im Cache sind, lehnen wir die Prefetch-Anfrage ab. Durch den direkten Abruf von Inhalten aus unserem CDN-Cache für Prefetching-Anfragen können wir Bedenken hinsichtlich der Cache-Eignung ausräumen. Der Grund dafür ist einfach: Wenn eine Seite nicht für die Zwischenspeicherung in Frage kommt, wollen wir nicht, dass sie vorab im Browser-Cache abgerufen wird, da dies zu unbeabsichtigten Folgen und einer erhöhten Belastung des Ursprungsservers führen könnte. Beispielsweise kann das Vorabrufen einer Abmeldeseite den Benutzer frühzeitig abmelden, bevor der Benutzer seine Aktion tatsächlich beendet hat. Zustandsbehaftete Prefetching- oder Prerendering-Anfragen können unvorhersehbare Auswirkungen haben und möglicherweise den Zustand des Servers für Aktionen ändern, die der Client nicht bestätigt hat. Indem wir das Prefetching nur für Seiten erlauben, die sich bereits in unserem CDN-Cache befinden, haben wir die Gewissheit, dass sich diese Seiten nicht negativ auf die Nutzererfahrung auswirken.
Diese Leitplanken wurden für Performance-sensible Umgebungen implementiert. Anfang Juli 2024 haben wir die Auswirkungen unseres konservativen Bereitstellungsmodells auf alle Seiten in der Entwicklerdokumentation von Cloudflare gemessen. Wir stellten fest, dass wir in 94 % der Fälle die richtigen Inhalte vorwegnehmen konnten, d.h. Inhalte, zu denen die Nutzer tatsächlich navigieren würden. Gleichzeitig konnten wir die Performance der Navigation verbessern, indem wir die LCP am p75-Quantil um 40 % reduzierten, ohne dass es zu unbeabsichtigten Nebenwirkungen kam. Die Ergebnisse waren erstaunlich!
So funktioniert die Implementierung von Cloudflare
Unser globales Netzwerk erstreckt sich über 330 Städte und ist innerhalb von 50 Millisekunden von 95 % der mit dem Internet verbundenen Bevölkerung erreichbar. Dank dieser großen Reichweite können wir die Performance zwischenspeicherbarer Assets für unsere Kunden erheblich verbessern. Durch die Nutzung dieses Netzwerks für das intelligente Prefetching mit Speed Brain kann Cloudflare vorab abgerufene Inhalte direkt aus dem CDN-Cache bereitstellen und so die Latenzzeit auf praktisch sofortige reduzieren.
Unsere einzigartige Position innerhalb des Netzwerks gibt uns die Möglichkeit, Speed Brain automatisch zu aktivieren, ohne dass unsere Kunden Änderungen an den Konfigurationen ihrer Ursprungsserver vornehmen müssen. Dafür müssen Sie bloß einen Schalter umlegen! Unsere erste Version von Speed Brain ist jetzt live.
Wenn eine Anfrage für eine Webseite mit aktiviertem Speed Brain eingeht, gibt der Cloudflare-Server einen zusätzlichen HTTP-Antwort-Header „Speculation-Rules“ zurück. Der Wert für diesen Header ist eine URL, die eine rechtmäßige Regelkonfiguration (wie oben erwähnt) hostet.
Wenn der Browser mit dem Parsen des Antwort-Headers beginnt, ruft er unsere Speculation-Rules-Konfiguration ab und lädt sie als Teil der Webseite.
Die Konfiguration weist den Browser an, wann er die nächste wahrscheinliche Seite von Cloudflare abrufen soll, zu der der Besucher navigieren kann, je nachdem, wie der Besucher die Seite nutzt.
Wenn eine Aktion des Nutzers (z. B. ein Mausklick auf den Link zur nächsten Seite) die Rules-Anwendung auslöst, sendet der Browser eine Prefetch-Anfrage für diese Seite mit dem HTTP-Anfrage-Header „sec-purpose: prefetch“.
Unser Server analysiert den Anfrage-Header, um die Prefetch-Anfrage zu identifizieren. Wenn der angeforderte Inhalt in unserem Cache vorhanden ist, geben wir ihn zurück; andernfalls geben wir den HTTP-Statuscode 503 zurück und lehnen die Prefetch-Anfrage ab. Dadurch entfällt das Risiko unsicherer Nebeneffekte beim Senden von Anfragen an Ursprungsserver oder Cloudflare Workers, die vom Prefetching nichts wissen. Es werden nur Inhalte zurückgegeben, die ausschließlich im Cache vorhanden sind.
Bei einer Erfolgsantwort ruft der Browser den Inhalt aus dem Speicher erfolgreich vor, und wenn der Besucher zu dieser Seite navigiert, lädt der Browser die Webseite direkt aus dem Browser-Cache und rendert sie sofort.
Gängige Muster bei der Fehlerbehebung
Die Unterstützung für Speed Brain basiert auf der Speculation Rules-API, einem neuen Webstandard. Ab September 2024 ist die Unterstützung für diesen neuen Standard auf Chromium-basierte Browser (Version 121 oder höher) wie Google Chrome und Microsoft Edge beschränkt. Sobald die Web-Community einen Konsens über die API-Standardisierung erreicht, hoffen wir auf eine breitere Akzeptanz bei anderen Browser-Anbietern.
Prefetching gilt naturgemäß nicht für dynamische Inhalte, da sich der Zustand dieser Inhalte ändern kann, was möglicherweise dazu führt, dass veraltete oder überholte Daten an den Endnutzer übermittelt werden und die Ursprungsserver belastet. Daher funktioniert Speed Brain nur für nicht-dynamische Seiten Ihrer Website, die in unserem Netzwerk zwischengespeichert sind. Es hat keine Auswirkungen auf das Laden dynamischer Seiten. Um den größten Nutzen aus Speed Brain zu ziehen, empfehlen wir die Verwendung von Cache-Regeln, um sicherzustellen, dass alle statischen Inhalte (insbesondere HTML-Inhalte) auf Ihrer Website für die Zwischenspeicherung geeignet sind.
Wenn der Browser als Antwort auf eine spekulative Prefetch-Anfrage (gekennzeichnet durch den sec-purpose: prefetch-Header) den HTTP-Statuscode 503 empfängt, bricht er den Prefetch-Versuch ab. Obwohl ein 503-Fehler in der Konsole des Browsers alarmierend erscheinen mag, ist er für den Abbruch einer Prefetch-Anfrage völlig harmlos. In unseren ersten Tests hat der 503-Antwortcode bei einigen Websitebesitzern Bedenken ausgelöst. Wir arbeiten mit unseren Partnern daran, dies zu überarbeiten, um die Kundenerfahrung zu verbessern, aber im Moment folgen wir den Anweisungen der Spezifikation, die eine 503-Antwort vorschlägt, damit der Browser die spekulative Anfrage sicher verwerfen kann. Wir befinden uns in aktiven Gesprächen mit Chrome, basierend auf dem Feedback von ersten Beta-Testern, und sind der Meinung, nd glauben, dass ein neuer, nicht fehlerbezogener Antwortcode angemessener wäre und weniger Verwirrung stiften würde. In der Zwischenzeit sind 503-Antwortprotokolle für Prefetch-Anfragen im Zusammenhang mit Speed Brain harmlos. Wenn Ihr Tool es schwierig macht, diese Anfragen zu ignorieren, können Sie Speed Brain vorübergehend deaktivieren, bis wir mit dem Chrome-Team eine bessere Lösung gefunden haben.
Wenn eine Website außerdem sowohl ihre eigenen benutzerdefinierten Speculation Rules als auch das Speed Brain-Feature von Cloudflare verwendet, können beide Regelsätze gleichzeitig eingesetzt werden. Die Leitplanken von Cloudflare beschränken die Regeln für Spekulationen auf cachefähige Seiten, was für diejenigen mit bestehenden Implementierungen eine unerwartete Einschränkung darstellen kann. Wenn Sie ein solches Verhalten beobachten, sollten Sie erwägen, eine der Implementierungen für Ihre Website zu deaktivieren, um ein einheitliches Verhalten zu gewährleisten. Beachten Sie: Wenn Ihre Ursprungsserver Antworten den Speculation-Rules-Header enthalten, wird dieser nicht überschrieben. Daher besteht die Gefahr von Regelsatzkonflikten in erster Linie bei vordefinierten Regeln für Inline-Spekulationen.
Wie kann ich die Auswirkungen von Speed Brain sehen?
Im Allgemeinen empfehlen wir Ihnen, Speed Brain und die meisten anderen Performance-Funktionen von Cloudflare zu nutzen, wenn unser Tool zur Messung der RUM-Performance aktiviert ist. Unsere RUM-Funktion hilft Entwicklern und Website-Betreibern zu verstehen, wie ihre Endnutzer die Performance ihrer Anwendung erleben, und bietet Einblick in:
Laden: Wie lange hat es gedauert, bis die Inhalte verfügbar waren?
Interaktivität: Wie reaktionsfähig ist die Website, wenn Nutzer mit dieser interagieren?
Visuelle Stabilität: Wie stark bewegt sich die Seite beim Laden?
Wenn RUM aktiviert ist, können Sie im Dashboard zum Abschnitt „Web Analytics“ navigieren, um wichtige Informationen darüber anzuzeigen, wie Speed Brain zur Reduzierung der Latenzzeit bei Ihren Core Web Vitals wie Largest Contentful Paint (LCP) und der Ladezeit beiträgt.
Beispiel für ein RUM-Dashboard für eine Website mit einem hohen Anteil an vorabrufbaren Inhalten, die Speed Brain um den 16. September herum aktiviert hat.
Was haben wir bisher bei unserer Einführung festgestellt?
Wir haben diese Funktion standardmäßig bei allen kostenlosen Tarifen aktiviert und dabei Folgendes festgestellt:
Domains
Cloudflare hat derzeit mehrere zehn Millionen Domains, die Speed Brain nutzen. Wir haben die LCP am 75. Quantil (p75) für diese Standorte gemessen und eine Verbesserung für diese Standorte zwischen 40 % und 50 % (im Durchschnitt etwa 45 %) festgestellt.
Wir haben diese Verbesserung durch den Vergleich von navigationsbasierten Prefetches mit normalen (solchen ohne Prefetching) Seitenaufrufen für dieselbe Gruppe von Domains festgestellt.
Anfragen
Bevor Speed Brain aktiviert ist, haben die p75 der kostenlosen Websites auf Cloudflare einen LCP von etwa 2,2 Sekunden. Wenn Speed Brain aktiviert ist, können diese Standorte erhebliche Latenzzeiteinsparungen bei LCP verzeichnen. Insgesamt spart Speed Brain bei jedem erfolgreichen Prefetch etwa 0,88 Sekunden und bis zu 1,1 Sekunden!
Anwendbare Browser
Derzeit ist die Speculation Rules-API nur in Chromium-Browsern verfügbar. Anhand von Cloudflare Radar können wir sehen, dass etwa 70 % der Anfragen von Besuchern von Chromium-Browsern (Chrome, Edge usw.) stammen.
Über das Netzwerk hinweg
Cloudflare verzeichnet jeden Tag Hunderte von Milliarden von Anfragen für HTML-Inhalte. Von diesen Anfragen wird etwa die Hälfte zwischengespeichert (stellen Sie sicher, dass Ihr HTML cachefähig ist!). Etwa 1 % dieser Anfragen sind für das Prefetching auf Basis der Navigation der Webbesucher bestimmt. Das bedeutet täglich erhebliche Einsparungen für die Besucher von Websites, auf denen Speed Brain aktiviert ist. Alle 24 Stunden kann Speed Brain mehr als 82 Jahre an Latenzzeit einsparen!
Was ist als Nächstes geplant?
Was wir heute für Speed Brain anbieten, ist nur der Anfang. Für das Jahr 2025 haben wir eine Reihe von spannenden Ergänzungen zu erkunden und zu veröffentlichen.
Einsatz von Machine Learning
Unsere einzigartige Position im Internet bietet uns wertvolle Einblicke in die Muster beim Surfen im Internet, die wir zur Verbesserung der Web-Performance bei gleichzeitiger Wahrung der Privatsphäre der individuellen Nutzer nutzen können. Durch einen verallgemeinerten datengesteuerten Machine-Learning-Ansatz können wir genauere und standortspezifische Prefetch-Prädiktoren für die Seiten der Nutzer definieren.
Wir sind dabei, ein adaptives spekulatives Modell zu entwickeln, das unser derzeitiges konservatives Angebot erheblich verbessert. Dieses Modell verwendet eine datenschutzfreundliche Methode, um einen User-Traversal-Graph für jede Website auf der Grundlage von Referrer-Headern derselben Seite zu erstellen. Für zwei Seiten, die durch einen navigationsbasierten Hop miteinander verbunden sind, prognostiziert unser Modell die Wahrscheinlichkeit, dass ein typischer Nutzer zwischen den Seiten wechselt, indem es Erkenntnisse aus unseren aggregierten Traffic-Daten nutzt.
Dieses Modell ermöglicht es uns, Regelsätze mit benutzerdefinierten Eagerness-Werten für jeden relevanten Link zur nächsten Seite auf Ihrer Website zu erstellen. Bei Seiten, bei denen das Modell ein hohes Vertrauen in die Navigation des Nutzers voraussagt, wird das System diese aggressiv vorabrufen oder prerendern. Wenn das Modell keine Regel für eine Seite vorgibt, wird standardmäßig unser bestehender konservativer Ansatz verwendet, sodass die Vorteile des Speed Brain-Basismodells erhalten bleiben. Diese Signale leiten die Browser beim Prefetching und Prerendering der entsprechenden Seiten, was dazu beiträgt, die Navigation der Nutzer zu beschleunigen und gleichzeitig unsere aktuellen Sicherheitsleitplanken einzuhalten.
In Labortests verbesserte unser ML-Modell die LCP-Latenzzeit um 75 % und sagte die Besuchernavigation mit einer Genauigkeit von ~98 % voraus. Dadurch wurde sichergestellt, dass die richtigen Seiten vorgeladen wurden, um Ressourcenverschwendung für Nutzer zu vermeiden. Auf dem Weg zur Skalierung dieser Lösung konzentrieren wir uns darauf, das Modell regelmäßig zu trainieren, um es an das veränderte Verhalten der Nutzer und die sich entwickelnden Websites anzupassen. Durch den Einsatz eines internetbasierten Machine Learning-Ansatzes wird der Bedarf an manuellen Aktualisierungen und Abweichungen von Inhalten bei gleichbleibend hoher Genauigkeit drastisch reduziert – die Speed Brain Load-Lösung, die mit der Zeit immer intelligenter wird!
Feinere Beobachtbarkeit durch RUM
Wie wir bereits erwähnt haben, sind wir der Meinung, dass unsere RUM-Tools die besten Erkenntnisse darüber liefern, wie Speed Brain die Performance Ihrer Website verbessert. Für die Zukunft planen wir, RUM-Tools nach Navigationsart zu filtern, sodass Sie die Browser-Rendering von vorab abgerufenen Inhalten mit denen von nicht vorab abgerufenen Inhalten vergleichen können.
Prerendering
Wir bieten derzeit die Möglichkeit des Prefetching für zwischenspeicherbare Inhalte an. Beim Prefetching wird die primäre Dokumentressource der Seite vor der Navigation des Nutzers heruntergeladen, aber der Browser wird nicht angewiesen, die Seite vorzurendern oder zusätzliche Unterressourcen herunterzuladen.
In Zukunft wird das Speed Brain-Angebot von Cloudflare Inhalte in unseren CDN-Cache vorberechnen und dann mit den Browsern zusammenarbeiten, um zu wissen, welche Inhalte sich am besten für das Prerendering eignen. Dies wird dazu beitragen, dass statische Inhalte noch schneller gerendert werden können.
Argo Smart Browsing: Speed Brain & Smart Routing
Speed Brain bietet in seiner ersten Implementierung einen unglaublichen Performance-Schub, bleibt aber bei der Implementierung immer noch konservativ; und zwar sowohl hinsichtlich der Eagerness als auch hinsichtlich des Ressourcenverbrauchs.
Wie bereits in diesem Beitrag erwähnt, haben Labortests mit einem aggressiveren Modell, das auf Machine Learning und einer höheren Eagerness basiert, eine Reduzierung der LCP um 75 %. Wir prüfen, ob wir diese aggressivere, zusätzliche Implementierung von Speed Brain mit Argo Smart Routing in einem Produkt namens „Argo Smart Browsing“ bündeln.
Cloudflare-Kunden können Speed Brain weiterhin nutzen. Wer jedoch eine noch bessere Performance wünscht, kann Argo Smart Browsing mit einem einzigen Mausklick aktivieren. Mit Argo Smart Browsing werden nicht nur cachefähige statische Inhalte dank der aggressiveren Modelle bis zu 75 % schneller im Browser geladen. In Fällen, in denen Inhalte nicht gecacht werden können und die Anfrage an einen Ursprungsserver weitergeleitet werden muss, wird sie über den leistungsfähigsten Netzwerkpfad gesendet, was zu einer durchschnittlichen Performance-Steigerung von 33 % führt. Performance-Optimierungen werden auf fast jedes Segment des Lebenszyklus von Anfragen angewandt, unabhängig davon, ob es sich um statische oder dynamische Inhalte handelt, ob sie im Cache gespeichert sind oder nicht.
Fazit
Um die ersten Schritte mit Speed Brain zu setzen, navigieren Sie einfach im Cloudflare-Dashboard zu Speed > Optimierung > Content-Optimierung > Speed Brain und aktivieren Sie die Lösung. Das ist alles! Die Funktion kann auch per API aktiviert werden. Bei Domains im Free-Tarif ist Speed Brain standardmäßig aktiviert.
Wir empfehlen unseren Kunden dringend, auch RUM zu aktivieren, das sich im selben Bereich des Dashboards befindet, um die Performance-Verbesserungen durch Speed Brain und andere Cloudflare-Funktionen und -Produkte zu sehen.
Wir freuen uns darauf, weiterhin Produkte und Funktionen zu entwickeln, die Performance des Internets zuverlässig schnell machen. Wenn Sie als Entwickler oder Entwicklerin daran interessiert sind, die Webperformance für alle zu verbessern, kommen Sie zu uns!