Die effektivsten Möglichkeiten zur Verbesserung der Core Web Vitals

Im Laufe der Jahre hat die Web-Community umfangreiches Wissen zur Optimierung der Webleistung aufgebaut. Eine einzelne Optimierung kann die Leistung vieler Websites verbessern. Wenn Sie jedoch alle gleichzeitig vornehmen, kann das überwältigend sein. Realistisch gesehen sind nur einige davon für eine bestimmte Website geeignet.

Sofern die Webleistung nicht Ihr täglicher Job ist, ist es wahrscheinlich nicht offensichtlich, welche Optimierungen für Ihre Website am effektivsten sind. Sie werden wahrscheinlich nicht für alle Zeit haben. Daher ist es wichtig, sich zu fragen, welche Optimierungen die größte Wirkung haben, um die Leistung für Ihre Nutzer zu verbessern?

Die Wahrheit über Leistungsoptimierungen: Sie können sie nicht nur anhand ihrer technischen Vorzüge beurteilen. Außerdem müssen Sie die menschlichen und organisatorischen Faktoren berücksichtigen, die die Wahrscheinlichkeit beeinflussen, mit der Sie eine bestimmte Optimierung umsetzen können. Einige Leistungsverbesserungen können in der Theorie einen großen Einfluss haben, aber in Wirklichkeit haben nur wenige Entwickler die Zeit oder Ressourcen, sie zu implementieren. Andererseits gibt es möglicherweise Best Practices mit enormer Wirkung auf die Leistung, die fast jeder bereits umsetzt. In diesem Leitfaden werden Optimierungen der Webleistung beschrieben, die:

  • die größte reale Wirkung haben
  • Sie sind für die meisten Websites relevant und anwendbar.
  • für die meisten Entwickler realistisch umsetzbar sind

Zusammengenommen sind dies die realistischsten und effektivsten Möglichkeiten, Ihre Core Web Vitals-Messwerte zu verbessern. Wenn Sie noch keine Erfahrung mit der Webleistung haben oder noch nicht wissen, wie Sie den größten Return on Investment erzielen, ist dies der beste Ausgangspunkt.

Interaction to Next Paint (INP)

Als neuester Core Web Vital-Messwert bietet Interaction to Next Paint (INP) einige der größten Verbesserungsmöglichkeiten. Da jedoch im Vergleich zum veralteten Vorgänger viel weniger Websites den Grenzwert für eine „gute“ Nutzererfahrung erreichen, gehören Sie möglicherweise zu den vielen Entwicklern, die zum ersten Mal lernen, wie sie die Reaktionsfähigkeit von Interaktionen optimieren können. Beginnen Sie mit diesen wichtigen Techniken, um die effektivsten Möglichkeiten zur Verbesserung des Anzeigen-Impressionswerts zu erfahren.

1. Oftmals innehalten, um lange Aufgaben aufzuteilen

Aufgaben sind alle einzelnen Aufgaben, die der Browser ausführt, einschließlich Rendering, Layout, Parsen, Kompilieren oder Ausführen von Scripts. Wenn eine Aufgabe länger als 50 Millisekunden dauert, wird sie zu einer langen Aufgabe. Lange Aufgaben sind problematisch, da sie verhindern können, dass der Haupt-Thread schnell auf Nutzerinteraktionen reagiert.

Sie sollten zwar immer versuchen, in JavaScript so wenig Arbeit wie möglich zu erledigen, aber Sie können dem Hauptthread helfen, indem Sie lange Aufgaben aufteilen. Dazu können Sie häufig den Hauptthread ausführen, damit Rendering-Aktualisierungen und andere Nutzerinteraktionen schneller erfolgen.

Browser Support

  • Chrome: 129.
  • Edge: 129.
  • Firefox: not supported.
  • Safari: not supported.

Source

Mit der Scheduler API können Sie Aufgaben mithilfe eines Prioritätssystems in die Warteschlange stellen. Insbesondere wird mit der scheduler.yield() API die Ausführung langer Aufgaben unterbrochen, während sichergestellt wird, dass Interaktionen verarbeitet werden können, ohne ihren Platz in der Aufgabenwarteschlange aufzugeben.

