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 erachtet.
Im Laufe der Jahre haben wir bei Google viele Empfehlungen an Webentwickler zur Verbesserung der Leistung ausgesprochen.
Jede einzelne dieser Empfehlungen kann die Leistung vieler Websites verbessern. Die gesamten Empfehlungen sind jedoch zugegebenermaßen überwältigend und es gibt keine Möglichkeit, alle einzelnen Personen oder Websites zu befolgen.
Sofern die Leistung im Web nicht Ihre Hauptaufgabe ist, ist es wahrscheinlich nicht offensichtlich, welche Empfehlungen sich am stärksten positiv auf Ihre Website auswirken. Vielleicht haben Sie beispielsweise gelesen, dass die Implementierung von wichtigem CSS die Ladeleistung verbessern kann. Vielleicht haben Sie 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 entscheiden, welches das richtige ist?
Im letzten Jahr hat unser Chrome-Team nach der folgenden Frage gesucht: Was sind die wichtigsten Empfehlungen, die wir Entwicklern geben können, um die Leistung für ihre Nutzer zu verbessern?
Bei der Beantwortung dieser Frage müssen wir nicht nur die technischen Vorteile der einzelnen Empfehlungen berücksichtigen, sondern auch menschliche und organisatorische Faktoren, die die Wahrscheinlichkeit beeinflussen, ob Entwickler diese Empfehlungen tatsächlich umsetzen können. Mit anderen Worten: Einige Empfehlungen können theoretisch enorm wichtig sein, aber tatsächlich haben nur sehr wenige Websites die Zeit oder die Ressourcen, sie umzusetzen. Auch einige Empfehlungen sind wichtig, aber die meisten Websites setzen diese Praktiken bereits um.
Kurz gesagt: Unsere Empfehlungen zur Leistungsoptimierung im Web sollten sich auf Folgendes konzentrieren:
- Empfehlungen, von denen wir glauben, dass sie die größte Wirkung in der Praxis haben
- Empfehlungen, die relevant und für die meisten Websites relevant sind
- Empfehlungen, die von den meisten Entwicklern realistisch sind
Im vergangenen Jahr haben wir viel Zeit damit verbracht, alle von uns gegebenen Leistungsempfehlungen zu prüfen und jede einzelne (sowohl qualitativ als auch quantitativ) anhand der oben genannten drei Kriterien zu bewerten.
In diesem Beitrag werden unsere wichtigsten Empfehlungen zur Leistungsverbesserung für jeden der Core Web Vitals-Messwerte beschrieben. Wenn Sie noch keine Erfahrung mit der Webleistung haben oder wissen möchten, was Ihnen die besten Ergebnisse bringt, sind diese Empfehlungen der beste Ausgangspunkt.
Largest Contentful Paint (LCP)
Die erste Reihe von Empfehlungen bezieht 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 im Web erfüllen derzeit den empfohlenen Grenzwert. Fangen wir also damit an.
Achten Sie darauf, dass die LCP-Ressource in der HTML-Quelle sichtbar ist
Laut dem HTTP-Archiv Web Almanac 2022 haben 72% der mobilen Seiten ein Bild als LCP-Element. Das bedeutet, dass bei den meisten Websites zur Optimierung des LCP-Werts dafür gesorgt werden muss, dass diese Bilder schnell geladen werden können.
Was für viele Entwickler nicht offensichtlich ist, ist, dass das Laden eines Bildes nur ein Teil der Herausforderung ist. Ein weiterer wichtiger Teil ist die Zeit, bis ein Bild geladen wird. Die Daten aus dem HTTP-Archiv deuten darauf hin, dass viele Websites hier schiefgehen.
Tatsächlich hatten 39% der Seiten, auf denen das LCP-Element ein Bild war, Quell-URLs, die aus der HTML-Dokumentquelle nicht ermittelbar waren. Das bedeutet, dass diese URLs nicht in Standard-HTML-Attributen wie <img src="..."> oder <link rel="preload" href="..."> gefunden wurden. So konnte der Browser sie schnell erkennen und sofort laden.
Wenn eine Seite warten muss, bis die 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.
Grundsätzlich gilt: Wenn Ihr LCP-Element ein Bild ist, muss die URL des Bildes in der HTML-Quelle immer sichtbar sein. Hier sind einige Tipps, wie du das erreichen kannst:
Laden Sie das Bild mithilfe eines
<img>-Elements mit dem Attributsrcodersrcset. Verwenden Sie keine nicht standardmäßigen Attribute wiedata-src, für deren Darstellung JavaScript erforderlich ist, da dies immer langsamer ist. 9% der Seiten verdecken ihr LCP-Bild hinterdata-src.Bevorzugen Sie serverseitiges Rendering (SSR) dem clientseitigen Rendering (CSR), da die SSR impliziert, dass in der HTML-Quelle das vollständige Seiten-Markup (einschließlich des Bildes) vorhanden ist. Bei CSR-Lösungen muss JavaScript ausgeführt werden, bevor das Bild gefunden werden kann.
Falls in 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 einfügen. Beachten Sie, dass Bilder, auf die Inline-Styles verweisen, vom Vorabladescanner nicht gefunden werden können. Obwohl sie sich in der HTML-Quelle befinden, können sie beim Laden anderer Ressourcen aber möglicherweise blockiert werden. In diesen Fällen kann das Vorabladen hilfreich sein.
Damit du besser nachvollziehen kannst, ob es bei deinem LCP-Bild Probleme mit der Auffindbarkeit gibt, veröffentlicht Lighthouse in Version 10.0 eine neue Prüfung (voraussichtlich im Januar 2023).
Wenn du dafür sorgst, dass die LCP-Ressource von der HTML-Quelle aus gefunden werden kann, kann dies zu messbaren Verbesserungen führen. Außerdem werden dadurch zusätzliche Möglichkeiten zur Priorisierung der Ressource geschaffen. Dies ist unsere nächste Empfehlung.
Achten Sie darauf, dass die LCP-Ressource priorisiert wird
Sicherzustellen, dass die LCP-Ressource aus der HTML-Quelle erkannt werden kann, ist ein wichtiger erster Schritt, um sicherzustellen, dass die LCP-Ressource früher geladen wird. Ein weiterer wichtiger Schritt besteht jedoch darin, sicherzustellen, dass das Laden dieser Ressource priorisiert wird und nicht hinter einer Reihe weniger wichtiger Ressourcen in die Warteschlange gestellt wird.
Selbst wenn Ihr LCP-Bild in der HTML-Quelle mit einem standardmäßigen <img>-Tag vorhanden ist und Ihre Seite vor diesem <img>-Tag im <head>-Tag ein Dutzend <script>-Tags enthält, kann es eine Weile dauern, bis die Bildressource geladen wird.
Am einfachsten lösen Sie dieses Problem, indem Sie dem Browser einen Hinweis darauf geben, welche Ressourcen die höchste Priorität haben. Dazu legen Sie das neue Attribut fetchpriority="high" für das Tag <img> oder <link> fest, mit dem Ihr LCP-Bild geladen wird. Dadurch wird der Browser angewiesen, die Datei früher zu laden, anstatt auf den Abschluss der Skripte zu warten.
Laut Web Almanac nutzen nur 0,03% der infrage kommenden Seiten diese neue API.Das bedeutet, dass es für die meisten Websites viele Möglichkeiten gibt, den LCP mit minimalem Aufwand zu verbessern. Das Attribut fetchpriority wird zwar derzeit nur in Chromium-basierten Browsern unterstützt, aber diese API ist eine progressive Verbesserung, die andere Browser einfach ignorieren. Wir empfehlen Entwicklern, sie jetzt zu verwenden.
Wenn Sie einen anderen Browser als Chromium verwenden, kann nur durch Verweis auf die LCP-Ressource im Dokument sichergestellt werden, dass sie Vorrang vor anderen Ressourcen hat. Nehmen wir noch einmal das Beispiel einer Website mit vielen <script>-Tags in <head> des Dokuments. Wenn Sie sichergehen möchten, dass Ihre LCP-Ressource vor diesen Skriptressourcen priorisiert wird, können Sie ein <link rel="preload">-Tag vor diesen Skripts einfügen oder diese Skripts später in der <body> unter das <img> verschieben. Das funktioniert zwar, ist aber weniger ergonomisch als die Verwendung von fetchpriority. Wir hoffen, dass bald auch andere Browser unterstützt werden.
Ein weiterer wichtiger Aspekt bei der Priorisierung der LCP-Ressource besteht darin, dass Sie nichts unternehmen, das zu einer schlechter Priorität führt, wie das Hinzufügen des Attributs loading="lazy". Mittlerweile setzen 10% der Seiten tatsächlich loading="lazy" auf ihrem LCP-Bild. Hüten Sie sich vor Bildoptimierungslösungen, die Lazy Loading wahllos auf alle Bilder anwenden. Wenn die Möglichkeit besteht, dieses Verhalten zu überschreiben, achten Sie darauf, die entsprechende Option für das LCP-Bild zu verwenden. Wenn Sie nicht sicher sind, welches Bild der LCP sein soll, wählen Sie anhand der Heuristik einen vernünftigen Kandidaten aus.
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 steuern, wie Analytics-Skripts oder Widgets für soziale Netzwerke, sicher bis nach dem Auslösen des load-Ereignisses verschoben werden. So wird sichergestellt, dass sie nicht mit anderen kritischen Ressourcen (z. B. der LCP-Ressource) um die Netzwerkbandbreite konkurrieren.
Zusammenfassend lässt sich sagen, dass Sie die folgenden Best Practices befolgen sollten, damit die LCP-Ressource frühzeitig und mit hoher Priorität geladen wird:
- Füge
fetchpriority="high"in das<img>-Tag deines LCP-Images ein. Wenn die LCP-Ressource über ein<link rel="preload">-Tag geladen wird, ist das nicht schlimm, denn du kannst dafür auchfetchpriority="high"festlegen. - Legen Sie niemals
loading="lazy"für das<img>-Tag des LCP-Bilds fest. Dadurch wird dem Bild eine geringere Priorität eingeräumt und der Ladevorgang verzögert. - Verzögern Sie nicht kritische Ressourcen nach Möglichkeit. 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 von Dokument- und Ressourcen-TTFB verwenden
Bei den beiden vorherigen Empfehlungen geht es darum, die LCP-Ressource frühzeitig zu erkennen und zu priorisieren, damit sie sofort mit dem Laden beginnen kann. Das letzte Teil dieses Puzzles besteht darin, sicherzustellen, dass die erste Antwort auf das Dokument schnellstmöglich eintrifft.
Der Browser kann erst dann mit dem Laden von Unterressourcen beginnen, wenn er das erste Byte der ursprünglichen HTML-Dokumentantwort empfangen hat. Je früher dies geschieht, desto früher kann auch alles andere passieren.
Diese Zeit wird als Time to First Byte (TTFB) bezeichnet. Die beste Möglichkeit, TTFB zu reduzieren, ist wie folgt:
- Stellen Sie Ihre Inhalte möglichst geografisch in der Nähe Ihrer Nutzer bereit.
- Speichern Sie diese Inhalte im Cache, damit kürzlich angeforderte Inhalte schnell wieder bereitgestellt werden können.
Die beste Möglichkeit, diese beiden Dinge zu erreichen, ist die Verwendung eines CDN. CDNs verteilen Ihre Ressourcen auf Edge-Server, die auf der ganzen Welt verteilt sind. Dadurch wird die Distanz begrenzt, die diese Ressourcen über die Verbindung zu Ihren Nutzern zurücklegen müssen. CDNs verfügen in der Regel auch über detaillierte 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 solche, die dynamisch generiert werden.
Laut Web Almanac wurden nur 29% der HTML-Dokumentanfragen von einem CDN bereitgestellt. Für Websites besteht 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 sollen. Ist es beispielsweise wirklich wichtig, dass Inhalte immer aktuell sind? Oder kann es ein paar Minuten veraltet sein?).
- Sie könnten Inhalte sogar unbegrenzt im Cache speichern und dann den Cache leeren, wenn Sie eine Aktualisierung vornehmen.
- Untersuchen Sie, ob Sie die dynamische Logik, die derzeit auf Ihrem Ursprungsserver ausgeführt wird, zum Edge verschieben können, einer Funktion der meisten modernen CDNs.
Grundsätzlich gilt: Wenn Sie Inhalte direkt vom Edge-Netzwerk aus bereitstellen können und so eine Reise zu Ihrem Ursprungsserver vermieden wird, ist dies eine Leistungssteigerung. Und selbst wenn Sie den Weg zurück zu Ihrem Ursprungsserver müssen, sind die CDNs in der Regel für ein viel schnelleres Arbeiten optimiert, sodass sie in beiden Fällen von Vorteil ist.
Cumulative Layout Shift (CLS)
Die nächsten Empfehlungen beziehen sich auf Cumulative Layout Shift (CLS), ein Maß für die visuelle Stabilität auf Webseiten. Obwohl sich der CLS-Wert im Web seit 2020 erheblich verbessert hat, erreichen etwa ein Viertel der Websites immer noch nicht die empfohlenen Grenzwerte. Für viele Websites besteht also weiterhin die Chance, die Nutzerfreundlichkeit zu verbessern.
Explizite Größen für alle Inhalte festlegen, die von der Seite geladen werden
Layoutverschiebungen treten normalerweise auf, wenn vorhandene Inhalte verschoben werden, nachdem andere Inhalte geladen wurden. Daher empfiehlt es sich, den erforderlichen Platz so weit wie möglich im Voraus zu reservieren, um dies zu vermeiden.
Am einfachsten lassen sich Layoutverschiebungen, die durch nicht hervorgehobene Bilder verursacht werden, beheben, indem Sie die Attribute width und height (oder entsprechende CSS-Eigenschaften) explizit festlegen. Allerdings weisen laut HTTP-Archiv auf 72% der Seiten mindestens ein unformatiertes Bild auf. Ohne explizite Größe wird im Browser zunächst eine Standardhöhe von 0px festgelegt. Wenn das Bild schließlich geladen ist und die Abmessungen erkannt werden, kann das zu einer merklichen Layoutverschiebung führen. Dies stellt eine große Chance für das gesamte Web dar und erfordert viel weniger Aufwand als einige der anderen Empfehlungen in diesem Artikel.
Außerdem sollten Sie bedenken, dass nicht nur Bilder zur CLS beitragen. Layoutverschiebungen können durch andere Inhalte verursacht werden, die normalerweise nach dem Rendern der Seite geladen werden. Dazu gehören Anzeigen von Drittanbietern oder eingebettete Videos. Mit der Property aspect-ratio lässt sich dies verhindern. Es handelt sich um eine relativ neue CSS-Funktion, mit der Entwickler sowohl für Bilder als auch für Elemente, die keine Bilder sind, ein Seitenverhältnis explizit angeben können. Auf diese Weise können Sie eine dynamische width festlegen (z. B. basierend auf der Bildschirmgröße) und der Browser die passende Höhe automatisch berechnen lässt, ähnlich wie bei Bildern mit Abmessungen.
Manchmal ist es nicht möglich, die genaue Größe von dynamischem Inhalt zu ermitteln, da er naturgemäß dynamisch ist. Aber auch wenn Sie die genaue Größe nicht kennen, können Sie Maßnahmen ergreifen, um die Wichtigkeit von Layoutverschiebungen zu reduzieren. Eine sinnvolle min-height festzulegen ist fast immer besser, als zuzulassen, dass der Browser die Standardhöhe von 0px für ein leeres Element verwendet. Die Verwendung eines min-height ist in der Regel auch eine einfache Lösung, da der Container so bei Bedarf weiterhin auf die endgültige Inhaltshöhe wachsen kann. Dadurch wurde das Wachstum von der vollständigen Menge auf ein hoffentlich akzeptableres Niveau reduziert.
Dafür sorgen, dass Seiten den bfcache verwenden können
Browser verwenden einen Navigationsmechanismus namens Back-Forward-Cache (kurz „bfcache“), um eine Seite aus einem früheren oder späteren Browserverlauf direkt aus einem Arbeitsspeicher-Snapshot direkt zu laden.
Mit dem bfcache lässt sich die Leistung auf Browserebene erheblich optimieren. Layoutverschiebungen während des Seitenaufbaus werden dabei vollständig eliminiert, da bei vielen Websites die CLS-Werte hier am häufigsten auftreten. Die Einführung des bfcache hat uns zu der größten Verbesserung des CLS im Jahr 2022 geführt.
Trotzdem kommen eine beträchtliche Anzahl von Websites nicht für den bfcache infrage und so lassen sich diese kostenlose Leistung im Web für eine beträchtliche Anzahl von Aufrufen nicht entgehen. Sofern Ihre Seite keine vertraulichen Daten lädt, die nicht aus dem Arbeitsspeicher wiederhergestellt werden sollen, sollten Sie sich vergewissern, dass Ihre Seiten die Anforderungen erfüllen.
Websiteinhaber sollten prüfen, ob ihre Seiten für den bfcache infrage kommen, und mögliche Gründe dafür prüfen. Chrome hat bereits einen bfcache-Tester in den Entwicklertools und dieses Jahr planen wir, die Tools hier durch eine neue Lighthouse-Prüfung, die einen ähnlichen Test durchführt, und eine API, um dies in der Praxis messen zu können zu verbessern.
Obwohl wir den bfcache in den CLS-Bereich aufgenommen haben, konnten wir bisher die größten Verbesserungen erzielen, aber bfcache wird in der Regel auch andere Core Web Vitals verbessern. Sie gehört zu den schnellen Navigationsoptionen, mit denen sich die Seitennavigation erheblich verbessern lässt.
Animationen/Übergänge vermeiden, die CSS-Eigenschaften verwenden, die das Layout beeinflussen
Eine weitere häufige Ursache für Layoutverschiebungen sind animierte Elemente. Cookie-Banner oder andere Benachrichtigungsbanner, die von oben oder unten in den Hintergrund verschoben werden, tragen häufig zu CLS bei. Dies ist besonders problematisch, wenn diese Banner andere Inhalte beiseiteschieben, aber selbst wenn sie dies nicht tun, kann eine Animation dennoch die CLS beeinträchtigen.
HTTP-Archiv-Daten lassen sich zwar nicht eindeutig mit Layout Shifts verknüpfen, aber die Daten zeigen, dass Seiten, die eine CSS-Property animieren, die sich auf das Layout auswirken könnte, eine um 15% geringere Wahrscheinlichkeit haben, dass sie eine „gute“ CLS haben als Seiten insgesamt. Bei einigen Properties ist die CLS schlechter als bei anderen. Beispielsweise haben Seiten, die die margin- oder border-Breite animieren, einen „schlechten“ CLS-Wert, der fast doppelt so hoch ist wie bei Seiten insgesamt als schlecht.
Das überrascht vielleicht nicht, denn jedes Mal, wenn Sie eine Layout-induzierende CSS-Eigenschaft umstellen oder animieren, führt dies zu Layoutverschiebungen. Wenn diese Layoutverschiebungen nicht innerhalb von 500 Millisekunden nach einer Nutzerinteraktion erfolgen, wirken sich sie auf die CLS aus.
Für manche Entwickler ist es vielleicht überraschend, dass dies auch dann der Fall ist, wenn das Element außerhalb des normalen Dokumentflusses übernommen wird. Genau positionierte Elemente, die top oder left animieren, führen beispielsweise zu Layoutverschiebungen, auch wenn sie keine anderen Inhalte verschieben. Wenn Sie jedoch nicht top oder left animieren, sondern transform:translateX() oder transform:translateY() animieren, führt dies nicht dazu, dass der Browser das Seitenlayout aktualisiert und es daher zu keinen Layoutverschiebungen kommt.
Die Bevorzugung der Animation von CSS-Eigenschaften, die im Compositor-Thread des Browsers aktualisiert werden können, gilt seit Langem als Best Practice für die Leistung, da die Elemente dadurch auf die GPU und außerhalb des Hauptthreads verschoben werden. Sie ist nicht nur eine allgemeine Best Practice, sondern kann auch zur Verbesserung der CLS beitragen.
Generell sollten CSS-Eigenschaften, bei denen der Browser das Seitenlayout aktualisieren muss, grundsätzlich niemals animiert oder übertragen werden, es sei denn, dies erfolgt durch Tippen oder Tastenbetätigung des Nutzers (jedoch nicht hover). Übergänge und Animationen sollten nach Möglichkeit immer mit der CSS-Eigenschaft transform verwendet werden.
In der Lighthouse-Prüfung Nicht zusammengesetzte Animationen vermeiden wird eine Warnung ausgegeben, wenn eine Seite potenziell langsame CSS-Eigenschaften animiert.
First Input Delay (FID)
Die letzten Empfehlungen betreffen First Input Delay (FID), ein Maß dafür, wie schnell eine Seite auf Nutzerinteraktionen reagiert. Obwohl die meisten Websites im Internet derzeit sehr gute Ergebnisse mit FID erzielen, haben wir in der Vergangenheit Schwachstellen des FID-Messwerts dokumentiert. Wir sind der Meinung, dass es für Websites noch viele Möglichkeiten gibt, ihre Reaktionsfähigkeit auf Nutzerinteraktionen insgesamt zu verbessern.
Der neue Messwert Interaction to Next Paint (INP) ist eine mögliche Nachfolge von FID und alle folgenden Empfehlungen gelten gleichermaßen für FID und INP. Da Websites mit INP schlechter abschneiden als FID, empfehlen wir Entwicklern, diese Empfehlungen für die Reaktionszeit ernst zu nehmen, auch wenn der FID-Wert als „gut“ gilt.
Lange Aufgaben vermeiden oder aufteilen
Aufgaben sind alle eigenständigen Aufgaben, die der Browser ausführt. Die Aufgaben umfassen das Rendern, das Layout, das Parsen sowie das Kompilieren und Ausführen von Skripts. Wenn Aufgaben zu langen Aufgaben – also 50 Millisekunden oder länger – werden, kann der Hauptthread nicht schnell auf Nutzereingaben reagieren.
Laut dem Web Almanac gibt es zahlreiche Beweise, die darauf hindeuten, dass Entwickler mehr tun könnten, um lange Aufgaben zu vermeiden oder aufzuteilen. Das Aufteilen langer Aufgaben ist vielleicht nicht so einfach wie andere Empfehlungen in diesem Artikel, aber es ist weniger Aufwand als andere Techniken, die in diesem Artikel nicht behandelt werden.
Sie sollten sich immer bemühen, in JavaScript so wenig Arbeit wie möglich zu erledigen, können den Hauptthread aber sehr unterstützen, indem Sie lange Aufgaben in kleinere Aufgaben aufteilen. Dies können Sie erreichen, indem Sie häufig an den Hauptthread liefern, damit Rendering-Updates und andere Nutzerinteraktionen schneller ausgeführt werden können.
Alternativ können Sie APIs wie isInputPending und die Scheduler API verwenden. 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 an den Hauptthread liefern, damit dieser die ausstehende Nutzereingabe verarbeiten kann.
Die Scheduler API ist ein ausgefeilterer Ansatz, mit dem Sie Aufgaben anhand eines Prioritätensystems planen können. Dabei wird berücksichtigt, ob die ausgeführte Arbeit für den Nutzer sichtbar oder im Hintergrund ist.
Wenn Sie lange Aufgaben aufteilen, gibt der Browser mehr Möglichkeiten, sich in kritische für den Nutzer sichtbare Aufgaben zu integrieren, beispielsweise im Umgang mit Interaktionen und den resultierenden Rendering-Aktualisierungen.
Vermeiden Sie unnötigen JavaScript-Code.
Es gibt keinen Zweifel: Websites veröffentlichen mehr JavaScript als je zuvor und der Trend wird sich auch in Zukunft nicht mehr ändern. Wenn Sie zu viel JavaScript versenden, schaffen Sie eine Umgebung, in der Aufgaben um die Aufmerksamkeit des Hauptthreads konkurrieren. Dies kann sich definitiv auf die Reaktionszeit Ihrer Website auswirken, insbesondere in dieser wichtigen Startphase.
Dieses Problem ist jedoch nicht unlösbar. Sie haben verschiedene Möglichkeiten:
- Mit dem Tool zur Abdeckung 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 sicherstellen, 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 „unused“ gekennzeichnet, weil er nicht beim Start ausgeführt wurde, aber für einige Funktionen in Zukunft dennoch erforderlich ist. Dies ist Code, den Sie per Codeaufteilung in ein separates Bundle verschieben können.
- Wenn Sie Tag-Manager verwenden, müssen Sie regelmäßig Ihre Tags prüfen, um sicherzustellen, dass sie optimiert sind bzw. ob sie noch verwendet werden. Ältere Tags mit nicht verwendetem Code können Sie entfernen, damit das JavaScript Ihres Tag Managers kleiner und effizienter wird.
Umfangreiche Rendering-Updates vermeiden
JavaScript ist nicht der einzige Faktor, der die Reaktionsfähigkeit Ihrer Website beeinflussen kann. Das Rendering kann eine kostspielige Arbeit sein. Wenn umfangreiche Rendering-Updates stattfinden, kann dies dazu führen, dass Ihre Website nicht mehr auf Nutzereingaben reagiert.
Die Optimierung der Rendering-Arbeit ist nicht einfach 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 sinnvoll sind und nicht zu langen Aufgaben übergehen:
- 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 geleistet wird, können sich Rendering-Aktualisierungen verzögern. Es ist wichtig, dass alle Vorgänge, die du mitrequestAnimationFrame()machst, ausschließlich Aufgaben vorbehalten sind, die Rendering-Updates erfordern. - 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 zunehmen.
- CSS-Eindämmung verwenden Die CSS-Eindämmung basiert auf der CSS-Eigenschaft
contain, die dem Browser Anweisungen gibt, wie Layoutarbeiten für den Container ausgeführt werden können, auf den diecontain-Eigenschaft festgelegt ist. Dabei wird sogar der Umfang des Layouts und des Renderings für einen bestimmten Stamm im DOM isoliert. Dies ist nicht immer einfach. Wenn Sie jedoch Bereiche mit komplexen Layouts isolieren, können Sie unnötige Layout- und Renderingarbeiten vermeiden.
Fazit
Das Verbessern der Seitenleistung kann eine gewaltige Aufgabe sein, zumal es eine Menge Leitlinien im Web gibt, die berücksichtigt werden müssen. Wenn Sie sich auf diese Empfehlungen konzentrieren, können Sie das Problem jedoch fokussiert und zielgerichtet angehen und hoffentlich die Core Web Vitals Ihrer Website verbessern.
Die hier aufgeführten Empfehlungen sind bei Weitem nicht vollständig. Wir sind aber aufgrund einer sorgfältigen Analyse des Webs davon überzeugt, dass diese Empfehlungen die effektivsten Möglichkeiten zur Verbesserung der Core Web Vitals-Leistung von Websites im Jahr 2023 darstellen.
Wenn Sie über die hier aufgeführten Empfehlungen hinausgehen möchten, sehen Sie sich diese Optimierungsleitfäden mit weiteren Informationen an:
Auf ein neues Jahr und ein schnelleres Web für alle! Wir möchten, dass Ihre Websites in allen wichtigen Bereichen schnell laden.
Foto von Devin Avery