Optimierung der Geschwindigkeit: Wie kann der Backend helfen?
Das Backend spielt eine entscheidende Rolle bei der Optimierung der Webgeschwindigkeit, da eine korrekte Optimierung von Code und Server Verzögerungen eliminieren kann, die häufig bei der Verarbeitung von Anfragen und der Bereitstellung von Inhalten auftreten.
Dieser Artikel richtet sich hauptsächlich an Backend-Entwickler oder Verwalter von Server-Infrastrukturen.
Einfluss des Backends auf Geschwindigkeitsmetriken
Beginnen wir mit der Feststellung, dass Geschwindigkeitsmetriken nicht nur eine Frontend-Angelegenheit sind. Das Backend beeinflusst viele Metriken, insbesondere auch die aus der Reihe der Core Web Vitals.
Die Geschwindigkeit des Backends messen wir mithilfe der Metrik Time To First Byte (TTFB). Der ideale Wert für TTFB liegt bei maximal 0,8 Sekunden. TTFB hat einen direkten Einfluss auf die Ladegeschwindigkeit der Webseite, speziell auf das Largest Contentful Paint (LCP), die Ladegeschwindigkeit des größten Seitenelements.
Dies wird durch das folgende vereinfachte Diagramm gut veranschaulicht. Wenn TTFB 2,6 Sekunden in Anspruch nimmt, haben wir ein Problem, und wir erreichen nicht den Grenzwert für die LCP-Metrik, der bei 2,5 Sekunden liegt. In einem solchen Fall kann selbst die beste Frontend-Optimierung Sie nicht retten, und Sie müssen auf Backend-Optimierung zurückgreifen.
Die Backend- und Frontend-Zeit zusammen ergeben den Wert der LCP-Metrik.
TIPP: Geschwindigkeitsoptimierung ist ein Schlüsselfaktor für den Erfolg einer Webseite. Eine schnelle Seite verbessert nicht nur die Benutzererfahrung, sondern kann auch zu einem besseren SEO-Ranking beitragen.
Neben LCP beeinflusst das Backend auch eine der unterstützenden Web Vitals-Metriken, nämlich das First Contentful Paint (FCP), die Geschwindigkeit des Renderns jeglicher Inhalte.
Die Optimierung des Backends ist die Grundlage, auf der weiter aufgebaut werden kann, selbst wenn Sie WordPress, Shoptet oder ein anderes CMS-System optimieren.
Allgemeine Tipps zur Beschleunigung des Backends
Es gibt unzählige potenzielle Stellen, an denen die TTFB-Metrik optimiert werden kann. Zu der oben beschriebenen Liste können wir noch einige „evergreen“ Punkte hinzufügen, darunter:
- Erhöhen Sie die Serverleistung (CPU, Speicher)
Ausreichende Serverressourcen können Anfragen schneller verarbeiten. - Optimieren Sie die Datenbank
Feinabstimmung der Datenbankeinstellungen, effiziente Abfragen und Nutzung von Indizes. - Verwenden Sie Cache
Implementieren Sie Caching auf Datenbank-, Speicher- (z. B. Redis) oder HTTP-Cache-Ebene für häufig wiederkehrende Anfragen oder Endpunkte, um die Notwendigkeit des erneuten Ladens von Daten aus der Datenbank zu eliminieren. - Achten Sie auf mehrfache Weiterleitungen
Lange Roundtrips verlängern die Gesamtladezeit der Seiten. - Optimieren Sie DNS und Netzwerklatenzen
Richten Sie ein optimiertes DNS ein und speichern Sie es im Cache, damit das Laden so schnell wie möglich erfolgt. In einigen Fällen kann auch der Umzug von Servern in Regionen näher am Zielpublikum helfen.
Wie kann ein Backend-Entwickler zur Webgeschwindigkeit beitragen?
Die folgenden Tipps zielen nicht direkt auf die Optimierung der TTFB-Metrik ab, können jedoch zur allgemeinen Verbesserung der Webgeschwindigkeit beitragen.
Datenkompression, Brotli, GZIP
Brotli und GZIP sind Methoden der verlustfreien Kompression, die das Datenvolumen beim Herunterladen von Textdateien wie CSS oder JS vom Server in den Browser reduzieren. Wenige wissen jedoch, dass GZIP und Brotli sogenannte Kompressionsstufen haben. Bei GZIP gibt es 9, bei Brotli sogar 11.
Im Allgemeinen empfehlen wir, die Kompressionsstufe auf 6 einzustellen. Höhere Stufen als 6 bringen keine wesentlichen Unterschiede in der Dateigröße, und je höher der Kompressionsgrad, desto höher die Serverbelastung und der Zeitaufwand.
Für Schriftarten (WOFF und WOFF2) verwenden Sie keine Kompression, da diese bereits aufgrund ihres Formattyps komprimiert sind. Wenn Sie keine Erfahrung mit der Komprimierungseinstellung haben, testen Sie zuerst die Kompressionsstufe hier. Dienste wie Cloudflare können eine gute Kompressionseinstellung automatisch für Sie übernehmen.
Möchten Sie Cloudflare auf Ihrer Website implementieren? Schauen Sie sich unseren Service Cloudflare-Einrichtung an.
Wenn Sie anstelle von Menschen von Robotern belastet werden, kann dies ein Problem für Geschwindigkeit und Stabilität sein. Werfen Sie einen Blick auf unseren Service Strategien für AI-Bots.
Ignorieren von UTM-Parametern
Es kommt häufig vor, dass Webseiten Cache verwenden, der ungültig wird, wenn in der URL ein Parameter enthalten ist. Es ist jedoch wichtig zu erkennen, dass ein UTM-Parameter aus inhaltlicher Sicht keine Änderung bedeutet, sondern nur für Analysetools verwendet wird.
Das Ignorieren von UTM-Parametern im Cache kann ein guter Optimierungsschritt sein, da es Sie von der doppelten Verteilung bei der TTFB-Metrik befreien kann, die für die Version mit und ohne Cache sehr typisch ist.
Ein Beispiel für zwei verschiedene Benutzergruppen bei der TTFB-Metrik – grün für gecachte, die andere nicht.
Ein solches Muster ist auch im Histogramm der CrUX-Daten im Domainbericht zu sehen.
Upgrade des Backend-Stacks
Die Wartung und Erhöhung der Versionen von Technologien in der Entwicklungsumgebung ist sehr wichtig. In neuen Versionen kommt es oft zu Leistungssteigerungen, was die Geschwindigkeit Ihres Projekts verbessern und technologischen Schulden vorbeugen kann.
Zum Beispiel können Sie bei PHP die einzelnen Versionen mithilfe von Benchmarks vergleichen. Beim Laravel-Framework kann eine Erhöhung der Version zu einem erheblichen Anstieg der bearbeiteten Anfragen pro Sekunde führen.
Die Leistung und die Anzahl der bearbeiteten Anfragen in PHP-Version 8.3 ist höher als in älteren Versionen.
Neue Bildformate (WebP, AVIF)
Die Formate von Webbildern haben in den letzten Jahren eine interessante Entwicklung durchlaufen, und derzeit können wir zwei neue Formate verwenden: WebP und AVIF. Ihr Hauptvorteil ist die höhere Datenkomprimierung. Beide Formate können Sie jetzt ohne Bedenken verwenden, da sie von allen modernen Browsern unterstützt werden.
Mit dem WebP-Format können Sie nativ in PHP arbeiten; von den wichtigen Parametern erwähnen wir $quality, das die Ausgabequalität des Bildes einstellt.
Mit dem neuen WebP-Format können Sie bis zu zig Prozent der Datenmenge von Bildern sparen.
AVIF ist nativ ab PHP-Version 8.1 und höher verfügbar, und hier können wir auch Parameter wie $quality und $speed einstellen.
Das AVIF-Format basiert auf dem Videoformat AV1 und hat leider einen Nachteil: Die Erstellung eines AVIF-Bildes dauert relativ lange. Wenn Sie nicht direkt mit Bildern arbeiten, kann beispielsweise Cloudflare die Implementierung neuer Formate für Sie übernehmen.
Mit dem neuen AVIF-Format können Sie bis zu zig Prozent der Datenmenge von Bildern sparen.
Eine detaillierte Anleitung zur Implementierung von AVIF, einschließlich unserer praktischen Erfahrungen, finden Sie im Artikel über das AVIF-Format. Dort finden Sie weitere Tipps zur Optimierung von Bildern auf der Webseite.
HTTP3
Interessante Entwicklungen und Beschleunigungen sehen wir auch auf der Ebene der Kommunikation zwischen Server und Client. HTTP3 bringt Verbesserungen, bei denen nicht bei jeder Kommunikation ein sogenannter Handshake erforderlich ist, wodurch der gesamte Prozess erheblich beschleunigt wird.
HTTP3 vereinfacht die Kommunikationsprozesse zwischen Server und Client erheblich.
Weitere Vorteile sind eine bessere Priorisierung heruntergeladener Dateien (z.B. wenn wir neben der Hauptdomäne weitere CDNs oder Subdomänen verwenden) und eine bessere Handhabung instabiler Verbindungen. Aus unserer Sicht definitiv eine Verbesserung, die es wert ist, in Betracht gezogen zu werden.
Early Hints
Eine weitere Effizienzsteigerung der Kommunikation zwischen Server und Client bietet 103 Early Hints. Vereinfacht gesagt handelt es sich dabei um noch schnellere Preloads und Preconnects, mit denen wir den früheren Beginn des Herunterladens von Ressourcen für das Web freischalten.
103 Early Hint
Link: </style.css>; rel=preload; as=style
Early Hints empfehlen wir nicht für eine große Anzahl von Dateien, aber sie können beim Herunterladen von Ressourcen, die das erste Rendering blockieren, nützlich sein. Ein gutes Beispiel wäre das Herunterladen von CSS mit Hilfe von Early Hints.
Zur einfacheren Verständlichkeit eine Infografik, die die Kommunikation zwischen Server und Client ohne und mit Early Hints zeigt.
Speculation Rules API
In diesem Jahr hat Chrome mit einer Verbesserung des Speculation Rules API aufgewartet, das das Vorladen von Seiten im Voraus ermöglicht. Bei der Implementierung des Speculation Rules API kann aktuell besser selektiert werden, z.B. mit Hilfe von CSS-Selektoren, sodass Sie leicht auf einen bestimmten Teil der Links zielen können. Sehr interessant ist die Möglichkeit prerender, bei der die Seite in den Speicher geladen wird und beim Klick sofort verfügbar ist.
<script type="speculationrules">
{
"prerender": [
{
"where": { "href_matches": "/next" },
"eagerness": "eager"
}
]
}
</script>
Normalerweise werden Speculation Rules im HTML definiert, aber wenn dies aus irgendeinem Grund in Ihrem Projekt nicht möglich ist, können sie auch in den HTTP-Headern gesendet werden:
Speculation-Rules: "/rules/prefetch.json","/rules/prerender.json"
Werkzeuge zur Überwachung von Metriken
Die Geschwindigkeit des Backends können Sie mithilfe spezialisierter Monitoring-Tools überwachen. Für unsere Praxis gilt erneut, dass die wichtigsten Daten von den Nutzern aus dem Chrome UX Report (CrUX) stammen, wo Sie die Werte der TTFB-Metrik finden.
Diese Daten können Sie im Monitoring PageSpeed.ONE PLUS verfolgen, wo sie in übersichtlicher Form im Domainbericht angezeigt werden. Der Vorteil des Testers besteht darin, dass er die Entwicklung der Metriken im Laufe der Zeit anzeigt.
Verfolgen Sie die historische Entwicklung der TTFB-Metrik im Diagramm.
Das Thema Optimierung beschäftigt uns langfristig und wir empfehlen, auch unsere weiteren Texte zu lesen:
- Testen von Web Vitals im Browser
- BFcache: Beschleunigen Sie den Nutzern das Bewegen in der Browser-Historie
Geschwindigkeitsüberwachung PLUS
Testen Sie unsere Monitoring-App einen Monat lang kostenlos.
5.400 Kč jährlich für die Website. Auf Rechnung, keine Kreditkarte nötig.