Indem Sie lange Aufgaben aufteilen, geben Sie dem Browser mehr Möglichkeiten, wichtige Aufgaben auszuführen, die die Nutzer blockieren.

2. Unnötiges JavaScript vermeiden

Auf Websites wird mehr JavaScript als je zuvor verwendet und dieser Trend scheint sich nicht zu ändern. Wenn Sie zu viel JavaScript verwenden, schaffen Sie eine Umgebung, in der Aufgaben um die Aufmerksamkeit des Haupt-Threads konkurrieren. Dies kann sich auf die Reaktionsfähigkeit Ihrer Website auswirken, insbesondere in der wichtigen Startphase.

Dieses Problem lässt sich jedoch lösen und Sie haben folgende Möglichkeiten:

  • Verwenden Sie Standard-Webplattformfunktionen, die weithin verfügbar sind, anstelle redundanter JavaScript-basierter Implementierungen.
  • Mit dem Abdeckungstool in den Chrome-Entwicklertools können Sie nicht verwendeten Code in Ihren Scripts finden. Wenn Sie die Größe der beim Start erforderlichen Ressourcen reduzieren, wird beim Parsen und Kompilieren von Code weniger Zeit auf den Seiten benötigt. Das sorgt für eine reibungslosere Nutzererfahrung.
  • Mit der Codeaufteilung können Sie ein separates Bundle für Code erstellen, der für das erste Rendern nicht erforderlich ist, aber später verwendet wird.
  • Wenn Sie einen Tag-Manager verwenden, optimieren Sie Ihre Tags regelmäßig. Ältere Tags mit nicht verwendetem Code können entfernt werden, um den JavaScript-Footprint Ihres Tag Managers zu reduzieren.

3. Große Rendering-Aktualisierungen vermeiden

Die JavaScript-Ausführung ist nur einer der Faktoren, die sich auf die Responsivität Ihrer Website auswirken. Das Rendering ist an sich schon eine kostspielige Angelegenheit. Bei großen Rendering-Updates reagiert Ihre Website möglicherweise noch langsamer auf Nutzerinteraktionen.

Die Optimierung von Rendering-Aufgaben ist nicht einfach und hängt davon ab, was Sie erreichen möchten. Trotzdem gibt es einige Möglichkeiten, wie Sie dafür sorgen können, dass Rendering-Aufgaben nicht zu lang werden:

  • Organisieren Sie DOM-Lese- und Schreibvorgänge in Ihrem JavaScript-Code neu, um erzwungene Layouts und Layout-Überlastungen zu vermeiden.
  • Begrenzen Sie die Größe des DOM. Die Größe des DOM 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 Aufwand für die Neuberechnung des Layouts erheblich steigen.
  • Verwenden Sie CSS-Begrenzungen, um DOM-Inhalte außerhalb des Bildschirms verzögert zu rendern. Das ist nicht immer ganz einfach, aber wenn Sie Bereiche mit komplexen Layouts isolieren, können Sie unnötige Layout- und Rendering-Arbeiten vermeiden.

Largest Contentful Paint (LCP)

Der Largest Contentful Paint (LCP) ist der Core Web Vital, mit dem Entwickler am häufigsten zu kämpfen haben. 40% der Websites im Chrome UX-Bericht erfüllen nicht den empfohlenen LCP-Grenzwert für eine gute Nutzerfreundlichkeit. Das Chrome-Team empfiehlt die folgenden Methoden als die effektivsten Möglichkeiten, die LCP zu verbessern.

1. Sorgen Sie dafür, dass die LCP-Ressource in der HTML-Quelle sichtbar ist und priorisiert wird.

