Der entscheidende erste Eindruck: Ladezeiten optimieren
Die initiale Ladezeit Ihrer Webseite oder App ist von enormer Bedeutung, da sie den ersten Eindruck prägt, den Nutzer von Ihrem Angebot erhalten. Dieser Artikel beleuchtet bewährte Methoden, die Ihnen helfen, wertvolle Sekunden beim ersten Seitenaufruf zu gewinnen.
Bedeutung der anfänglichen Ladezeit
Die Zeitspanne zwischen der Eingabe einer Webadresse durch den Nutzer und dem vollständigen Anzeigen der Inhalte ist kritisch. In diesen ersten Sekunden wird der Grundstein für die Nutzererfahrung gelegt.
Studien von Amazon zeigen, dass bereits eine Verzögerung von 100 Millisekunden zu einem Umsatzverlust von 1 % führen kann. Viele Webentwickler unterschätzen die Relevanz dieses Aspekts. Immer mehr Bibliotheken und Funktionen werden integriert, was sukzessive zu einer sinkenden Conversion-Rate führt. Diese Verluste bleiben oft unerkannt, da Nutzer die Seite aufgrund der langen Ladezeit verlassen, bevor Messdaten gesendet werden können.
Einige Optimierungen können im Frontend, andere im Backend durchgeführt werden, jedoch ist eine schnelle Ladezeit für jede Webanwendung essenziell.
Den Ladevorgang genau analysieren
Der erste Schritt zur Optimierung ist das genaue Messen des Ladevorgangs. Dieser besteht aus verschiedenen Phasen, und ohne die Analyse der jeweiligen Segmente lassen sich Engpässe nicht identifizieren.
Hier sind die wichtigsten Meilensteine des Ladevorgangs:
| Messungen | Diagramm erstellt bei Terrastruktur |
Es ist wichtig, Metriken für jedes Segment zu erfassen.
Betrachten wir, wie dies umgesetzt werden kann.
Browser-Anfrage zur Server-Antwort:
Messen Sie dies auf Ihrer Serverseite. Erfassen Sie den Zeitpunkt, an dem die Anfrage Ihre API erreicht und die Antwort gesendet wird. Externe Aufrufe, z.B. an Datenbanken, können diesen Vorgang erheblich verlängern.
Verarbeitung der Server-Antwort im Browser:
Diese Messung ist anspruchsvoller. Eine Möglichkeit ist, einen Zeitstempel beim Verlassen des Servers hinzuzufügen und diesen auf der Benutzerseite, idealerweise im Header der HTML-Seite, mit der aktuellen Zeit zu vergleichen.
Erhaltene Antwort bis zum ersten sichtbaren Inhalt:
Das „First Contentful Paint“ beschreibt den Moment, in dem das erste Element im DOM gerendert wird. Dies kann ein Text, ein Hintergrund oder ein Ladesymbol sein. Die Messung kann mit dem Tool Lighthouse in den Chrome-Entwicklertools erfolgen.
Erstes sichtbares Element bis zum größten sichtbaren Element:
Das „Largest Contentful Paint“ zeigt an, wann das größte Element im Browser-Viewport des Benutzers gerendert wird. Dies signalisiert in der Regel das Ende des „Rendering“-Prozesses und der Nutzer sieht den vollständigen Bildschirm. Auch diese Metrik wird mit Lighthouse gemessen.
Größtes sichtbares Element bis zur Interaktivität:
Die „Time to Interactive“ misst die Zeit, bis der Nutzer mit der Seite interagieren kann (Scrollen, Klicken etc.). Eine lange Wartezeit kann frustrierend sein, wenn der Bildschirm zwar sichtbar ist, aber keine Aktionen möglich sind. Auch hier hilft Lighthouse bei der Messung.
Code-Größe reduzieren
Nach der Analyse beginnt die Optimierungsphase. Jede Optimierung hat ihren Preis, und die Messungen zeigen, welche sich lohnen.
Eine leere Seite lädt am schnellsten, jedoch kann auch eine komplexe App schnell sein, wenn der Code optimiert ist. Oftmals führen minimale, unbemerkte Veränderungen zu einer Verlangsamung. Die App wird aufgebläht, und Code-Reduzierung ist die einzige Lösung.
Durch Code-Reduktion erreichen Sie zwei Geschwindigkeitsverbesserungen:
- Schnellere Übertragung über das Netzwerk.
- Schnelleres Parsen des Codes im Browser.
Die Geschwindigkeitssteigerung durch eine kleinere Datenübertragung ist gering, da Anfragen komprimiert werden. Die Einsparung kann nur wenige Kilobyte betragen. Der Effekt des schnelleren Parsens ist jedoch beachtlich. Nutzer verwenden verschiedene Geräte, viele mit geringerer Rechenleistung, und der Browser benötigt länger, um den Code zu verarbeiten. Dieser Unterschied kann sich in Sekunden bemerkbar machen.
Je weniger Code, desto schneller kann der Browser die Verarbeitung abschließen und die App starten. Selbst ein Ladebildschirm benötigt eine schnelle Verarbeitung durch Javascript.
Es ist nicht das Ziel, Funktionen oder Code zu löschen. Standardpraktiken helfen, die Code-Größe zu reduzieren, ohne die Funktionen zu beeinträchtigen:
- Minifizierer verwenden: Minifizierer optimieren den Code durch Verkürzung langer Variablennamen, Entfernung von Leerzeichen und andere Kompaktierungen.
- Partials importieren: Bibliotheken enthalten oft nicht benötigten Code. Importieren Sie nur die benötigten Funktionen einer Bibliothek anstatt der gesamten Bibliothek.
- „Tree-Shaking“ von totem Code: Entfernen Sie Code, der nicht ausgeführt wird, z.B. Debugging-Code oder veraltete Funktionen. Tools wie Webpack können diesen Code automatisch im Produktions-Build entfernen.
Code in Module aufteilen
Nachdem der Code optimiert wurde, kann die Aufteilung in Module helfen, die Menge des anfänglich geladenen Codes zu reduzieren.
Angenommen, 20 % des Codes sind für Funktionen, die erst nach einigen Klicks benötigt werden. Das Parsen dieses Codes ist unnötig, bevor überhaupt der Ladebildschirm angezeigt wird. Die Code-Aufteilung verkürzt die „Time to Interactive“ erheblich.
Anstelle eines komplexen Abhängigkeitsdiagramms für alle Javascript-Dateien, identifizieren Sie Module, die isoliert werden können. Beispielsweise kann eine Komponente, die umfangreiche Bibliotheken lädt, in eine separate Datei verschoben und nur bei Bedarf geladen werden.
Verschiedene Bibliotheken können das „Lazy Loading“ unterstützen. Übertreiben Sie es jedoch nicht, da dies zu Verzögerungen bei späteren Interaktionen führen kann. Identifizieren Sie die größten Code-Blöcke und teilen Sie sie sinnvoll auf.
Serverseitiges Rendering
Da das Parsen und Kompilieren im Browser zeitaufwändig ist, kann der Server einen Teil dieser Last übernehmen. Anstatt eine leere Seite zu senden, die erst durch Javascript gefüllt wird (wie bei Single-Page-Apps), kann eine Javascript-Engine auf dem Server (z.B. Node.js) so viele Daten und Inhalte wie möglich vorab erstellen.
Die Server sind in der Regel schneller als die Browser der Nutzer. Auch hier wird noch Javascript benötigt, um die App interaktiv zu machen. Das serverseitige Rendering liefert jedoch einen Teil der Inhalte, sodass der Benutzer mindestens einen Ladebildschirm oder Fortschrittsbalken sieht, wenn die Seite geladen wird.
Zusätzliche Daten für die anfängliche Ansicht werden auch direkt an den Client geliefert, wodurch separate Abfragen vermieden werden.
Assets optimieren
Assets (Bilder, Icons etc.) tragen wesentlich zum Erscheinungsbild einer Webseite bei. Die Seite fühlt sich erst dann komplett geladen an, wenn auch die Assets geladen wurden. Sie können jedoch zu Layoutverschiebungen führen und die Ladezeit erheblich verlängern. Oftmals ist ein Asset das Element, welches für das „Largest Contentful Paint“ verantwortlich ist.
Assets sind häufig auch die „schwersten“ Elemente einer App. Ein Bild kann mehrere Megabyte groß sein und das Laden vieler Icons kann das Limit für gleichzeitige Netzwerkanfragen überschreiten.
Vermeiden Sie das direkte Einbinden unoptimierter Bilder. Skalieren Sie Bilder auf die benötigten Dimensionen. Ein Profilbild in einem 50×50 Pixel Element sollte nicht in der Größe eines Desktop-Hintergrunds geladen und verkleinert werden.
Bilder können durch das Format komprimiert werden. Webp ist das aktuelle Format der Wahl, wobei die Kompressionstechniken stetig verbessert werden. Da nicht alle Browser neueste Formate unterstützen, verwenden Sie Image- und Video-Elemente mit Fallback-Formaten.
Fazit
Diese fünf Techniken sind einige der wichtigsten Methoden, um eine schnelle Ladezeit zu gewährleisten. Schnellere Ladezeiten verbessern die Conversion-Rate, die Nutzerzufriedenheit und das Suchmaschinen-Ranking, da SEO die Ladezeiten positiv bewertet. Bei Terrastruktur setzen wir diese und weitere Methoden ein, damit unsere Benutzer Diagramme so schnell wie möglich erstellen und anzeigen können.