Die Frontend-Leistung optimieren – auch für Backend-Entwickler:innen
Die Frontend-Leistung optimieren – auch für Backend-Entwickler:innen
Backend-Entwickler:innen stoßen oft an ihre Grenzen, wenn es um die Leistung des Frontends geht – sie haben mit JavaScript-Fehlern, CSS-Macken oder langsam ladenden Seiten zu kämpfen. Diese Herausforderungen frustrieren die Benutzer:innen und haben für Webseitenbetreiber wirtschaftliche Auswirkungen.
Für viele Problemlösungen sind keine tiefgreifenden Frontend-Kenntnisse erforderlich. Wir schauen uns an, wie man Webseiten mit praktischen und wirkungsvollen Techniken schnell und einfach beschleunigen kann.
Backend-Metriken messen die Servergeschwindigkeit, doch das Nutzererlebnis wird von der Frontend-Leistung bestimmt. Core Web Vitals (CWV) [1] sind eine Reihe von Metriken, mit deren Hilfe Google die Qualität einer Webseite aus der Perspektive der Nutzer:innen bewertet. Wenn wir diese Schlüsselmetriken verstehen, können wir auf ihrer Grundlage Maßnahmen zur Verbesserung unserer Webseite ergreifen – schauen wir sie uns also einmal an.
Core Web Vitals geben Aufschluss über die Seitengeschwindigkeit und die Benutzerfreundlichkeit. Die wichtigsten Metriken dazu sind die Folgenden (Abb. 1):
Largest Contentful Paint (LCP): Misst, wie lange das größte sichtbare Element (z. B. das Hero Image) zum Laden benötigt, was die allgemeine Ladegeschwindigkeit widerspiegelt.
Cumulative Layout Shift (CLS): Zeigt an, wie oft sich Seitenelemente unerwartet verschieben. Es ist ein bekanntes Ärgernis, wenn der Inhalt beim Laden an eine andere Stelle springt.
Interaction to Next Paint (INP): Misst, wie schnell die Seite auf Benutzeraktionen reagiert, z. B. auf das Anklicken eines Buttons.
Google behauptet, dass die Optimierung dieser Metriken die Nutzererfahrung und möglicherweise auch die Platzierung in der Suchmaschine verbessert. Woher wissen wir, wie unsere Webseiten bei diesen Metriken abschneiden? Tools wie Google Search Console und PageSpeed Insights helfen uns, unsere CWV-Leistung effektiv zu messen.
Abb. 1: Die wichtigsten Metriken der Core Web Vitals, © web.dev
Search Console [2] bietet Einblicke in Links, Sitemaps und den allgemeinen Zustand der Webseite aus SEO-Sicht (Abb. 2). Sie enthält einen speziellen Abschnitt „Core Web Vitals“, in dem reale Leistungsmetriken angezeigt werden, die von Chrome-Nutzern anonym gemeldet werden (kein „bei mir funktioniert es gut!“ mehr).
Abb. 2: Metriken in Search Console
Allerdings liegen die Daten nicht in Echtzeit vor. Die Aktualisierungen können sich um bis zu 30 Tage verzögern, was die Feedbackschleife bei der Behebung von Problemen verlangsamt. Um schnelleres Feedback zu erhalten, wenden wir uns an PageSpeed Insights.
PageSpeed Insights [3] bewertet einen URL nach den wichtigsten CWV-Metriken und erstellt einen Top Line Score zwischen 0 (sehr schlecht) und 100 (sehr gut).
PageSpeed Insights kombiniert reale Nutzerdaten mit synthetischen Tests über Headless Chrome und identifiziert so wichtige Problembereiche. Lokale Tests könnten hier allerdings schwierig sein, da das Tool die Ergebnisse 15 Minuten lang zwischenspeichert und öffentlich zugängliche URLs benötigt. Zum Glück bieten die Chrome-Entwicklertools vollständige PSI-Testfunktionen für die lokale Entwicklung.
Die Durchführung von Tests für eine regelmäßige, objektive Überwachung wird durch Tools wie Lighthouse PHP von Spatie [4] entscheidend vereinfacht (Abb. 3). Die Kombination mit einem einfachen Dashboard (z. B. Laravel Jetstream [5]) ermöglicht ein fortlaufendes Tracking der Leistung für wichtige URLs.
Abb. 3: Seitengeschwindigkeit lokal testen mit Lighthouse
Es ist zu beachten, dass lokale Umgebungsfaktoren – wie verfügbarer Arbeitsspeicher oder laufende Hintergrundanwendungen – die Lighthouse-Ergebnisse verfälschen können, was konsistente Tests schwierig macht.
Jetzt wissen wir, wie wir die Geschwindigkeit messen können – aber wie können wir sie verbessern?
Bilder tragen oft am meisten zur Ladezeit einer Seite bei und machen bis zu 65 % der Nutzlast einer Webseite aus. Ihre Optimierung ist entscheidend für die Verbesserung der Ladezeit.
Die Größe der Bilder sollte genau dem Platz entsprechen, den sie auf der Seite einnehmen. Andernfalls muss der oder die Nutzer:in viel mehr Daten als nötig herunterladen, was unsere LCP-Bewertung beeinträchtigt (Abbildung 4).
Abb. 4: Dateien sollten in der richtigen Größe verwendet werden
Wir können uns nicht darauf verlassen, dass die Nutzer:innen der Anwendung optimale Größen hochladen – ein Nachrichtenredakteur z. B. wählt ein Foto aus, um eine Geschichte zu erzählen, und kümmert sich nicht darum, dass es 7 000 Pixel breit und 15 MB groß ist. Wir, die Anbieter der Seite, müssen sicherstellen, dass ein hochgeladenes Bild auf die von uns benötigte Größe gebracht wird. Anwendungen wie WordPress sorgen schon beim Hochladen dafür; ein On-Demand-Dienst wie Cloudinary [6] kann das während des laufenden Betriebs erledigen. So kann sichergestellt werden, dass das von uns bereitgestellte Bild immer eine angemessene Größe hat. Doch selbst dann, wenn ein Bild die korrekte Größe hat, ist es entscheidend, dass jedes Gerät, auf dem die Seite dargestellt werden kann, auch die richtige Bildversion erhält.
Der Codeblock oben links in Abbildung 5 könnte Nutzer:innen von älteren WordPress-Sites bekannt vorkommen. Es kann allerdings mittlerweile zu Problemen führen, wenn man URL-basiertes Caching verwendet, da wir heute verschiedene Caches für verschiedene Geräte benötigen – was unsere Cachelöschstrategie verkompliziert. Die Verwendung von srcset (Listing 1) liefert dagegen immer die korrekte Bildgröße für verschiedene Geräte, ohne unsere Cachestrategie zu verkomplizieren. Moderne Browser ermitteln automatisch das beste zu ladende Bild auf der Grundlage des von uns bereitgestellten Markups. So gewährleisten sie eine optimale Bilderbereitstellung, ohne dass manuelle Eingriffe nötig sind:
srcset: definiert mehrere Bilddateien mit ihren Breiten (w = Pixel)
sizes: übermittelt dem Browser, welche Bildgröße auf der Grundlage der Bildschirmbreite über Media-Queries geladen werden soll
Abb. 5: Verwendung eines einzigen Bildtags für alle Benutzer:innen
Listing 1
<img
srcset="small.jpg 480w, medium.jpg 800w, large.jpg 1200w"
sizes="(max-width: 600px) 480px, (max-width: 1024px) 800px, 1200px"
alt="A beautiful sunset">
Wir haben unsere Bilddateien jetzt verkleinert, können aber noch weiter gehen, indem wir die verwendeten Dateiformate optimieren. WebP bietet eine 25-30 Prozent bessere Komprimierung als JPG, während AVIF sogar noch größere Einsparungen ermöglicht. Beide Formate werden in PHP seit Version 8.1 unterstützt. Allerdings stellt sich bei jedem neuen Format die Frage, ob wir es auch für alle unsere Nutzer:innen verwenden können: Gibt es Browser, die ein Format nicht unterstützen, sodass wir uns über Polyfills und Fallbacks Gedanken machen müssen?
Abb. 6: AVIF-Unterstützung in modernen Browsern
caniuse.com [7] ist eine fantastische Ressource für die Bewertung der Browserunterstützung. Wenn man ein Bildformat, eine JavaScript-Funktion oder ein HTML-Attribut angibt, wird dort ein Diagramm erstellt, das zeigt, welcher Browser das fragliche Format seit wann unterstützt. Ein Blick auf die Statistiken in Abbildung 6 zeigt uns, dass unsere Nutzerschaft über Browser verfügt, die das AVIF-Format unterstützen, sodass wir unbesorgt auf die verbesserte Geschwindigkeit von AVIF-Bildern setzen können.
Durch die Optimierung von Bildern haben wir erhebliche Fortschritte bei der Verkürzung der Ladezeiten von Seiten und auf dem Weg zu einer verbesserten Benutzerfreundlichkeit erzielt. Wir können aber noch mehr tun.
Selbst bei richtig dimensionierten Bildern kann es beim Laden der Bilder zu Layoutverschiebungen auf der Seite (CLS) kommen. Diese Verschiebungen frustrieren Benutzer:innen und lassen eine Webseite unfertig wirken – doch mit Hilfe ein paar einfacher CSS-Techniken lassen sie sich verhindern. Das ist auch machbar für uns, die wir hauptsächlich Backend-Entwickler:innen sind, uns aber ins Frontend-Territorium wagen.
Listing 2
<div class="image-container">
<img … />
</div>
<style>
.image-container {
height: 250px;
}
/* Media query to handle responsive sites */
@media (min-width: 768px) {
.image-container {
height: 400px;
}
}
</style>
In unserem CSS definieren wir die Bildabmessungen, um sicherzustellen, dass Browser vor dem Laden der Bilder den nötigen Platz dafür reservieren. Dadurch werden Rückläufe beim Erscheinen von Bildern vermieden (Listing 2).
Während das bei querformatigen Bildern in der Regel gut funktioniert, können hochformatige Bilder manchmal ein wenig verloren aussehen. Eine schnelle und einfache Lösung dafür besteht darin, den Bildern einen Wrapper hinzuzufügen und eine weiche Hintergrundfarbe einzustellen. Wir könnten jedoch auch eine schöne visuelle Verzierung hinzufügen, ohne die Seitengeschwindigkeit negativ zu beeinflussen. Hierfür lassen wir uns von den Fernsehnachrichten inspirieren.
Wenn in Fernsehnachrichten Bildmaterial von Twitter oder TikTok gezeigt werden soll, wird ein Hochformatvideo in einem Querformatcontainer (nämlich dem Fernseher) gezeigt. Aber was passiert an beiden Seiten des Videos? Dieser Platz wird normalerweise mit einer unscharfen Version des Videos gefüllt – scharf genug, um erkennbar zu sein, unscharf...