Das Chrome-Team hat Folgendes im Hinblick auf LCP im Web festgestellt:

  • Laut dem Web Almanac 2024 des HTTP Archive haben 73% der mobilen Seiten ein Bild als LCP-Element.
  • Eine Analyse von Echtzeitnutzerdaten aus Chrome zeigt, dass bei der Mehrheit der Ursprünge mit schlechtem LCP weniger als 10 % der LCP-Zeit von 75 % für das Herunterladen des LCP-Bildes aufgewendet werden.
  • Bei Seiten mit schlechtem LCP dauert das Laden der LCP-Bilder auf dem Client im 75. Perzentil 1.290 Millisekunden. Das ist mehr als die Hälfte des Budgets für eine schnelle Website.
  • Bei Seiten, auf denen das LCP-Element ein Bild war, hatten 35% dieser Bilder Quell-URLs, die in der ursprünglichen HTML-Antwort nicht gefunden werden konnten (z. B. <img src="..."> oder <link rel="preload" href="...">). Dadurch konnten sie vom Browser-Preload-Scanner nicht so schnell wie möglich gefunden werden.
  • Laut Web Almanac nutzen 15% der infrage kommenden Seiten das HTML-Attribut fetchpriority, um Ressourcen eine höhere Priorität zu geben, einschließlich solcher, mit denen sich der LCP einer Seite mit relativ wenig Aufwand verbessern lässt.

Diese Statistiken zeigen, dass Entwickler eine große Chance haben, sowohl die Verzögerung beim Laden der Ressourcen als auch die Dauer des Ressourcenladevorgangs für LCP-Bilder zu reduzieren.

Browser Support

  • Chrome: 102.
  • Edge: 102.
  • Firefox: 132.
  • Safari: 17.2.

Source

Wenn das Problem auf eine Verzögerung beim Laden von Ressourcen zurückzuführen ist, ist es wichtig zu wissen, dass es möglicherweise schon zu spät ist, um eine gute LCP zu erreichen, wenn eine Seite warten muss, bis CSS oder JavaScript vollständig geladen ist, bevor Bilder überhaupt geladen werden können. Außerdem kann die Dauer der Ressourcenauslastung eines LCP-Bildes reduziert werden, indem es mithilfe des HTML-Attributs fetchpriority neu priorisiert wird, sodass es mehr Bandbreite erhält und somit schneller geladen wird.

Wenn Ihr LCP-Element ein Bild ist, sollte die URL des Bilds in der HTML-Antwort zu finden sein, um die Verzögerung beim Laden der Ressourcen zu verringern. Hier einige Tipps, wie Sie das erreichen:

  • Laden Sie das Bild mit einem <img>-Element mit dem Attribut src oder srcset hoch. Verwenden Sie keine nicht standardmäßigen Attribute wie data-src, für die JavaScript zum Rendern erforderlich ist, da dies immer langsamer ist. Auf 7% der Seiten ist das LCP-Bild hinter data-src verborgen.
  • Verwenden Sie das serverseitige Rendering (SSR) anstelle des clientseitigen Renderings (CSR), da beim SSR das vollständige Seiten-Markup (einschließlich des Bilds) in der HTML-Quelle vorhanden ist. Bei CSR-Lösungen muss JavaScript ausgeführt werden, bevor das Bild erkannt werden kann.
  • Wenn auf Ihr Bild aus einer externen CSS- oder JS-Datei verwiesen werden muss, können Sie es trotzdem mit einem <link rel="preload">-Tag in die HTML-Quelle einfügen. Bilder, auf die durch Inline-Styles verwiesen wird, können vom Vorab-Scanner des Browsers nicht gefunden werden. Auch wenn sie in der HTML-Quelle gefunden werden, kann es sein, dass sie beim Laden anderer Ressourcen nicht erkannt werden. In diesen Fällen kann das Vorabladen helfen.

Außerdem können Sie die Ladedauer einer Ressource verkürzen, indem Sie dafür sorgen, dass die LCP-Ressource früh und mit hoher Priorität geladen wird:

  • Fügen Sie dem <img>- oder <link rel="preload">-Tag des LCP-Bilds das Attribut fetchpriority="high" hinzu. Dadurch wird die Priorität der Bildressource erhöht, sodass sie früher geladen werden kann.
  • Entfernen Sie das loading="lazy"-Attribut aus dem <img>-Tag Ihres LCP-Bilds. So wird die Ladeverzögerung vermieden, die durch die Bestätigung entsteht, dass sich das Bild im oder in der Nähe des Darstellungsbereichs befindet.
  • Verschieben Sie nicht kritische Ressourcen nach Möglichkeit. Wenn Sie diese Ressourcen ans Ende Ihres Dokuments verschieben, Bilder oder iFrames mit Lazy Loading laden oder sie asynchron mit JavaScript laden, können wichtigere Ressourcen wie das LCP-Bild schneller geladen werden.

