Die schnellste und am besten optimierte Ressource ist eine nicht gesendete Ressource. 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 Ressource X immer auf Ihren Seiten verwendet. Aber überwiegen die Kosten für das Herunterladen und Darstellen den Wert, den sie den Nutzern bietet? Können Sie den Wert messen und nachweisen?
- Bietet die Ressource (insbesondere wenn es sich um eine Drittanbieterressource handelt) eine gleichbleibende Leistung? Befindet sich diese Ressource auf dem kritischen Pfad oder muss sie sich dort befinden? Könnte die Ressource, wenn sie sich auf dem kritischen Pfad befindet, ein Single Point of Failure für die Website sein? Heißt das, dass sich die Leistung und die Nutzerfreundlichkeit Ihrer Seiten verschlechtern, wenn die Ressource nicht verfügbar ist?
- Ist für diese Ressource ein SLA erforderlich oder gibt es ein SLA? Werden bei dieser Ressource die Best Practices für die Leistung befolgt, z. B. Komprimierung und Caching?
Zu oft enthalten Seiten Ressourcen, die unnötig sind oder die die Seitenleistung beeinträchtigen, ohne für den Besucher oder die Website, auf der sie gehostet werden, einen großen Mehrwert zu bieten. Das gilt gleichermaßen für eigene und Drittanbieterressourcen und -widgets:
- Auf Website A wird ein Fotokarussell auf der Startseite angezeigt, damit Besucher mit nur einem Klick eine Vorschau mehrerer Fotos sehen können. Alle Fotos werden beim Laden der Seite geladen und der Nutzer kann sich die Fotos ansehen.
- Frage:Haben Sie gemessen, wie viele Nutzer sich mehrere Fotos im Karussell ansehen? Möglicherweise verursachen Sie einen hohen Overhead, indem Sie Ressourcen herunterladen, die die meisten Besucher nie sehen.
- Website B hat beschlossen, ein Drittanbieter-Widget 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 des Widgets klicken? Ist die Interaktion, die dieses Widget generiert, ausreichend, um den Overhead zu rechtfertigen? Können Sie außerdem eine Ladestrategie verwenden, damit das Script erst geladen wird, wenn es benötigt wird?
Die Entscheidung, ob unnötige Downloads eliminiert werden sollen, erfordert oft sorgfältiges Nachdenken und Messungen. Die besten Ergebnisse erzielen Sie, wenn Sie diese Fragen für jedes Asset auf Ihren Seiten regelmäßig 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 Core Web Vitals. Wenn Sie sich fragen, ob eine bestimmte Ressource auf einer Seite geladen werden soll, können Sie diese Messwerte auf Ihrer Website verbessern. Im Folgenden finden Sie einige Beispiele, die nach den einzelnen Core Web Vitals gruppiert sind und die Sie in Betracht ziehen sollten. Diese Liste ist nicht vollständig (es gibt viele weitere Beispiele), aber sie kann Ihnen Anregungen geben.
Largest Contentful Paint (LCP)
Der Largest Contentful Paint (LCP) gibt an, wann der größte Inhalt (z. B. ein Hero-Image oder eine Überschrift) geladen wird. Er gilt als wichtiger Wahrnehmungsmesswert, der den Nutzern den Eindruck vermittelt, dass eine Website schnell geladen wird.
Wenn weniger Ressourcen heruntergeladen werden, wird die verfügbare Bandbreite des Nutzers in der Regel auf weniger Ressourcen verteilt. Das kann zu einer Verbesserung des LCP führen. Ein klassisches Beispiel ist das Lazy Loading, bei dem Bilder außerhalb des Darstellungsbereichs beim Laden der Seite erst heruntergeladen werden, wenn der Browser festgestellt hat, dass der Nutzer sie mit höherer Wahrscheinlichkeit sehen wird. Wenn Sie eine große Miniaturansichtengalerie mit beispielsweise 50 Bildern haben und alle Bilder außer den zehn obersten per Lazy Loading laden, kann der Browser die verfügbare Bandbreite effizienter nutzen und die ersten Bilder, die der Nutzer sieht, werden schneller geladen.
Es geht jedoch nicht nur darum, weniger Bilder zu laden. Der Browser hat ein internes Priorisierungsschema, das festlegt, wie viel Bandbreite jede Ressource erhalten soll. Aber selbst bei dieser Einstellung können alle Ressourcen – insbesondere diejenigen, die mit hoher Priorität heruntergeladen werden – die abhängige Ressource eines potenziellen LCP-Elements entziehen. Das gilt insbesondere für langsame Netzwerkverbindungen. Diese abhängige Ressource kann eine Bilddatei sein, die das LCP-Element der Seite darstellt, aber auch eine Webschrift-Ressource, die der Browser zum Rendern eines Textknotens benötigt, der als LCP-Element der Seite bestimmt werden kann.
Wenn Ihre Website viel Text enthält, ist das LCP-Element einer Seite möglicherweise ein Textknoten. Es gibt viele gute Schriftoptimierungs- und Ladestrategien. Es kann sich jedoch lohnen, zu überlegen, ob ein Systemschriftschnitt für die Anforderungen Ihrer Website ausreicht, damit LCP-Elemente, die Textknoten sind, ohne Abhängigkeit von einer Webschriftressource geladen und fast sofort dargestellt werden können, sobald das CSS und HTML vom Server ankommt.
Cumulative Layout Shift (CLS)
Jede von Ihnen geladene Ressource kann zum Cumulative Layout Shift (CLS) einer Seite beitragen, insbesondere wenn der Download nicht bis zum Zeitpunkt des ersten Paints abgeschlossen ist. Um bei Bildern ein hohes CLS zu vermeiden, können Sie beispielsweise explizite Abmessungen festlegen. Beim Laden von Schriftarten und beim Abgleich mit einer möglichen Fallback-Schriftart können Abweichungen während des Austauschzeitraums einer Webschrift minimiert werden. Bei JavaScript kann es sich um die Verwaltung der DOM-Manipulation durch das Script handeln, damit Layoutverschiebungen auf ein akzeptables Maß reduziert werden.
Jede Ressource, die zum CLS einer Seite beiträgt, erfordert etwas Arbeit, um sicherzustellen, dass das Seitenlayout ausreichend stabil ist. Wenn Sie sich fragen, ob Sie eine bestimmte Ressource benötigen, beschleunigen Sie nicht nur das Laden der Seite, sondern reduzieren auch den kognitiven Aufwand, der für die Aufrechterhaltung der Layoutstabilität erforderlich ist. 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. Die INP einer Seite kann stark vom geladenen JavaScript beeinflusst werden, da JavaScript die meisten interaktiven Funktionen im Web antreibt. Insbesondere die Menge der Scriptressourcen, die beim Laden der Seite heruntergeladen werden, kann zu potenziell kostspieligen Script-Bewertungs- und ‑kompilierungsarbeiten führen. Je weniger JavaScript Sie beim Starten laden, desto weniger Arbeit muss der Browser an diesem kritischen Punkt der Seitennutzung leisten, an dem Nutzer möglicherweise versuchen, mit der Seite zu interagieren.
Es gibt zwar Strategien zur Reduzierung der Größe von JavaScript-Ressourcen, die beim Start heruntergeladen werden, z. B. Code Splitting und Tree Shaking. Es lohnt sich jedoch, 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. Es werden aber auch Methoden mitgeliefert, die der Browser standardmäßig bietet, z. B. Array-spezifische Funktionen zum Zuordnen, Reduzieren und Filtern sowie viele andere.
Progressive Verbesserung ist auch ein nützlicher Ansatz für JavaScript, da Sie damit Nutzern eine grundlegende (aber dennoch funktionsfähige) Website präsentieren können, die Sie für Nutzer mit leistungsfähigeren Geräten und schnelleren Netzwerkverbindungen ergänzen können. Unabhängig davon, ob Sie dem Prinzip der progressiven Verbesserung folgen oder nicht, bleibt der Grundsatz: Jede JavaScript-Ressource, deren Herunterladen Sie vermeiden können, kann zu einer schnelleren Reaktion auf Nutzerinteraktionen führen, was ein wichtiger Aspekt der Webleistung ist.
Fazit
Die Prüfung Ihrer Website auf unnötige Downloads ist zwar nur ein Aspekt für eine schnelle Nutzererfahrung, aber ein Aspekt mit großem Potenzial. Zusammenfassung:
- Erstellen Sie ein Inventar Ihrer eigenen Assets und der Assets von Drittanbietern auf Ihren Seiten.
- Messen Sie die Leistung der einzelnen Assets: ihren Wert und ihre technische Leistung.
- Prüfen Sie, ob die Ressourcen einen ausreichenden Mehrwert bieten.
- Auswirkungen unnötiger Downloads auf die Core Web Vitals und die zugehörigen Messwerte
Wenn du die Inhaltseffizienz auf diese Weise optimierst, verbesserst du nicht nur die Gesamtleistung, sondern sorgst auch dafür, dass die Bandbreite der Nutzer nicht verschwendet wird. Außerdem kannst du nutzerorientierte Messwerte verbessern und die Nutzerfreundlichkeit erhöhen.