Die schnellste und am besten optimierte Ressource ist eine Ressource, die nicht gesendet wird. Sie sollten unnötige Ressourcen aus Ihrer Anwendung entfernen. Es ist eine gute Praxis, die impliziten und expliziten Annahmen mit Ihrem Team zu hinterfragen und regelmäßig zu überprüfen. Hier einige Beispiele:
- Sie haben die Ressource X schon immer auf Ihren Seiten eingebunden. Aber wiegen die Kosten für das Herunterladen und Anzeigen den Wert auf, den sie dem Nutzer bietet? Können Sie den Wert messen und nachweisen?
- Liefert die Ressource (insbesondere wenn es sich um eine Drittanbieterressource handelt) eine konsistente Leistung? Befindet sich diese Ressource auf dem kritischen Pfad oder muss sie sich dort befinden? Wenn sich die Ressource im kritischen Pfad befindet, könnte sie ein Single Point of Failure für die Website sein? Das heißt, wenn die Ressource nicht verfügbar ist, wirkt sich das auf die Leistung und die Nutzerfreundlichkeit Ihrer Seiten aus?
- Benötigt diese Ressource ein SLA oder hat sie bereits eines? Entspricht diese Ressource den Best Practices für die Leistung: Komprimierung, Caching usw.?
Zu oft enthalten Seiten unnötige Ressourcen oder, noch schlimmer, Ressourcen, die die Seitenleistung beeinträchtigen, ohne dem Besucher oder der Website, auf der sie gehostet werden, einen nennenswerten Mehrwert zu bieten. Dies gilt gleichermaßen für eigene und Drittanbieter-Ressourcen und -Widgets:
- Website A hat sich entschieden, auf der Startseite ein Fotokarussell anzuzeigen, damit Besucher mit einem schnellen Klick eine Vorschau mehrerer Fotos sehen können. Alle Fotos werden geladen, wenn die Seite geladen wird, und der Nutzer kann sich die Fotos nacheinander ansehen.
- Frage: Haben Sie gemessen, wie viele Nutzer sich mehrere Fotos im Karussell ansehen? Möglicherweise entsteht ein hoher Overhead, weil Ressourcen heruntergeladen werden, die die meisten Besucher nie sehen.
- Website B hat sich entschieden, ein Widget eines Drittanbieters zu installieren, um ähnliche Inhalte anzuzeigen, die Interaktion in sozialen Medien zu verbessern oder einen anderen Dienst bereitzustellen.
- Frage: Haben Sie erfasst, wie viele Besucher das Widget verwenden oder auf die Inhalte klicken, die das Widget bereitstellt? Rechtfertigt die Interaktion, die dieses Widget generiert, den Aufwand? Außerdem: Ist es für Sie möglich, eine Ladestrategie zu verwenden, um sicherzustellen, dass das Skript erst geladen wird, wenn es benötigt wird?
Um zu entscheiden, ob unnötige Downloads entfernt werden sollen, ist oft sorgfältiges Nachdenken und Messen erforderlich. Die besten Ergebnisse erzielen Sie, wenn Sie diese Fragen regelmäßig für alle Assets auf Ihren Seiten durchgehen.
Auswirkungen auf die Core Web Vitals
Die Core Web Vitals-Initiative wurde von Google eingeführt, um eine Reihe von Messwerten bereitzustellen, die die Nutzererfahrung im Web widerspiegeln. Es gibt viele Optimierungsstrategien für die Core Web Vitals. Wenn Sie sich jedoch fragen, ob eine bestimmte Ressource auf einer Seite geladen werden soll, kann Ihnen das helfen, diese Messwerte auf Ihrer Website zu verbessern. Im Folgenden finden Sie einige Beispiele, die nach den einzelnen Core Web Vitals gruppiert sind und die Sie berücksichtigen sollten. Diese Liste ist zwar nicht vollständig, aber sie kann Ihnen als Denkanstoß dienen.
Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) misst, wann der größte Inhalt (z. B. ein Hero-Image oder eine Überschrift) geladen wird. Er gilt als wichtiger Messwert für die Wahrnehmung, der Nutzern den Eindruck vermittelt, dass eine Website schnell geladen wird.
Wenn weniger Ressourcen heruntergeladen werden, wird die Bandbreite des Nutzers auf weniger Ressourcen verteilt. Das kann zu einer Verbesserung des LCP führen. Ein klassisches Beispiel ist das Lazy Loading, bei dem Bilder, die sich beim Seitenaufbau außerhalb des Darstellungsbereichs befinden, erst dann heruntergeladen werden, wenn der Browser festgestellt hat, dass der Nutzer sie wahrscheinlich sehen wird. Wenn Sie eine große Galerie mit Miniaturansichten haben, z. B. 50 Bilder, bedeutet Lazy Loading aller Bilder bis auf die ersten zehn, dass der Browser die verfügbare Bandbreite effizienter nutzen kann und die ersten Bilder, die der Nutzer sieht, schneller geladen werden.
Es geht jedoch nicht nur darum, weniger Bilder zu laden. Der Browser hat ein internes Priorisierungsschema, das bestimmt, wie viel Bandbreite jede Ressource erhalten soll. Aber selbst dann können alle Ressourcen – insbesondere solche, die mit hoher Priorität heruntergeladen werden – die abhängige Ressource eines potenziellen LCP-Elements beeinträchtigen. Das gilt insbesondere für langsame Netzwerkverbindungen. Diese abhängige Ressource kann eine Bilddatei sein, die das LCP-Element der Seite darstellt. Es kann sich aber auch um eine Web-Schriftartressource handeln, die der Browser benötigt, um einen Textknoten zu rendern, der als LCP-Element der Seite bestimmt werden kann.
Wenn Ihre Website viel Text enthält, kann es sein, dass das LCP-Element einer Seite ein Textknoten ist. Es gibt viele gute Strategien zur Schriftoptimierung und zum Laden von Schriftarten. Sie sollten jedoch überlegen, ob eine Systemschriftart für Ihre Website ausreicht, damit LCP-Elemente, die Textknoten sind, ohne Abhängigkeit von einer Webschriftartressource geladen und fast sofort dargestellt werden können, wenn das CSS und HTML vom Server eintrifft.
Cumulative Layout Shift (CLS)
Jede Ressource, die Sie laden, kann zum Cumulative Layout Shift (CLS) einer Seite beitragen, insbesondere wenn sie zum Zeitpunkt des ersten Renderns noch nicht vollständig heruntergeladen wurde. Bei Bildern können Sie CLS vermeiden, indem Sie explizite Abmessungen festlegen. Bei Schriftarten können Sie das Laden von Schriftarten und möglicherweise die Zuordnung von Fallback-Schriftarten verwalten, um Verschiebungen während des Austauschs einer Webschriftart zu minimieren. Bei JavaScript könnte es darum gehen, wie das Skript das DOM manipuliert, damit Layoutverschiebungen auf ein akzeptables Maß reduziert werden.
Für jede Ressource, die zum CLS einer Seite beiträgt, ist ein gewisser Aufwand erforderlich, um sicherzustellen, dass das Seitenlayout ausreichend stabil ist. Wenn Sie sich fragen, ob Sie eine bestimmte Ressource benötigen, beschleunigen Sie nicht nur den Seitenaufbau, sondern reduzieren auch den kognitiven Aufwand, der erforderlich ist, um die Layoutstabilität zu erhalten. Das führt nicht nur zu einer viel weniger frustrierenden Nutzererfahrung, sondern auch zu einer weniger frustrierenden Entwicklererfahrung, da Sie mehr Zeit haben, andere Ziele in Ihren Projekten zu verfolgen.
Interaction to Next Paint (INP)
Interaction to Next Paint (INP) misst die Reaktionsfähigkeit auf Nutzereingaben während der gesamten Lebensdauer einer Seite. Der INP einer Seite kann stark durch das geladene JavaScript beeinflusst werden, da JavaScript für den Großteil der Interaktivität im Web verantwortlich ist. Insbesondere die Menge der Skriptressourcen, die während des Seitenaufbaus heruntergeladen werden, kann zu potenziell aufwendigen Arbeiten bei der Skriptauswertung und -kompilierung führen. Je weniger JavaScript beim Start geladen wird, desto weniger Arbeit muss der Browser an diesem kritischen Punkt der Nutzerfreundlichkeit von Seiten erledigen, an dem Nutzer möglicherweise versuchen, mit der Seite zu interagieren.
Es gibt zwar Strategien, um die Größe der beim Start heruntergeladenen JavaScript-Ressourcen zu reduzieren, z. B. Codeaufteilung und Tree-Shaking, aber es lohnt sich, die in Ihren Projekten verwendeten Pakete zu prüfen, um festzustellen, ob sie überhaupt erforderlich sind. lodash bietet beispielsweise viele Methoden, die auch heute noch nützlich sind, aber auch Methoden, die der Browser standardmäßig bereitstellt, z. B. Array-spezifische Funktionen für Mapping, Reduzierung und Filterung und viele andere.
Die progressive Verbesserung ist auch ein nützlicher Ansatz für JavaScript, da Sie damit Nutzern eine grundlegende (aber dennoch funktionale) Version bereitstellen können, die Sie für Nutzer mit leistungsstärkeren Geräten und schnelleren Netzwerkverbindungen erweitern können. Unabhängig davon, ob Sie sich an das Prinzip der progressiven Verbesserung halten oder nicht, gilt: Jede JavaScript-Ressource, die Sie nicht herunterladen müssen, kann zu einer schnelleren Reaktion auf Nutzerinteraktionen führen, was ein wichtiger Aspekt der Webleistung ist.
Fazit
Die Überprüfung Ihrer Website auf unnötige Downloads ist nur ein Aspekt, um die Nutzerfreundlichkeit zu verbessern, aber einer, der sich stark auswirken kann. Zusammenfassung:
- Erstellen Sie ein Inventar Ihrer eigenen Assets und der Assets von Drittanbietern auf Ihren Seiten.
- Messen Sie die Leistung jedes Assets: seinen Wert und seine technische Leistung.
- Bestimmen Sie, ob die Ressourcen einen ausreichenden Wert bieten.
- Auswirkungen unnötiger Downloads auf die Core Web Vitals und unterstützende Messwerte verstehen
Wenn Sie die Effizienz von Inhalten auf diese Weise optimieren, verbessern Sie nicht nur die Leistung insgesamt, sondern achten auch darauf, die Bandbreite der Nutzer nicht zu verschwenden. Außerdem können Sie so potenziell nutzerorientierte Messwerte verbessern und eine bessere Nutzererfahrung bieten.