2. Für sofortige Navigation sorgen

Idealerweise müssen Nutzer nie warten, bis eine Seite geladen ist. LCP-Optimierungen wie die Sichtbarkeit und Priorisierung von Ressourcen können effektiv dazu beitragen, die Wartezeit der Nutzer auf das Laden und Rendern des LCP-Elements zu verkürzen. Es gibt jedoch eine physische Grenze dafür, wie schnell diese Bytes über das Netzwerk geladen und auf einer Seite gerendert werden können. Schon lange vor Erreichen dieses Limits ist ein unverhältnismäßig hoher Aufwand erforderlich, um nur wenige Millisekunden einzusparen. Um eine sofortige Navigation zu ermöglichen, müssen wir also einen radikal anderen Ansatz verfolgen.

Bei der sofortigen Navigation wird versucht, die Seite vor dem Aufruf durch den Nutzer zu laden und zu rendern. So kann die vorab gerenderte Seite sofort mit einer LCP von nahezu null angezeigt werden. Rekonstruktionen und Spekulationen sind zwei Möglichkeiten, dies zu tun. Wenn ein Nutzer zu einer zuvor besuchten Seite zurückkehrt oder vorwärts wechselt, kann sie schnell aus einem In-Memory-Cache wiederhergestellt werden und wird genau so angezeigt, wie der Nutzer sie verlassen hat. Alternativ können Webanwendungen versuchen, vorherzusagen, wohin ein Nutzer als Nächstes gehen wird. Wenn die Vorhersage zutrifft, ist die nächste Seite bereits geladen und gerendert, wenn der Nutzer dorthin wechselt.

Das Wiederherstellen zuvor besuchter Seiten wird durch den Back-Forward-Cache (bfcache) ermöglicht. Damit Sie ihn verwenden können, müssen Ihre Seiten die Teilnahmevoraussetzungen für bfcache erfüllen. Häufige Gründe dafür, dass Seiten nicht für den bfcache infrage kommen, sind Cache-Direktive vom Typ no-store oder Ereignis-Listener vom Typ unload.

Wenn Sie vollständig gerenderte Seiten wiederherstellen, wird nicht nur die Ladeleistung, sondern auch die Layoutstabilität verbessert. Weitere Informationen zum bfcache und dazu, wie effektiv er die CLS verbessern kann, finden Sie im Abschnitt Dafür sorgen, dass Seiten für den bfcache infrage kommen.

Browser Support

  • Chrome: 109.
  • Edge: 109.
  • Firefox: not supported.
  • Safari: not supported.

Das Vorab-Rendering der nächsten Seite, die ein Nutzer besucht, ist eine weitere effektive Möglichkeit, die LCP-Leistung drastisch zu verbessern. Dies wird durch die Speculation Rules API ermöglicht. Damit Sie diese Vorteile nutzen können, müssen die richtigen Seiten vorab gerendert werden. Falsche Spekulationen verschwenden Ressourcen sowohl auf dem Server als auch auf dem Client, was sich negativ auf die Leistung auswirken kann. Je weniger Sie also sicher sind, wie die nächste Seite aussehen wird, desto konservativer sollten Sie beim Vorab-Rendering vorgehen. Wenn Sie sich nicht sicher sind, können Ihre Analysedaten Ihnen helfen, Seiten, die mit hoher Wahrscheinlichkeit als Nächstes besucht werden, schneller vorab zu rendern.

3. TTFB mit einem CDN optimieren

