Eine Sammlung der Best Practices, die das Chrome DevRel-Team als die effektivsten Möglichkeiten zur Verbesserung der Core Web Vitals-Leistung im Jahr 2023 betrachtet.
Im Laufe der Jahre haben wir bei Google Webentwicklern zahlreiche Empfehlungen zur Verbesserung der Leistung gegeben.
Obwohl jede dieser Empfehlungen im Einzelnen die Leistung vieler Websites verbessern kann, ist die gesamte Auswahl an Empfehlungen zugegebenermaßen überwältigend und realistischerweise kann weder eine Person noch eine Website allen folgen.
Sofern die Webleistung nicht Ihre Hauptaufgabe ist, ist wahrscheinlich nicht offensichtlich, welche Empfehlungen die größten positiven Auswirkungen auf Ihre Website haben werden. Vielleicht haben Sie beispielsweise gelesen, dass die Implementierung von kritischem CSS die Ladeleistung verbessern kann, und Sie haben vielleicht auch gehört, dass es wichtig ist, Ihre Bilder zu optimieren. Aber wenn du keine Zeit hast, an beiden Dingen zu arbeiten, wie würdest du dich dann entscheiden?
Im Chrome-Team haben wir uns im letzten Jahr mit der folgenden Frage befasst: Was sind die wichtigsten Empfehlungen, die wir Entwicklern geben können, um die Leistung für ihre Nutzer zu verbessern?
Um diese Frage richtig beantworten zu können, müssen wir nicht nur die technischen Vorzüge einer bestimmten Empfehlung berücksichtigen, sondern auch menschliche und organisatorische Faktoren, die die Wahrscheinlichkeit beeinflussen, dass Entwickler diese Empfehlungen tatsächlich umsetzen können. Mit anderen Worten: Einige Empfehlungen können theoretisch eine enorme Wirkung haben, aber in Wirklichkeit haben nur sehr wenige Websites die Zeit oder die Ressourcen, um sie umzusetzen. Ebenso sind einige Empfehlungen von entscheidender Bedeutung, aber bei den meisten Websites werden diese Praktiken bereits umgesetzt.
Kurz gesagt, unsere Liste der besten Empfehlungen zur Leistung im Web sollte den Schwerpunkt auf Folgendes legen:
- Empfehlungen, von denen wir glauben, dass sie die größten Auswirkungen auf die reale Welt haben
- Empfehlungen, die für die meisten Websites relevant und anwendbar sind
- Empfehlungen, die für die meisten Entwickler realistisch umgesetzt werden können
Im vergangenen Jahr haben wir viel Zeit damit verbracht, alle von uns abgegebenen Leistungsempfehlungen zu überprüfen und jede davon (sowohl qualitativ als auch quantitativ) anhand der drei oben genannten Kriterien zu bewerten.
In diesem Beitrag stellen wir unsere wichtigsten Empfehlungen zur Verbesserung der Leistung für jeden der Core Web Vitals-Messwerte vor. Wenn Sie noch keine Erfahrung mit der Leistung im Web haben oder sich überlegen, wie Sie Ihr Budget optimal nutzen können, sind diese Empfehlungen der beste Ausgangspunkt.
Largest Contentful Paint (LCP)
Unsere ersten Empfehlungen beziehen sich auf den Largest Contentful Paint (LCP), mit dem die Ladeleistung gemessen wird. Von den drei Core Web Vitals-Messwerten ist der LCP derjenige, mit dem die meisten Websites zu kämpfen haben – nur etwa die Hälfte aller Websites erfüllt derzeit den empfohlenen Grenzwert. Fangen wir also damit an.
Achten Sie darauf, dass die LCP-Ressource in der HTML-Quelle sichtbar ist
Laut dem Web Almanac von 2022 vom HTTP-Archiv haben 72% der mobilen Seiten ein Bild als LCP-Element. Das bedeutet, dass die meisten Websites den LCP nur dann optimieren können, wenn sie schnell geladen werden können.
Für viele Entwickler ist es vielleicht nicht offensichtlich, dass die zum Laden eines Bildes benötigte Zeit nur ein Teil der Herausforderung ist. Ein weiterer wichtiger Teil ist die Zeit, bevor ein Bild geladen wird. Die Daten aus dem HTTP-Archiv deuten darauf hin, dass viele Websites tatsächlich dort sprengen.
Tatsächlich hatten 39% der Seiten, auf denen das LCP-Element ein Bild war, Quell-URLs, die in der HTML-Dokumentquelle nicht auffindbar waren. Mit anderen Worten: Diese URLs wurden nicht in Standard-HTML-Attributen wie <img src="..."> oder <link rel="preload" href="..."> gefunden, sodass der Browser sie schnell erkennen und sofort laden kann.
Wenn eine Seite warten muss, bis CSS- oder JavaScript-Dateien vollständig heruntergeladen, geparst und verarbeitet wurden, bevor das Bild überhaupt geladen werden kann, ist es möglicherweise bereits zu spät.
Allgemein gilt: Wenn Ihr LCP-Element ein Bild ist, sollte die URL des Bildes immer in der HTML-Quelle sichtbar sein. Hier einige Tipps, um dies zu ermöglichen:
Lade das Bild mithilfe eines
<img>-Elements mit dem Attributsrcodersrcset. Verwende keine nicht standardmäßigen Attribute wiedata-src, für die zum Rendern JavaScript erforderlich ist, da dies immer langsamer ist. 9% der Seiten verdecken ihr LCP-Bild hinterdata-src.Bevorzugen Sie serverseitiges Rendering (SSR) gegenüber clientseitigem Rendering (CSR), da SSR impliziert, dass das gesamte Seiten-Markup (einschließlich des Bilds) in der HTML-Quelle vorhanden ist. Für CSR-Lösungen muss JavaScript ausgeführt werden, bevor das Image erkannt werden kann.
Wenn von einer externen CSS- oder JS-Datei auf das Bild verwiesen werden muss, können Sie es über ein
<link rel="preload">-Tag in die HTML-Quelle einbinden. Beachten Sie, dass Bilder, auf die in Inline-Stilen verwiesen wird, vom Vorabladen-Scanner des Browsers nicht erkannt werden. Auch wenn sie in der HTML-Quelle zu finden sind, kann die Erkennung dieser Bilder beim Laden anderer Ressourcen dennoch blockiert sein. In diesen Fällen kann das Vorabladen hilfreich sein.
Damit Sie besser erkennen können, ob Ihr LCP-Image Probleme mit der Sichtbarkeit hat, veröffentlicht Lighthouse in Version 10.0 eine neue Prüfung (erwartet Januar 2023).
Wenn die LCP-Ressource von der HTML-Quelle aus gefunden werden kann, kann dies zu messbaren Verbesserungen führen. Außerdem eröffnen sich dadurch zusätzliche Möglichkeiten zur Priorisierung der Ressource. Das ist unsere nächste Empfehlung.
Achten Sie darauf, dass die LCP-Ressource priorisiert ist
Sicherzustellen, dass die LCP-Ressource aus der HTML-Quelle erkannt werden kann, ist ein wichtiger erster Schritt, damit die LCP-Ressource frühzeitig geladen werden kann. Ein weiterer wichtiger Schritt besteht jedoch darin, sicherzustellen, dass das Laden dieser Ressource priorisiert ist und nicht hinter einer Reihe anderer, weniger wichtiger Ressourcen in die Warteschlange gestellt wird.
Auch wenn das LCP-Bild mit einem Standard-<img>-Tag in der HTML-Quelle vorhanden ist und die Seite <head> im Dokument vor diesem <img>-Tag ein Dutzend <script>-Tags enthält, kann es eine Weile dauern, bis die Bildressource geladen wird.
Die einfachste Methode zur Lösung dieses Problems besteht darin, dem Browser einen Hinweis darauf zu geben, welche Ressourcen die höchste Priorität haben. Dazu legen Sie das neue Attribut fetchpriority="high" im <img>- oder <link>-Tag fest, über das Ihr LCP-Image geladen wird. Dadurch wird der Browser angewiesen, die Datei früher zu laden, anstatt auf den Abschluss dieser Skripts zu warten.
Laut Web Almanac nutzen nur 0, 03% der infrage kommenden Seiten diese neue API.Für die meisten Websites im Web gibt es also viele Möglichkeiten, den LCP mit sehr geringem Aufwand zu verbessern. Obwohl das Attribut fetchpriority derzeit nur in Chromium-basierten Browsern unterstützt wird, handelt es sich bei dieser API um eine progressive Verbesserung, die von anderen Browsern einfach ignoriert wird. Wir empfehlen Entwicklern daher dringend, sie jetzt zu verwenden.
Bei anderen Browsern als Chromium können Sie nur sicherstellen, dass die LCP-Ressource Vorrang vor anderen Ressourcen hat, indem Sie weiter oben im Dokument darauf verweisen. Nehmen wir noch einmal das Beispiel einer Website mit vielen <script>-Tags in <head> des Dokuments. Wenn Sie sicherstellen möchten, dass Ihre LCP-Ressource vor diesen Skriptressourcen priorisiert wird, können Sie vor jedem dieser Skripts ein <link rel="preload">-Tag einfügen oder diese Skripts später in <body> unter <img> verschieben. Das funktioniert zwar, ist aber weniger ergonomisch als die Verwendung von fetchpriority. Wir hoffen, dass bald auch andere Browser dies unterstützen.
Ein weiterer wichtiger Aspekt bei der Priorisierung der LCP-Ressource besteht darin, dass Sie nichts unternehmen, was zu einer niedrigeren Priorisierung führt, z. B. das Hinzufügen des Attributs loading="lazy". Mittlerweile legen 10% der Seiten auf ihrem LCP-Bild loading="lazy" fest. Hüten Sie sich vor Lösungen zur Bildoptimierung, bei denen Lazy Loading wahllos auf alle Bilder angewendet wird. Wenn sie eine Möglichkeit bieten, dieses Verhalten zu überschreiben, sollten Sie sie für das LCP-Image verwenden. Wenn Sie nicht sicher sind, welches Bild der LCP sein wird, versuchen Sie, mithilfe von Heuristiken einen geeigneten Kandidaten auszuwählen.
Das Zurückstellen nicht kritischer Ressourcen ist eine weitere Möglichkeit, die relative Priorität der LCP-Ressource effektiv zu erhöhen. Beispielsweise können Skripts, die die Benutzeroberfläche nicht unterstützen (z. B. Analyseskripts oder soziale Widgets), bedenkenlos auf das Auslösen des load-Ereignisses verschoben werden. Dadurch wird sichergestellt, dass sie nicht mit anderen kritischen Ressourcen wie der LCP-Ressource um die Netzwerkbandbreite konkurrieren.
Zusammenfassend lässt sich sagen, dass Sie die folgenden Best Practices befolgen sollten, um sicherzustellen, dass die LCP-Ressource frühzeitig und mit hoher Priorität geladen wird:
- Füge
fetchpriority="high"dem<img>-Tag deines LCP-Images hinzu. Wenn die LCP-Ressource über ein<link rel="preload">-Tag geladen wird, können Sie auchfetchpriority="high"dafür festlegen. - Legen Sie
loading="lazy"niemals im<img>-Tag Ihres LCP-Bilds fest. Dadurch wird die Priorisierung Ihres Bildes herabgestuft und der Ladevorgang verzögert sich. - Stellen Sie nicht kritische Ressourcen nach Möglichkeit auf später zurück. Sie können sie entweder an das Ende des Dokuments verschieben, natives Lazy Loading für Bilder oder iFrames verwenden oder sie asynchron über JavaScript laden.
CDN zur Optimierung der TTFB für Dokumente und Ressourcen verwenden
Bei den beiden vorherigen Empfehlungen ging es darum, dass Ihre LCP-Ressource frühzeitig erkannt und priorisiert wird, damit sie sofort geladen werden kann. Der letzte Teil dieses Puzzles besteht darin, sicherzustellen, dass auch die erste Dokumentantwort so schnell wie möglich eintrifft.
Der Browser kann erst dann mit dem Laden von Unterressourcen beginnen, wenn er das erste Byte der ursprünglichen HTML-Dokumentantwort erhält. Je früher dieser Vorgang eintritt, desto früher kann auch alles andere passieren.
Diese Zeit wird als Time to First Byte (TTFB) bezeichnet. Die beste Möglichkeit zum Reduzieren der TTFB ist:
- Stellen Sie Ihre Inhalte so nahe wie möglich an den Nutzern bereit.
- Speichern Sie diese Inhalte im Cache, damit kürzlich angeforderte Inhalte schnell wieder bereitgestellt werden können.
Die beste Möglichkeit für diese beiden Dinge ist die Verwendung eines CDN. CDNs verteilen Ihre Ressourcen auf Edge-Server, die auf der ganzen Welt verteilt sind. Dadurch wird die Entfernung begrenzt, die diese Ressourcen über die Kabel zu Ihren Nutzern zurücklegen müssen. CDNs haben in der Regel auch detailgenaue Caching-Steuerelemente, die an die Anforderungen Ihrer Website angepasst und optimiert werden können.
Viele Entwickler sind mit der Verwendung eines CDN zum Hosten statischer Assets vertraut, aber CDNs können auch HTML-Dokumente bereitstellen und im Cache speichern, selbst wenn sie dynamisch generiert wurden.
Laut Web Almanac wurden nur 29% der Anfragen für HTML-Dokumente über ein CDN bereitgestellt. Websites haben also die Möglichkeit, zusätzliche Einsparungen zu erzielen.
Hier einige Tipps zum Konfigurieren Ihrer CDNs:
- Überlegen Sie, wie lange Inhalte im Cache gespeichert werden. Ist es z. B. wirklich wichtig, dass Inhalte immer aktuell sind? Oder sind sie ein paar Minuten veraltet?).
- Sie können Inhalte sogar unbegrenzt im Cache speichern und den Cache dann leeren, wenn Sie eine Aktualisierung vornehmen.
- Prüfen Sie, ob Sie die derzeit auf Ihrem Ursprungsserver ausgeführte dynamische Logik in den Edge (eine Funktion der meisten modernen CDNs) verschieben können.
Im Allgemeinen ist es ein Vorteil, wenn Sie Inhalte direkt vom Edge-Server bereitstellen können und so eine Reise zu Ihrem Ursprungsserver vermeiden. Und selbst in Fällen, in denen Sie den gesamten Weg zurück zu Ihrem Ursprungsserver müssen, sind CDNs in der Regel dafür optimiert, dies viel schneller zu erledigen. Es ist also in jedem Fall ein Gewinn.
Cumulative Layout Shift (CLS)
Die nächsten Empfehlungen beziehen sich auf den Cumulative Layout Shift (CLS), mit dem die visuelle Stabilität auf Webseiten gemessen wird. Obwohl sich CLS seit 2020 erheblich verbessert hat, erfüllen etwa ein Viertel der Websites immer noch nicht den empfohlenen Grenzwert. Für viele Websites besteht also weiterhin eine große Chance, die Nutzerfreundlichkeit zu verbessern.
Explizite Größen für alle von der Seite geladenen Inhalte festlegen
Layout Shifts treten normalerweise auf, wenn vorhandene Inhalte verschoben werden, nachdem andere Inhalte geladen wurden. Deshalb sollten Sie den erforderlichen Speicherplatz möglichst im Voraus reservieren.
Die einfachste Methode zum Beheben von Layoutverschiebungen, die durch nicht optimierte Bilder verursacht werden, besteht darin, explizit die Attribute width und height (oder entsprechende CSS-Attribute) festzulegen. Laut dem HTTP-Archiv weisen 72% der Seiten jedoch mindestens ein nicht skaliertes Bild auf. Ohne explizite Größe legen Browser anfangs eine Standardhöhe von 0px fest. Dies kann zu einer spürbaren Layoutverschiebung führen, wenn das Bild schließlich geladen und die Abmessungen ermittelt wurden. Dies stellt eine große Chance für das Web dar und erfordert wesentlich weniger Aufwand als einige der anderen Empfehlungen, die in diesem Artikel vorgeschlagen werden.
Beachten Sie auch, dass Bilder nicht die einzigen Mitwirkenden für CLS sind. Layout Shifts können durch andere Inhalte verursacht werden, die normalerweise geladen werden, nachdem die Seite ursprünglich gerendert wurde, z. B. Anzeigen von Drittanbietern oder eingebettete Videos. Die Eigenschaft aspect-ratio kann dabei helfen. Es ist eine relativ neue CSS-Funktion, mit der Entwickler explizit ein Seitenverhältnis für Bilder und Nicht-Bildelemente angeben können. So können Sie ein dynamisches width (zum Beispiel basierend auf der Bildschirmgröße) festlegen und der Browser die entsprechende Höhe automatisch berechnen lassen, ähnlich wie bei Bildern mit Abmessungen.
Manchmal ist es nicht möglich, die genaue Größe des dynamischen Inhalts zu bestimmen, da er von Natur aus dynamisch ist. Auch wenn Sie die genaue Größe nicht kennen, können Sie Maßnahmen ergreifen, um den Schweregrad von Layout Shifts zu reduzieren. Eine sinnvolle min-height festzulegen ist fast immer besser, als dem Browser die Standardhöhe von 0px für ein leeres Element zu verwenden. Die Verwendung eines min-height ist in der Regel auch eine einfache Lösung, da der Container bei Bedarf noch auf die endgültige Inhaltshöhe anwachsen kann. Es hat lediglich dieses Wachstum von der vollen Menge auf ein hoffentlich erträglicheres Niveau reduziert.
Sicherstellen, dass die Seiten für den bfcache infrage kommen
Browser verwenden einen Navigationsmechanismus, den Back-Forward-Cache – oder kurz bfcache –, um eine Seite aus einem früheren oder späteren Verlauf des Browserverlaufs direkt aus einem Arbeitsspeicher-Snapshot zu laden.
Der bfcache stellt eine signifikante Leistungsoptimierung auf Browserebene dar und eliminiert vollständig die Layoutverschiebungen während des Seitenaufbaus, die bei vielen Websites den größten Teil der CLS verursachen. Die Einführung des bfcache führte 2022 zu der größten Verbesserung bei den CLS.
Trotzdem kommt eine beträchtliche Anzahl von Websites nicht für den bfcache infrage und lässt sich die kostenlose Webleistung für eine beträchtliche Anzahl von Aufrufen entgehen. Wenn Ihre Seite keine vertraulichen Informationen lädt, die nicht aus dem Arbeitsspeicher wiederhergestellt werden sollen, sollten Sie prüfen, ob Ihre Seiten die Anforderungen erfüllen.
Websiteinhaber sollten prüfen, ob ihre Seiten für den bfcache verwendet werden können, und herausfinden, warum das nicht der Fall ist. Für Chrome gibt es bereits einen bfcache-Tester in den Entwicklertools. Dieses Jahr möchten wir die Tools durch eine neue Lighthouse-Prüfung mit einem ähnlichen Test und eine API zur Messung vor Ort ergänzen.
Wir haben den bfcache zwar in den CLS-Abschnitt aufgenommen, aber da wir dort bisher die größten Verbesserungen verzeichneten, wird er im Allgemeinen auch andere Core Web Vitals verbessern. Sie ist eine von mehreren sofortigen Navigationen, die zur drastischen Verbesserung der Seitennavigation eingesetzt werden können.
Animationen/Übergänge vermeiden, bei denen Layout-induzierende CSS-Eigenschaften verwendet werden
Eine weitere häufige Ursache von Layout Shifts ist die Animation von Elementen. Cookie-Banner oder andere Benachrichtigungsbanner, die von oben oder unten eingeschoben werden, tragen häufig zum CLS bei. Dies ist besonders problematisch, wenn diese Banner andere Inhalte aus dem Weg räumen, aber selbst wenn dies nicht der Fall ist, kann eine Animation dennoch den CLS beeinträchtigen.
Zwar können die Daten aus dem HTTP-Archiv Animationen nicht eindeutig mit Layout Shifts verbinden, doch zeigen die Daten, dass Seiten, auf denen CSS-Eigenschaften animieren, die das Layout könnten, mit einer um 15% geringeren Wahrscheinlichkeit als „gut“ eingestuft werden. CLS als die Seiten insgesamt. Einige Attribute haben einen schlechteren CLS als andere. Beispielsweise haben Seiten, die die Breite margin oder border animieren, „schlecht“. CLS ist fast doppelt so hoch wie Seiten insgesamt als schlecht bewertet.
Das ist wahrscheinlich nicht überraschend, da jedes Mal, wenn Sie eine beliebige layoutverursachende CSS-Eigenschaft verschieben oder animieren, Layoutverschiebungen auftreten. Wenn diese Layoutverschiebungen nicht innerhalb von 500 Millisekunden nach einer Nutzerinteraktion erfolgen, wirken sie sich auf den CLS aus.
Für manche Entwickler überrascht es möglicherweise, dass dies auch dann der Fall ist, wenn das Element außerhalb des normalen Dokumentflusses aufgenommen wird. Zum Beispiel verursachen absolut positionierte Elemente, die top oder left animieren, Layoutverschiebungen, auch wenn sie nicht andere Inhalte verschieben. Wenn Sie jedoch transform:translateX() oder transform:translateY() animieren, statt top oder left zu animieren, wird das Seitenlayout nicht aktualisiert und es werden auch keine Layoutverschiebungen entstehen.
Es gilt schon lange als Best Practice für die Leistung, die Animation von CSS-Eigenschaften zu bevorzugen, die im zusammengesetzten Thread des Browsers aktualisiert werden können, da diese auf die GPU und aus dem Hauptthread verschoben werden. Es ist nicht nur eine allgemeine Best Practice, sondern kann auch zur Verbesserung der CLS beitragen.
Generell gilt: Animieren oder ändern Sie keine CSS-Eigenschaften, für die der Browser das Seitenlayout aktualisieren muss, es sei denn, Sie führen dies durch Tippen oder Drücken des Nutzers aus (aber nicht hover). Außerdem sollten Übergänge und Animationen nach Möglichkeit mit der CSS-Eigenschaft transform bevorzugt werden.
Bei der Lighthouse-Prüfung Nicht zusammengesetzte Animationen vermeiden wird eine Warnung ausgegeben, wenn eine Seite potenziell langsame CSS-Eigenschaften animiert.
First Input Delay (FID)
<ph type="x-smartling-placeholder">Unsere letzten Empfehlungen beziehen sich auf First Input Delay (FID). Mit diesem Messwert wird die Reaktionsfähigkeit einer Seite auf Nutzerinteraktionen gemessen. Obwohl die meisten Websites im Internet derzeit in Bezug auf FID sehr gute Bewertungen erzielen, haben wir in der Vergangenheit Mängel beim FID-Messwert dokumentiert und wir glauben, dass es noch viele Möglichkeiten gibt, die Reaktionsfähigkeit von Websites insgesamt zu verbessern.
Unser neuer Messwert Interaction to Next Paint (INP) ist ein möglicher Nachfolger von FID und alle Empfehlungen unten gelten gleichermaßen für FID und INP. Da Websites insbesondere auf Mobilgeräten bei INP eine schlechtere Leistung erzielen als mit FID, empfehlen wir Entwicklern, diese Empfehlungen zur Reaktionsschnelligkeit ernst zu nehmen, auch wenn sie „gut“ sind. FID.
Lange Aufgaben vermeiden oder aufteilen
Aufgaben sind jede eigenständige Arbeit, die der Browser ausführt. Zu den Aufgaben gehören das Rendern, Layout, Parsen, Kompilieren und Ausführen von Skripts. Wenn Aufgaben zu langen Aufgaben werden, die mindestens 50 Millisekunden lang sind, verhindern sie, dass der Hauptthread schnell auf Nutzereingaben reagieren kann.
Laut Web Almanac gibt es viele Belege, die darauf hinweisen, dass Entwickler mehr tun könnten, um lange Aufgaben zu vermeiden oder aufzubrechen. Das Aufteilen langer Aufgaben ist zwar nicht so einfach wie die anderen Empfehlungen in diesem Artikel, ist aber weniger aufwendig als andere Methoden, die in diesem Artikel nicht beschrieben werden.
Auch wenn Sie immer versuchen sollten, so wenig Arbeit wie möglich in JavaScript zu leisten, können Sie dem Hauptthread ziemlich helfen, indem Sie lange Aufgaben in kleinere Aufgaben aufteilen. Das erreichen Sie, indem Sie häufig zum Hauptthread wechseln, sodass Aktualisierungen des Renderings und andere Nutzerinteraktionen schneller erfolgen können.
Eine weitere Möglichkeit ist die Verwendung von APIs wie isInputPending und der Scheduler API. isInputPending ist eine Funktion, die einen booleschen Wert zurückgibt, der angibt, ob eine Nutzereingabe ausstehend ist. Wenn true zurückgegeben wird, können Sie dem Hauptthread nachgeben, damit er die ausstehende Nutzereingabe verarbeiten kann.
Die Scheduler API ist ein komplexerer Ansatz, mit dem Sie Arbeiten basierend auf einem Prioritätensystem planen können, das berücksichtigt, ob die auszuführende Arbeit für den Nutzer sichtbar ist oder im Hintergrund ausgeführt wird.
Durch das Aufteilen langer Aufgaben gibst du dem Browser mehr Möglichkeiten, sich auf wichtige Aufgaben vorzubereiten, die für den Nutzer sichtbar sind, z. B. den Umgang mit Interaktionen und die daraus resultierenden Rendering-Aktualisierungen.
Unnötiges JavaScript vermeiden
Zweifellos versenden Websites mehr JavaScript als je zuvor, und dieser Trend sollte sich in naher Zukunft nicht ändern. Wenn Sie zu viel JavaScript senden, schaffen Sie eine Umgebung, in der Aufgaben um die Aufmerksamkeit des Hauptthreads konkurrieren. Dies kann sich definitiv auf die Reaktionsfähigkeit Ihrer Website auswirken, insbesondere während dieser entscheidenden Startphase.
Dies ist jedoch kein unlösbares Problem. Sie haben folgende Möglichkeiten:
- Mit dem Abdeckungstool in den Chrome-Entwicklertools können Sie nicht verwendeten Code in den Ressourcen Ihrer Website finden. Indem Sie die Größe der Ressourcen reduzieren, die Sie beim Start benötigen, können Sie dafür sorgen, dass Ihre Website weniger Zeit für das Parsen und Kompilieren von Code aufwendet, was zu einer reibungsloseren anfänglichen User Experience führt.
- Manchmal wird der nicht verwendete Code, den Sie mit dem Abdeckungstool finden, als „nicht verwendet“ gekennzeichnet. da sie nicht beim Start ausgeführt wurde, aber für einige Funktionen in Zukunft erforderlich ist. Dabei handelt es sich um Code, den Sie per Codeaufteilung in ein separates Bundle verschieben können.
- Wenn Sie einen Tag-Manager verwenden, sollten Sie regelmäßig prüfen, ob Ihre Tags optimiert sind oder ob sie noch verwendet werden. Ältere Tags mit nicht verwendetem Code können gelöscht werden, um das JavaScript in Ihrem Tag Manager zu verkleinern und effizienter zu machen.
Umfangreiche Rendering-Aktualisierungen vermeiden
JavaScript ist nicht der Einzige, der die Reaktionszeit Ihrer Website beeinträchtigen kann. Rendering kann für sich genommen eine Art kostspieliger Arbeit sein. Große Rendering-Aktualisierungen können die Reaktionsfähigkeit Ihrer Website auf Nutzereingaben beeinträchtigen.
Die Optimierung der Rendering-Arbeit ist kein direkter Prozess und hängt oft davon ab, was Sie erreichen möchten. Dennoch gibt es einige Dinge, die Sie tun können, um sicherzustellen, dass Ihre Rendering-Updates angemessen sind und sich nicht in lange Aufgaben überfrachten:
- Verwenden Sie
requestAnimationFrame()nicht für nicht-visuelle Arbeiten.requestAnimationFrame()-Aufrufe werden während der Renderingphase der Ereignisschleife verarbeitet. Wenn in diesem Schritt zu viel Arbeit erledigt wird, können sich die Rendering-Aktualisierungen verzögern. Sämtliche Arbeiten mitrequestAnimationFrame()dürfen nur für Aufgaben ausgeführt werden, die das Rendern von Aktualisierungen beinhalten. - Halten Sie die DOM-Größe klein. Die DOM-Größe und die Intensität der Layoutarbeit hängen zusammen. Wenn der Renderer das Layout für ein sehr großes DOM aktualisieren muss, kann der für die Neuberechnung des Layouts erforderliche Arbeitsaufwand erheblich ansteigen.
- Verwenden Sie CSS-Begrenzungen. Die CSS-Eindämmung basiert auf der CSS-Eigenschaft
contain, die dem Browser Anweisungen dazu gibt, wie er die Layout-Arbeit des Containers ausführen soll, in dem diecontain-Eigenschaft festgelegt ist. Dazu gehört auch, den Layoutbereich und das Rendering auf einen bestimmten Stamm im DOM zu beschränken. Dieser Prozess ist nicht immer einfach, aber durch das Isolieren von Bereichen mit komplexen Layouts können Sie es vermeiden, für sie nicht notwendige Layout- und Rendering-Arbeiten durchzuführen.
Fazit
Die Verbesserung der Seitenleistung kann eine gewaltige Aufgabe erscheinen, vor allem angesichts der Menge an Informationen, die im Web zu berücksichtigen sind. Wenn Sie sich jedoch auf diese Empfehlungen konzentrieren, können Sie das Problem fokussiert und zielgerichtet angehen und hoffentlich die Core Web Vitals Ihrer Website verbessern.
Die hier aufgeführten Empfehlungen sind zwar keineswegs vollständig, aber wir sind der Meinung, dass diese Empfehlungen – basierend auf einer sorgfältigen Analyse des Webstatus – die effektivsten Möglichkeiten sind, mit denen Websites ihre Core Web Vitals-Leistung im Jahr 2023 verbessern können.
Falls Sie über die hier aufgeführten Empfehlungen hinausgehen möchten, können Sie diese Optimierungsleitfäden lesen. Dort finden Sie weitere Informationen:
Auf ein neues Jahr und auf ein schnelleres Web für alle! Mögen Sie eine schnelle Website für Ihre Nutzer erreichen, wenn es am wichtigsten ist.
Foto von Devin Avery