Die schnellste und am besten optimierte Ressource ist eine Ressource, die nicht gesendet wird. Sie sollten unnötige Ressourcen aus Ihrer Anwendung entfernen. Es empfiehlt sich, die impliziten und expliziten Annahmen Ihrem Team in Frage zu stellen und regelmäßig zu überprüfen. Hier einige Beispiele:
- Sie haben die Ressource X schon immer auf Ihren Seiten eingefügt, aber stellen die Kosten für das Herunterladen und Anzeigen der Ressource für den Nutzer einen Gegenwert dar? Können Sie dessen Wert messen und nachweisen?
- Erbringt die Ressource (insbesondere, wenn es sich um die Ressource eines Drittanbieters handelt) eine konstante Leistung? Befindet sich diese Ressource im kritischen Pfad oder muss sie enthalten sein? 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 sie sich auf die Leistung und die Nutzererfahrung Ihrer Seiten aus?
- Verfügt diese Ressource über ein SLA? Entspricht diese Ressource den Best Practices für die Leistung: Komprimierung, Caching usw.?
Häufig enthalten Seiten Ressourcen, die unnötig sind oder sogar die Leistung beeinträchtigen, ohne dass der Besucher oder die Website, auf der sie gehostet werden, einen großen Mehrwert bietet. Dies gilt gleichermaßen für eigene und Drittanbieter-Ressourcen und -Widgets:
- Website A hat beschlossen, auf der Startseite ein Fotokarussell anzuzeigen, damit der Besucher mit einem kurzen Klick mehrere Fotos in der Vorschau anzeigen kann. Alle Fotos werden geladen, wenn die Seite geladen wird und der Nutzer durch die Fotos navigiert.
- Frage:Haben Sie gemessen, wie viele Nutzer sich mehrere Fotos im Karussell ansehen? Möglicherweise verursachen Sie hohe Kosten, wenn Sie Ressourcen herunterladen, die die meisten Besucher nie aufrufen.
- Auf Website B wird ein Drittanbieter-Widget installiert, um entsprechende Inhalte anzuzeigen, die Interaktion mit sozialen Netzwerken zu verbessern oder einen anderen Dienst anzubieten.
- Frage:Haben Sie erfasst, wie viele Nutzer das Widget verwenden oder auf den Inhalt des Widgets klicken? Ist die Interaktion, die dieses Widget generiert, ausreichend, um den Aufwand zu rechtfertigen? Können Sie außerdem eine Ladestrategie verwenden, damit das Script erst geladen wird, wenn es benötigt wird?
Um herauszufinden, ob unnötige Downloads vermieden werden können, sind oft sorgfältige Überlegungen und Messungen erforderlich. Um optimale Ergebnisse zu erzielen, sollten Sie regelmäßig eine Bestandsaufnahme machen und sich diese Fragen für jedes Asset auf Ihren Seiten noch einmal stellen.
Auswirkungen auf Core Web Vitals
Die Initiative „Core Web Vitals“ wurde von Google eingeführt, um eine Reihe von Messwerten zu erfassen, die Aufschluss darüber geben, wie Nutzer das Web nutzen. Für Core Web Vitals gibt es viele Optimierungsstrategien. Die Frage, ob eine bestimmte Ressource auf einer Seite geladen werden soll, ist jedoch möglicherweise eine gute Idee, um diese Messwerte auf Ihrer Website zu verbessern. Nachfolgend finden Sie einige Beispiele – gruppiert nach den Core Web Vitals –, die es wert sind, in Betracht gezogen zu werden. Das ist zwar keine vollständige Liste mit Beispielen (und es gibt viele!), aber wenn du sie noch einmal durchliest, erhältst du vielleicht Anregungen zum Nachdenken.
Largest Contentful Paint (LCP)
Mit Largest Contentful Paint (LCP) wird gemessen, wann die größten Inhalte geladen werden, z. B. ein Hero-Image oder eine Überschrift. Dies ist ein wichtiger wahrnehmbarer Messwert, der dem Nutzer den Eindruck vermittelt, dass eine Website schnell geladen wird.
Im Allgemeinen bedeutet das Herunterladen von weniger Ressourcen, dass die Bandbreite des Nutzers auf weniger Ressourcen verteilt wird, was zu einer Verbesserung des LCP führen kann. Ein klassisches Beispiel ist das Lazy Loading, bei dem Bilder, die sich während des Seitenaufbaus außerhalb des Darstellungsbereichs befinden, erst heruntergeladen werden, wenn der Browser bestimmt hat, dass sie vom Nutzer mit höherer Wahrscheinlichkeit gesehen werden. Bei einer großen Galerie mit beispielsweise 50 Bildern bedeutet das Lazy Loading von allen bis auf die Top-10, dass der Browser die verfügbare Bandbreite effizienter nutzen kann und die ersten Bilder, die der Nutzer sieht, schneller geladen werden.
Dabei müssen aber nicht unbedingt weniger Bilder geladen werden. Der Browser verfügt über ein internes Priorisierungsschema, das bestimmt, wie viel Bandbreite jede Ressource erhalten soll. Allerdings können alle Ressourcen – insbesondere solche, die mit hoher Priorität heruntergeladen wurden – die abhängige Ressource eines potenziellen LCP-Elements beeinträchtigen. Dies gilt insbesondere bei langsamen Netzwerkverbindungen. Diese abhängige Ressource kann eine Bilddatei sein, die das LCP-Element der Seite darstellt, aber auch eine Webschriftartressource, die der Browser zum Rendern eines Textknotens benötigt, der als LCP-Element der Seite festgelegt werden kann.
Wenn Ihre Website sehr viel Text enthält, ist das LCP-Element einer Seite möglicherweise ein Textknoten. Es gibt zwar viele gute Strategien zum Optimieren und Laden von Schriftarten, es kann sich jedoch lohnen, zu überlegen, ob eine Systemschriftart für die Anforderungen Ihrer Website ausreicht, damit LCP-Elemente, bei denen es sich um Textknoten handelt, ohne Abhängigkeit von einer Webschriftenressource geladen werden und fast sofort zu zeichnen sind, wenn CSS und HTML vom Server eintreffen.
Cumulative Layout Shift (CLS)
Jede geladene Ressource kann zum Cumulative Layout Shift (CLS) einer Seite beitragen, insbesondere wenn der Download zum Zeitpunkt der ursprünglichen Darstellung noch nicht abgeschlossen ist. Vermeiden Sie bei Bildern CLS, z. B. das Festlegen expliziter Abmessungen. Bei Schriftarten können durch die Verwaltung des Ladens von Schriftarten und des möglichen Abgleichs von Fallback-Schriftarten die Verschiebungen während des Auslagerungszeitraums einer Webschriftart minimiert werden. Bei JavaScript könnte es die Verwaltung des DOMs durch dieses Skript steuern, sodass Layoutverschiebungen auf ein akzeptables Maß reduziert werden.
Jede Ressource, die zur CLS einer Seite beiträgt, erfordert einen gewissen Aufwand, um sicherzustellen, dass das Seitenlayout ausreichend stabil ist. Indem Sie hinterfragen, ob Sie eine bestimmte Ressource benötigen oder nicht, beschleunigen Sie nicht nur das Laden von Seiten, sondern verringern auch den kognitiven Aufwand, der für die Stabilität des Layouts erforderlich ist. Dies führt nicht nur zu einer wesentlich weniger frustrierenden User Experience, sondern auch zu einer weniger frustrierenden Entwicklung, da Sie mehr Zeit für andere Ziele in Ihren Projekten haben.
Interaction to Next Paint (INP) und First Input Delay (FID)
Interaction to Next Paint (INP) und First Input Delay (FID) sind Messwerte, die die Reaktionsfähigkeit auf Nutzereingaben messen. Während INP voraussichtlich FID im März 2024 als Core Web Vitals-Wert ersetzen soll, gelten Optimierungsstrategien für FID tendenziell auch für INP. Außerdem ist INP in der Regel schwieriger zu optimieren als FID, da die volle Interaktionslatenz für alle Seiteninteraktionen erfasst wird und nicht nur die Eingabeverzögerung der ersten Interaktion als FID-Messung.
INP und FID werden tendenziell am stärksten von JavaScript beeinflusst, da es den größten Einfluss auf die Interaktivität im Web ist. Sowohl für INP als auch für FID wird durch die Menge der beim Seitenaufbau heruntergeladenen Skriptressourcen möglicherweise kostspielige Arbeit zur Bewertung und Kompilierung des Skripts ausgelöst. Je weniger JavaScript Sie beim Start laden, desto weniger Aufwand hat der Browser an diesem entscheidenden Punkt der Nutzerfreundlichkeit.
Es gibt zwar Strategien zur Reduzierung der Größe von JavaScript-Ressourcen, die beim Start heruntergeladen werden, z. B. Codeaufteilung und Baumschüttelung. Dennoch lohnt es sich, die in Ihren Projekten verwendeten Pakete auf ihre Notwendigkeit zu prüfen. Lodash bietet beispielsweise viele Methoden, die auch heute noch nützlich sind, beinhaltet aber Methoden, die der Browser standardmäßig zur Verfügung stellt, z. B. Array-spezifische Funktionen zum Zuordnen, Reduzieren und Filtern und viele weitere.
Progressive Enhancement ist auch ein nützlicher Ansatz für JavaScript, da Sie damit Nutzern mit leistungsstärkeren Geräten und schnelleren Netzwerkverbindungen eine grundlegende (aber noch funktionsfähige) Erfahrung bieten können. Unabhängig davon, ob Sie das Prinzip der progressiven Verbesserung einhalten oder nicht, gilt Folgendes: Jede JavaScript-Ressource, die Sie vermeiden können, kann zu einer schnelleren Reaktion auf Nutzerinteraktionen führen – ein wichtiger Aspekt der Webleistung.
Fazit
Die Überprüfung Ihrer Website auf unnötige Downloads mag nur einer der Aspekte der Bereitstellung einer schnellen Nutzererfahrung sein, aber sie hat das Potenzial, große Auswirkungen zu haben. Zur Wiederholung:
- Inventarisieren Sie Ihre eigenen Assets und Assets von Drittanbietern auf Ihren Seiten.
- Messen Sie die Leistung jedes Assets, also seinen Wert und seine technische Leistung.
- Prüfen Sie, ob die Ressourcen einen ausreichenden Mehrwert bieten.
- Auswirkungen unnötiger Downloads auf den Core Web Vitals-Wert und unterstützende Messwerte ermitteln
Wenn Sie die Effizienz Ihrer Inhalte auf diese Weise optimieren, steigern Sie nicht nur die Leistung insgesamt, sondern sorgen auch dafür, dass keine Bandbreite für die Nutzer verschwendet wird. Außerdem können Sie die nutzerorientierten Messwerte verbessern und die Nutzerfreundlichkeit verbessern.