Die vorherige Empfehlung konzentrierte sich auf die sofortige Navigation, die Nutzern die bestmögliche Nutzererfahrung bietet. Es kann jedoch Situationen geben, in denen die bfcache- und die Techniken für die spekulative Datenübertragung nicht anwendbar sind. Angenommen, ein Nutzer folgt einem plattformübergreifenden Link zu Ihrer Website, bei dem die Antwort des ursprünglichen HTML-Dokuments den LCP effektiv blockiert. Der Browser kann erst dann mit dem Laden von Unterressourcen beginnen, wenn er das erste Byte der Antwort erhalten hat. Je früher das passiert, desto früher kann alles andere beginnen.

Diese Zeit wird als Time to First Byte (TTFB) bezeichnet. So können Sie die TTFB am besten reduzieren:

  • Bieten Sie Ihre Inhalte so nah wie möglich an Ihren Nutzern an.
  • Diese Inhalte werden im Cache gespeichert, damit sie schnell bereitgestellt werden können, wenn sie in naher Zukunft noch einmal angefordert werden.

Am besten verwenden Sie dazu ein CDN. CDNs verteilen Ihre Ressourcen auf Edge-Server auf der ganzen Welt und begrenzen so die Entfernung, die diese Ressourcen über das Netzwerk zurücklegen müssen, um Nutzer zu erreichen. CDNs bieten in der Regel auch detaillierte Caching-Steuerungen, die an die Anforderungen Ihrer Website angepasst werden können.

CDNs können auch HTML-Dokumente bereitstellen und im Cache speichern. Laut Web Almanac wurden jedoch nur 33% der Anfragen für HTML-Dokumente über ein CDN ausgeliefert. Das bedeutet, dass es für Websites eine große Chance gibt, zusätzliche Einsparungen zu erzielen.

Hier einige Tipps zur Konfiguration von CDNs:

  • Statische HTML-Dokumente werden auch für kurze Zeit im Cache gespeichert. Ist es beispielsweise wichtig, dass die Inhalte immer aktuell sind? Oder darf es ein paar Minuten alt sein?
  • Prüfen Sie, ob Sie die dynamische Logik, die auf Ihrem Ursprungsserver ausgeführt wird, an den Edge verschieben können. Dies ist eine Funktion der meisten modernen CDNs.

Jedes Mal, wenn Sie Inhalte direkt über das Edge-Netzwerk bereitstellen und einen Zugriff auf Ihren Ursprungsserver vermeiden können, ist das ein Leistungsgewinn. Auch wenn Sie tatsächlich bis zum Ursprung gehen müssen, sind CDNs in der Regel so optimiert, dass dies schneller geht. In jedem Fall ist das also von Vorteil.

Cumulative Layout Shift (CLS)

Der Cumulative Layout Shift (CLS) ist ein Maß für die visuelle Stabilität einer Webseite. Der CLS ist der Messwert, bei dem die meisten Websites gute Werte erzielen. Etwa ein Viertel erfüllt jedoch immer noch nicht den empfohlenen Grenzwert. Es gibt also noch viel Potenzial, die Nutzerfreundlichkeit vieler Websites zu verbessern.

1. Für alle Inhalte, die von der Seite geladen werden, explizite Größen festlegen

Layoutverschiebungen treten in der Regel auf, wenn vorhandene Inhalte verschoben werden, nachdem andere Inhalte geladen wurden. Die wichtigste Möglichkeit, den CLS zu verbessern, besteht darin, den erforderlichen Speicherplatz so weit wie möglich im Voraus zu reservieren.

Die beste Möglichkeit, Layoutverschiebungen zu korrigieren, die durch nicht skalierte Bilder verursacht werden, besteht darin, die Attribute width und height explizit festzulegen oder die entsprechenden CSS-Eigenschaften zu verwenden. 66% der Seiten haben mindestens ein nicht skaliertes Bild. Ohne explizite Größe haben diese Bilder eine anfängliche Höhe von 0px. Dies kann zu Layoutverschiebungen führen, wenn diese Bilder geladen werden und der Browser ihre Abmessungen erkennt. Das ist eine große Chance für das kollektive Web – und diese Chance erfordert weniger Aufwand als einige der anderen Empfehlungen in diesem Leitfaden.

Browser Support

  • Chrome: 88.
  • Edge: 88.
  • Firefox: 89.
  • Safari: 15.

Source

Bilder sind nicht der einzige Faktor für die CLS. Layoutänderungen können durch andere Inhalte verursacht werden, die in der Regel nach dem ersten Rendern der Seite geladen werden, z. B. Anzeigen von Drittanbietern oder eingebettete Videos. Hier kann das Attribut aspect-ratio hilfreich sein. Es ist eine weithin verfügbare CSS-Funktion, mit der Entwickler ein Seitenverhältnis für Bilder und andere Elemente explizit festlegen können. So können Sie eine dynamische width festlegen (z. B. basierend auf der Bildschirmgröße) und die entsprechende Höhe wird automatisch vom Browser berechnet, ähnlich wie bei Bildern mit Abmessungen.

Die genaue Größe dynamischer Inhalte ist jedoch nicht immer bekannt. Auch wenn Sie die genaue Größe nicht kennen, können Sie die Auswirkungen von Layoutänderungen verringern. Es ist fast immer besser, eine sinnvolle min-height festzulegen, als dem Browser zu erlauben, 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 weiterhin auf die Höhe der endgültigen Inhalte wachsen kann. Das Wachstum wird nur auf ein hoffentlich tolerierbares Maß reduziert.

2. Prüfen, ob Seiten für den Back-Forward-Cache infrage kommen

Wie bereits in diesem Leitfaden erwähnt, lädt der Back-Forward-Cache (bfcache) eine Seite aus einem früheren oder späteren Zeitpunkt im Browserverlauf sofort aus einem Speicher-Snapshot. Der bfcache ist eine erhebliche Leistungsoptimierung auf Browserebene, die die LCP verbessert und Layoutverschiebungen vollständig eliminiert. Die Einführung des bfcaches im Jahr 2022 war für die größte Verbesserung der CLS verantwortlich, die wir in diesem Jahr verzeichnet haben.

Trotzdem ist eine beträchtliche Anzahl von Websites nicht für den bfcache geeignet und verpasst so diese kostenlose Leistungssteigerung. Sofern auf Ihrer Seite keine vertraulichen Informationen geladen werden, die nicht aus dem Arbeitsspeicher wiederhergestellt werden sollen, sollten Sie dafür sorgen, dass Ihre Seiten den bfcache verwenden können.

Websiteinhaber sollten prüfen, ob Seiten für den bfcache infrage kommen, und alle Gründe beheben, die dagegen sprechen. In Chrome gibt es einen bfcache-Tester in den Entwicklertools. Außerdem können Sie die Not Restored Reasons API verwenden, um Gründe für die Nichtwiederherstellung im Feld zu ermitteln.

3. Vermeiden Sie Animationen und Übergänge, die Layout-induzierende CSS-Properties verwenden

Eine weitere häufige Ursache für Layoutverschiebungen ist die Animation von Elementen. Dazu gehören beispielsweise Cookie-Banner oder andere Benachrichtigungsbanner, die von oben oder unten eingeblendet werden. Das ist besonders problematisch, wenn diese Banner andere Inhalte verdecken. Aber auch wenn das nicht der Fall ist, kann sich die CLS durch die Animation beeinträchtigen lassen.

Anhand der HTTP Archive-Daten lässt sich zwar nicht eindeutig ein Zusammenhang zwischen Animationen und Layoutänderungen herstellen, aber die Daten zeigen, dass die Wahrscheinlichkeit, dass Seiten mit animierten CSS-Eigenschaften, die sich auf das Layout auswirken könnten, eine „gute“ CLS haben, um 15% geringer ist als bei Seiten insgesamt. Einige Properties haben einen schlechteren CLS als andere. Bei Seiten mit einer Breite von margin oder border ist die CLS beispielsweise fast doppelt so häufig als „schlecht“ eingestuft wie bei Seiten insgesamt.

Das ist vielleicht nicht überraschend, denn immer wenn Sie eine CSS-Eigenschaft ändern oder animieren, die das Layout beeinflusst, kommt es zu Layoutverschiebungen. Wenn diese Layoutverschiebungen nicht innerhalb von 500 Millisekunden nach einer Nutzerinteraktion auftreten, wirken sie sich auf die CLS aus.

Für einige Entwickler mag es überraschend sein, dass dies auch dann der Fall ist, wenn das Element außerhalb des normalen Dokumentflusses verwendet wird. Beispielsweise führen absolut positionierte Elemente, die top oder left animieren, zu Layoutverschiebungen, auch wenn sie andere Inhalte nicht verschieben. Wenn Sie jedoch anstelle von top oder left transform:translateX() oder transform:translateY() animieren, wird das Seitenlayout nicht vom Browser aktualisiert und es kommt nicht zu Layoutverschiebungen.

Die bevorzugte Animation von CSS-Eigenschaften, die im Kompositionsleiter des Browsers aktualisiert werden können, ist seit langem eine Best Practice für die Leistung, da diese Arbeit vom Hauptthread an die GPU verschoben wird. Dies ist nicht nur eine allgemeine Best Practice für die Leistung, sondern kann auch zur Verbesserung des CLS beitragen.

Als Faustregel gilt: Animieren oder überführen Sie niemals CSS-Eigenschaften, für die der Browser das Seitenlayout aktualisieren muss, es sei denn, Sie tun dies als Reaktion auf einen Nutzertipp oder eine Tastendruck (aber nicht hover). Verwenden Sie nach Möglichkeit Übergänge und Animationen mit der CSS-Eigenschaft transform.

Bei der Lighthouse-Analyse Nicht zusammengesetzte Animationen vermeiden wird gewarnt, wenn auf einer Seite potenziell langsame CSS-Properties animiert werden.

Fazit

Die Verbesserung der Seitenleistung kann entmutigend erscheinen, insbesondere angesichts der Fülle an Anleitungen im Web. Wenn Sie sich jedoch auf diese kurze Liste der effektivsten Best Practices konzentrieren, können Sie das Problem mit neuer Energie angehen und hoffentlich Verbesserungen bei den Core Web Vitals Ihrer Website erzielen.

Wenn Sie über die hier aufgeführten Optimierungen hinausgehen möchten, lesen Sie die folgenden Leitfäden:

Anhang: Änderungsprotokoll

Wesentliche Änderungen an diesem Dokument werden hier erfasst, um zu erklären, wann und warum sich die wichtigsten Empfehlungen geändert haben.

Oktober 2024

Aktualisierung 2024:

  • INP
    • Wir haben diesen Messwert von FID zu INP geändert, da INP als Core Web Vital-Messwert eingeführt wurde. Außerdem haben wir ihn an den Anfang der Liste gesetzt.
    • Wir haben unsere Empfehlung, die isInputPending API zur Aufteilung langer Aufgaben zu verwenden, zurückgezogen. Weitere Informationen zu unseren Gründen finden Sie im Artikel Lange Aufgaben optimieren.
  • LCP
    • Wir haben die Empfehlungen zur Sichtbarkeit und Priorisierung zu einer einzigen Empfehlung zusammengefasst.
    • Wir haben eine neue Empfehlung hinzugefügt, die auf sofortige Navigationen abzielt.

Januar 2023

Dies ist die erste Liste mit Empfehlungen:

  • LCP
    • Sorgen Sie dafür, dass die LCP-Ressource über die HTML-Quelle erreichbar ist.
    • LCP-Ressource priorisieren
    • TTFB für Dokumente und Ressourcen mit einem CDN optimieren
  • CLS
    • Für alle Inhalte, die von der Seite geladen werden, explizite Größen festlegen
    • Prüfen, ob Seiten für den Back-Forward-Cache infrage kommen
    • Vermeiden Sie Animationen und Übergänge, die Layout-induzierende CSS-Properties verwenden
  • FID
    • Lange Aufgaben vermeiden oder aufteilen
    • Unnötiges JavaScript vermeiden
    • Große Rendering-Aktualisierungen vermeiden

Eine Videozusammenfassung finden Sie auch in dieser Google I/O-Präsentation von 2023.