Googles Update vom Mai 2021: Ein genauerer Blick auf Core Web Vitals

UPDATE: Die Welt des digitalen Marketings verändert sich ständig, aber keine Sorge, wir haben den Überblick. Google hat seine Meinung über den kommenden Algorithmus geändert.

Lesen Sie die jüngsten Änderungen hier in unserem Update, aber lesen Sie auch diesen Blog.

Im Mai 2021 wird Google Core Web Vitals (CWV)-Metriken als Teil seines Suchranking-Algorithmus einführen. Folgendes müssen Sie wissen und bis dahin tun…

Wir alle wissen, dass schnelle Websites wichtig sind. Sie sorgen für eine bessere Benutzererfahrung, was zu höheren Konversionsraten führt, und berücksichtigen bereits das Ranking der mobilen Suche in Google zusammen mit anderen Seitenerfahrungsmetriken wie der Handyfreundlichkeit.

Aber Google hört hier nicht auf. Bereits im Mai 2020 haben sie uns von Core Web Vitals erzählt und am 10. November 2020 angekündigt, dass Core Web Vitals im Mai 2021 als Suchsignal in den Gesamtranking-Algorithmus aufgenommen wird.

Darüber hinaus planen sie, „einen visuellen Indikator zu testen, der Seiten in Suchergebnissen hervorhebt, die eine großartige Seitenerfahrung bieten“. Wir haben also nicht nur eine erhöhte Chance auf höhere Rankings durch die CWV-Optimierung, sondern auch die Aussicht auf höhere Klickraten von Suchmaschinen-Ergebnisseiten.

Wenn Sie jetzt handeln, um potenzielle Probleme zu prüfen und zu beheben, die mit diesen neuen CWV-Messwerten gemeldet werden, haben unsere Websites bessere Chancen auf höhere Google-Rankings, wenn diese Änderung im Jahr 2021 in Kraft tritt.

Aber zuerst eine Zusammenfassung…

Zusammenfassung: Was sind Core Web Vitals?

Core Web Vitals sind eine Reihe von drei neuen Metriken zur Seitenerfahrung, die in die Gesamtbewertung der Website-Geschwindigkeit einfließen. Diese Metriken spielen bereits an anderer Stelle eine herausragende Rolle in Googles PageSpeed ​​Insights-Tool PSI und Lighthouse Performance Monitoring.

Die neuen CWV-Metriken umfassen Folgendes:

Größte Contentful Paint (LCP)

Dies ist die Zeit, die benötigt wird, bevor dem Benutzer das größte Element über der Falte angezeigt wird. Es macht 25 % des gesamten Geschwindigkeitsbewertungsmechanismus aus und ist daher von entscheidender Bedeutung, die Lieferung des größten Artikels auf 2,5 Sekunden oder weniger auf Mobilgeräten zu optimieren.

Zahlreiche Faktoren tragen zu einem hohen LCP bei, darunter die Reaktionsfähigkeit des Servers, Render-Blocking-Skripte und -Stile, die Komplexität von CSS, Schriftarten und Bildern

Erste Eingangsverzögerung (FID)

Dies misst die Interaktivität; wie reagiert die Seite auf Benutzereingaben, beispielsweise durch Tippen oder Klicken. Die Zielgeschwindigkeit, mit der der Browser auf die erste Eingabe reagiert, sollte 100 ms oder weniger betragen.

Wenn der Browser während des Ladens der Seite viel JavaScript parst oder ausführt, wird die CPU belastet oder der 'Main Thread' blockiert, wodurch Geräte weniger auf Eingaben reagieren. Ein hoher FID ist normalerweise ein Indikator für komplexes JavaScript. Dies kann ein einzelnes Skript oder eine einzelne Funktion oder zahlreiche Skripte sein.

Bestehende PSI-Metriken für die Zeit bis zur Interaktivität und die Gesamtblockierungszeit beziehen sich auf die FID und machen zusammen satte 35 % der Gesamtgeschwindigkeitsbewertungen aus.

Kumulative Layoutverschiebung (CLS)

Dies ist ein Maß für die visuelle Stabilität des Inhalts oberhalb der Falte. Obwohl es nur 5% der Gesamtgeschwindigkeitswerte ausmacht, ist es im Gesamtbild dennoch eine Überlegung wert. Ein hoher CLS kann oft auf eine oder mehrere Änderungen des visuellen Layouts während des Seitenladens hinweisen, beispielsweise wenn Banner geladen werden, die den Seiteninhalt nach unten verschieben.

Aufschlüsselung der Geschwindigkeitsbewertung

Das Diagramm unten zeigt eine Aufschlüsselung der Gesamtgeschwindigkeitsbewertung und die große Rolle, die diese neuen CWV-Metriken bei den GPSI-Bewertungen spielen.

Quelldaten aus dem Lighthouse-Score-Update

Während auch Nicht-CWV-Metriken die Gesamtpunktzahl bilden, einschließlich First Content Paint (FCP), Time to Interactive (TTI) und Total Blocking Time (TBT), wird die Konzentration auf die drei CWV-Metriken einen direkten Einfluss auf die anderen haben. Ein schnelles LCP ist beispielsweise ohne schnelles FCP nicht möglich und hohe FID-Werte werden direkt von TBT und TTI beeinflusst.

Tipps für die größte Contentful Paint-Optimierung

Die LCP-Metrik setzt sich aus zahlreichen Einzelfaktoren zusammen und wird direkt von einem hohen FCP beeinflusst. Wenn der FCP als schlecht gekennzeichnet wird, sollten Sie hier beginnen. Alles von der Netzwerkkonnektivität, der Serverreaktionsfähigkeit, der Time To First Byte TTFB und Renderblocking-Dateien beeinflusst den FCP-Wert. Um einen tieferen Einblick in einige dieser allgemeineren Empfehlungen zur Seitengeschwindigkeit zu erhalten, lesen Sie zusätzlich zu den LCP-spezifischen Tipps unten unser eBook zur Seitengeschwindigkeit zu diesem Thema.

Wenn der LCP-Wert viel höher als der FCP-Wert ist, müssen wir uns überlegen, wie wir die Anzeige dieses größten Elements besser optimieren können.

Bestimme das größte Element

Das erste, was Sie wahrscheinlich tun möchten, ist das größte Element zu bestimmen. Das größte Element basiert auf der Pixelfläche, die sich an verschiedenen Breakpoints ändern kann, sodass ein visueller Scan möglicherweise nicht unbedingt das richtige Element identifiziert.

In PSI sollte es im Diagnosebereich ein Feld „Größtes Contentful Paint-Element“ geben. Alternativ können Sie das LCP anzeigen, indem Sie den Mauszeiger über den Indikator im Leistungsüberwachungstool von Chrome bewegen, wie unten gezeigt.

Auf der Hallam-Site im obigen Beispiel zeigt der Leistungsmonitor das LCP als Hauptüberschrift „Thrive Online“. Im Idealfall sollte LCP sofort auf FCP folgen, wie in diesem Beispiel, und wenn es eine Lücke zwischen den beiden gibt, müssen wir versuchen, die Gründe dafür zu verstehen.

Sind Schriftarten optimiert?

Wenn das größte Element oberhalb der Falte Typografie ist, müssen wir sicherstellen, dass die Schriftartenlieferung so optimiert wie möglich ist. Das beinhaltet:

1. Verwenden Sie die CSS-Schriftartanzeige: swap; um eine sofortige Anzeige der Schriftart zu gewährleisten, während die Schriftartdatei geladen wird. Sowohl Google Fonts als auch Typekit von Adobe haben die Möglichkeit, den Parameter „Display“ der Schriftart festzulegen.
2. Versuchen Sie, .woff- und .woff2-Schriftdateien lokal auf dem Server zu hosten, anstatt domänenübergreifende Anforderungen an Schriftarten von Drittanbietern zu stellen. Google Fonts ist ziemlich schnell, Typekit-Schriften sind langsamer und einige Schriftartenhersteller von Drittanbietern können weniger zuverlässig sein.
3. Das Vorladen von Schriftartendateien kann helfen. Lokal gehostete Schriftarten werden oft in das Haupt-Stylesheet der Website aufgenommen, aber dieses Stylesheet muss heruntergeladen und geparst werden, bevor eine zusätzliche Anfrage an die darin enthaltene Schriftart gestellt wird. Das Vorladen weist den Browser an, früher mit dem Herunterladen der Schriftart zu beginnen, ohne darauf zu warten, dass das CSS geparst wird.
4. Verwenden Sie Preconnect und DNS-Prefetch für Schriftartenhersteller von Drittanbietern. Diese Anweisungen helfen dabei, eine DNS-, TLS- und TCP-Verbindung zwischen Domänen von Drittanbietern aufzubauen, bevor die Anfrage an die Schriftarten gestellt wird.
5. Fügen Sie nur Schriftartdateien für Typografie hinzu, die für oberhalb des Faltdisplays erforderlich sind. Font-Assets für Symbolbibliotheken wie Font Awesome sind bekanntermaßen umfangreich, aber Anfragen an diese (und das entsprechende CSS der Symbolbibliothek) können normalerweise zurückgestellt und nach dem <head>-Element geladen werden.
6. Stellen Sie keine domänenübergreifenden Anforderungen an Schriftartdateien innerhalb des Stylesheets der Hauptwebsite, da dies auf Konnektivität und zusätzlichem Nachschlagen einer Drittanbieterdomäne angewiesen ist.
7. Ziehen Sie websichere Schriftarten in Betracht. Diese erfordern keine Anforderungen an Schriftartdateien, können jedoch in Bezug auf die Ästhetik sehr eingeschränkt sein.

Sind Bilder optimiert?

Sehr oft ist das größte über dem Falzelement ein Bild, das so wichtig ist, um sicherzustellen, dass die Bilder optimiert werden. Das Folgende ist allgemein bewährt, aber besonders wichtig für das LCP-Element.

1. Verwenden Sie den richtigen Bilddateityp. JPG-Bilder sollten für Fotos verwendet werden, SVGs für Vektorgrafiken und Symbole oder PNGs für komplexere, nicht-fotografische Bilder und wenn Transparenz erforderlich ist.
2. Stellen Sie sicher, dass JPG-Bilder mit einer Qualität von 50-60 % gespeichert oder ausgegeben werden. Auf dieser Ebene sollte kein Qualitätsverlust erkennbar sein. Stellen Sie außerdem sicher, dass von den Bildern Metadaten entfernt wurden.
3. Komprimierungs-Plugins oder Dienste wie tinypng.com können Bilder automatisch und massenhaft optimieren und unnötige Metadaten entfernen.
4. Die Bilder sollten eine angemessene Größe für den Bereich haben, in dem sie angezeigt werden. Geben Sie das hochwertige Desktop-Bild nicht auf Mobilgeräten aus.
5. Bilder sollten mit dem Standard-<img>-Tag mit dem 'srcset'-Attribut für responsive Bilder ausgegeben werden.
6. Unterhalb der Falt- oder Off-Screen-Bilder sollte das Attribut loading=”lazy” verwendet werden.
7. Verwenden Sie das .web-Bilddateiformat der nächsten Generation für noch bessere Komprimierungsraten. Damit lassen sich leicht 30% und in vielen Fällen noch viel mehr einsparen.
8. Ziehen Sie in Betracht, das größte Bild über dem Falten vorab zu laden, um den Download vor anderen, potenziell weniger kritischen Inhalten schneller zu starten.

Reduzieren Sie Renderblocking-Dateien

Jede JavaScript- oder CSS-Datei, die in das Element <head></head> geladen wird, gilt als Renderblocker, da diese Dateien heruntergeladen werden müssen, bevor die Seite mit dem Rendern beginnen kann. Dies kann einen großen Einfluss sowohl auf die FCP- als auch auf die LCP-Metrik haben. Renderblocking-Dateien im Kopf sollten nur verwendet werden, wenn sie für die initiale oberhalb der Faltung auf der Seite kritisch sind.

Das Entfernen nicht verwendeter Dateien im <head>, das Laden nicht kritischer Dateien in die Fußzeile oder das Kombinieren mehrerer Dateien in weniger Dateien reduziert die Menge der Rendering-blockierenden Assets.

Verwenden Sie kein JavaScript, um das LCP anzuzeigen

Vor CWV war das keine große Sache. Es ist üblich, dass JavaScript verwendet wird, um Elemente oberhalb der Falte zu animieren oder anzuzeigen, z. B. mit verblassendem Text oder Heldenkarussells, oft mit geringen bis gar keinen Auswirkungen auf die Geschwindigkeitsbewertungen.

Wenn die Anzeige des größten Elements auf JavaScript basiert, kann dies oft zu einer langen Verzögerung führen, da JavaScript heruntergeladen, geparst und ausgeführt werden muss, bevor das Element erscheint. JavaScript-Dateien werden normalerweise (und das zu Recht) nach dem <head>-Element geladen, sodass sie nicht "render-blocking" sind, aber das bedeutet, dass sie das Rendern des LCP immer noch effektiv blockieren können.

Schauen Sie sich das folgende Beispiel an (Logo verschwommen und Überschrift geändert). Dies stammt von einer ansonsten hoch bewerteten Site in PSI. Das LCP (der Hauptüberschriftstext) ist einige Sekunden weiter vom FCP entfernt, was durch die Anforderung von JavaScript (dargestellt durch die gelben Bänder) verursacht wird, herunterzuladen, zu analysieren und auszuführen, bevor der Text eingeblendet werden kann.

Das Einblenden des Textes an sich kann ebenfalls ein Problem sein, was zu einer verzögerten Anzeige des größten Elements führt.

JavaScript-Techniken wie diese können die Gesamtgeschwindigkeitsbewertung sofort um 25 % reduzieren und sollten nicht verwendet werden, um das Laden des größten Elements in irgendeiner Weise zu behindern oder zu verhindern.

Ausführen von Skripten beim Laden von Fenstern

JavaScript ist selten erforderlich (und sollte auch nicht erforderlich sein), um kritischen Inhalt oberhalb des Faltens anzuzeigen. Ein häufiges Problem besteht jedoch darin, dass Funktionen ausgelöst werden können, sobald das DOM bereit ist. Im beliebten jQuery-Framework geschieht dies über das 'ready'-Ereignis. Google Tag Manager kann auch Funktionen oder 'Tags' auf Ready auslösen.

Ziehen Sie in Erwägung, alle JavaScripts auszulösen, die für die kritische Anzeige von Inhalten beim Fensterladeereignis nicht erforderlich sind, nachdem der Inhalt der Hauptseite geladen wurde, um potenzielle Störungen beim Rendern von Inhalten oberhalb der Falte und des LCP-Elements zu verhindern.

LCP hochschalten

Unabhängig davon, wie gut optimiert und optimiert ein Bild ist, dauert das Herunterladen und Anzeigen fast immer länger als bei einem typografischen Element. Obwohl es durchaus möglich ist, schnelle LCP-Werte für Bilder zu erzielen, bedeutet manchmal eine Anpassung, das größte Bildelement zu verkleinern, sodass es kleiner als das größte Textelement ist, stattdessen Text für das LCP verwendet werden kann.

Dies kann einen großen Einfluss auf die Partituren haben, wenn das Design dies zulässt, wie im Beispiel unten gezeigt, in dem das LCP auf ein Textelement umgestellt wurde.

Tipps zur Optimierung der ersten Eingabeverzögerung

Wie bereits erwähnt, misst FID, wie schnell die Seite auf Benutzereingaben reagiert. Es kombiniert die Time To Interactive TTI und die Total Blocking Time TBT, die bis zu 35% der Gesamtgeschwindigkeitsbewertungen ausmachen können.

Diese Metriken werden hauptsächlich durch Skripts beeinflusst, die beim Laden der Seite geparst und ausgeführt werden. Blockieren des Hauptthreads der CPU und möglicherweise Auswirkungen auf die Reaktionsfähigkeit des Geräts, insbesondere bei Smartphones der unteren Preisklasse.

Es ist wichtig zu beachten, dass die im PSI angezeigten „Labordaten“ die FID nicht direkt messen. Dies liegt an der interaktiven Natur der Messung durch Tippen oder Klicken durch den Benutzer, die schwer zu simulieren ist. Stattdessen werden sie von 'Felddaten' gesammelt; Messungen von tatsächlichen Benutzern über einen Zeitraum von 28 Tagen basierend auf dem Chrome User Experience Report CrUX.

Daher ist die direkte Optimierung für FID etwas schwieriger, da wir nichts ändern und 28 Tage warten können, bis weitere Daten gesammelt werden. Wir sollten daher stattdessen die TTI- und TBT-Metriken in den Labordaten verwenden, da niedrige Zeiten für diese Metriken mit einem niedrigen FID korrelieren.

Wie also optimieren wir diese Metriken?

Überprüfen Sie Ihr JavaScript

JavaScript kann in allen Formen und Größen auftreten und es ist nicht ungewöhnlich, dass eine einzelne Videoeinbettung, ein Chat-Widget, ein ReCaptcha-Skript oder eine HubSpot-Integration der einzige Grund für die hohen FID-, TTI- und TBT-Metriken ist.

Die Diagnosefelder in Page Speed ​​Insights sind ein guter Ausgangspunkt. Der Abschnitt „Haupt-Thread-Arbeit minimieren“ zeigt Ihnen, wie viel Ausführungszeit von JavaScript beansprucht wird, der Abschnitt „Ausführungszeit von JavaScript reduzieren“ zeigt an, welche Dateien eine hohe Parsing- und Ausführungszeit haben und „Verringern Sie die Auswirkungen von Drittanbietern code' markiert und gruppiert hochwirksame Skripte von Drittanbietern.

Der Screenshot unten zeigt eine Site, die unter mehreren schweren Skripten leidet, mit einer Time to Interactive-Metrik von 15 Sekunden. Viele Skripte stammen von Drittanbietern, darunter HubSpot und Vimeo.

Für eine tiefere Analyse und Visualisierung, wie sich diese Skripte auf das Laden der Seite auswirken, kann das Performance-Monitor-Tool von Chrome eine gute Möglichkeit sein, um herauszufinden, welche Skripte und Funktionen ausgelöst werden, welche Auswirkungen diese Skripts haben und an welchem ​​Punkt des Seitenladevorgangs lange Skripte werden ausgeführt.

Das folgende Beispiel stammt von derselben Site und zeigt JavaScript, das durch die gelben, rosa und orangefarbenen Balken dargestellt wird, wobei längere Balken länger ausgeführte Aufgaben anzeigen. Wenn wir auf diese längeren Aufgaben klicken, können wir sehen, dass die hervorgehobenen Skripte mit den großen Skripten korrelieren, die von PSI oben hervorgehoben wurden.

Sobald wir ein besseres Bild davon haben, welche Skripte sich auf die Leistung auswirken, gibt es verschiedene Techniken, die wir verwenden können, um ihre Auswirkungen zu minimieren, wie unten beschrieben.

Skripte asynchron laden

JavaScript wird standardmäßig nacheinander ausgeführt. Wenn es Skripte gibt, die nicht vom Laden anderer Skripts abhängig sind, sollten diese Skripte mit dem 'async'-Attribut geladen werden, damit sie das Parsen und Ausführen anderer Skripts nicht blockieren.

JavaScript bedingt laden

Ein häufiges Problem, das wir auf vielen Websites sehen, ist, dass umfangreiche Skripte global oder auf Seiten geladen werden, wenn sie nicht benötigt werden. Wenn Sie ReCaptcha verwenden müssen, um beispielsweise Spam beim Senden von Formularen zu stoppen, stellen Sie sicher, dass Sie Skripte nur auf den Seiten laden, die Formulare enthalten.

Optimieren Sie JavaScript-Pakete

JavaScript-Bibliotheken wie jQuery UI oder Bootstrap werden häufig verwendet, um zusätzliche JavaScript-Features und -Funktionen bereitzustellen. Wenn Sie ein Bundle verwenden, stellen Sie sicher, dass nur die relevanten Funktionen in das Bundle aufgenommen werden, um unnötiges JavaScript vor dem Herunterladen und Analysieren zu bewahren.

Lazy-Load-Skripte bei Bedarf

Auch wenn JavaScript nur auf den Seiten geladen wird, auf denen es benötigt wird, muss das Skript selbst während des Seitenladens oder des Fensterladeereignisses nicht unbedingt geparst und ausgeführt werden. Das Laden von JavaScript nur dann, wenn es tatsächlich benötigt wird, kann die TTI-, TBT- und FID-Metriken massiv verändern. Hier sind einige Beispiele:

1. Videoeinbettungen wie YouTube und Vimeo sind in der Regel sehr wirkungsvoll. Ziehen Sie in Betracht, diese Skripts nur zu laden, wenn Sie stattdessen auf ein Video-Thumbnail klicken.
2. Formularintegrationen von Drittanbietern wie HubSpot können intensiv sein. Wenn das Formular in einem modalen oder am unteren Rand einer Seite angezeigt wird, ziehen Sie in Betracht, das erforderliche Skript beim Scrollen oder bei der modalen Aktivierung statt beim Laden der Seite zu laden oder einzufügen.
3. Live-Chat-Widgets können die Gesamtgeschwindigkeitsbewertung um bis zu 35 % beeinflussen. Ziehen Sie in Erwägung, das Live-Chat-Widget auf eine dedizierte Kontaktseite mit Unterstützung des globalen „Live-Chat“-CTAs zu verschieben oder das Live-Chat-Skript nur einzufügen, wenn auf die Schaltfläche „Mit uns chatten“ geklickt wird.
4. Das Hinzufügen des 'loading=”lazy”-Attributs zu eingebetteten iFrame-basierten Inhalten kann hilfreich sein, aber es ist eine neue Browserfunktion und muss abhängig von der verwendeten iFrame-Einbettung getestet werden.

Business-Intelligence-Tools bewerten

Die Analyse des Benutzerverhaltens mit Tools wie Hotjar oder A/B-Testing-Software wie VWO ist für Business Intelligence sehr wichtig und in vielen Fällen überwiegen die Vorteile die Auswirkungen auf die Website-Geschwindigkeit.

Trotzdem lohnt es sich zu bewerten, wie wichtig es ist, diese Tools rund um die Uhr auszuführen, je nachdem, wie häufig Daten analysiert werden. A/B-Tests sollten ausgeschaltet werden, wenn beispielsweise keine aktiven Tests laufen und Verhaltensanalysetools wie Hotjar deaktiviert werden können, nachdem genügend Daten gesammelt und verarbeitet wurden.

Tipps zur Optimierung der kumulativen Layoutverschiebung

Die kumulative Layoutverschiebung (CLS) macht möglicherweise nur 5 % der Gesamtgeschwindigkeitsbewertungen aus, aber dennoch ein wichtiger Teil des Gesamtbilds, insbesondere da eine hohe Anzahl von Elementen beim Laden der Seite eine erschütternde Erfahrung für den Benutzer sein kann.

CLS-Element ermitteln

Manchmal mag es offensichtlich erscheinen, welches Element oder welche Elemente eine Verschiebung des Inhalts verursachen, aber es lohnt sich immer, dies über das Bedienfeld „Layoutverschiebung“ in PSI zu überprüfen, wie unten gezeigt.

Die CLS-Metrik sollte unter 0,1 liegen, aber im obigen Beispiel wird dies um über 400 % überschritten und führt zu einem Rückgang der Punktzahlen um 5 %. Wenn es sich um ein globales Problem handelt, sind das 5 % auf jeder Seite.

Sich verschiebende Elemente sollten in der Reihenfolge ihrer Auswirkungen identifiziert und behandelt werden und können Elemente oberhalb und unterhalb der Falte umfassen. Im Folgenden haben wir einige der häufigsten Ursachen und Lösungen für Layoutverschiebungen hervorgehoben.

Achten Sie auf Animationen

Es ist durchaus üblich, dass bestimmte Animationstechniken verwendet werden, um die Art und Weise zu ändern, wie Inhalte dem Benutzer präsentiert werden, beispielsweise durch Einblenden oder Einblenden von Bildern, Text oder Inhaltsfeldern, während der Benutzer eine Seite nach unten scrollt. Während diese ästhetisch ansprechend sein können (je nachdem, wen Sie fragen), ist es wichtig, dass diese Techniken beim Laden der Seite keine Inhalte verschieben.

Wenn Sie Inhalte ausblenden und dann für den Benutzer einblenden müssen, stellen Sie sicher, dass sich die Containergröße oder die Gesamtseitenhöhe beim Laden des Inhalts nicht ändert. Der Inhalt kann (falls erforderlich) mithilfe von CSS-Sichtbarkeitsregeln ausgeblendet werden, anstatt anzuzeigen: none; wodurch die zugrunde liegende Menge an benötigtem Speicherplatz erhalten bleibt.

Bildabmessungen angeben

Wenn für das <img>-Tag kein width- und height-Attribut festgelegt ist oder CSS nicht verwendet wird, um die Abmessungen oder das Seitenverhältnis des Bildes festzulegen, müssen Browser das Bild zuerst herunterladen, bevor sie den benötigten Pixelbereich bestimmen können Anzeige in. Dies kann dazu führen, dass der unter dem Bild gerenderte Inhalt verschoben wird, wenn das Bild geladen wird.

Wenn Sie die Breite und Höhe des Bildes angeben oder die Abmessungen oder das Verhältnis des Bildes (oder des übergeordneten Containers) in CSS vor dem Herunterladen des Bildes festlegen, wird sichergestellt, dass Browser den Bereich kennen, in dem das Bild angezeigt werden muss, und mögliches Layout vermieden werden Verschiebung.

Banner

Werbung, Cookie-Rechtssperren oder andere Informationen, die verwendet werden, um wichtige Informationen in einem Banner anzuzeigen, sind wahrscheinlich eine der häufigsten Ursachen für einen hohen CLS.

Es ist üblich, dass Bannerinhalte von einer externen Datenquelle oder über JavaScript von derselben Site geladen werden, was bedeutet, dass die Größe des Bannercontainers möglicherweise erst berechnet werden kann, wenn der Inhalt geladen wurde. In diesem Fall wird der Inhalt unter dem Banner nach unten verschoben, sobald der Bannerinhalt geladen und dem Benutzer angezeigt wird.

Dazu gibt es mehrere Auflösungen:

1. Legen Sie in CSS eine Mindesthöhe für das Banner oder den Banner-Container fest, damit der Browser einen Platzhalter effektiv rendern kann. Dies kann jedoch problematisch sein, wenn die Menge an Inhalten dynamisch und unbekannt ist.
2. Absolut oder fixieren Sie die Position des Banners am oberen oder unteren Bildschirmrand. Bei Bannern, die geschlossen oder geschlossen werden können, ist dies eine gute Überlegung, da feste Elemente die Positionierung anderer Elemente nicht beeinflussen.
3. Betrachten Sie nach Möglichkeit das serverseitige Rendering von Bannerinhalten, was bedeutet, dass Inhalte und Bannerabmessungen im Voraus geladen werden können, bevor sie den Benutzer erreichen.

Zusammenfassung

Hoffentlich finden Sie einige der oben genannten Techniken hilfreich bei der Diagnose und Behebung von Leistungsproblemen rund um die neuen Core Web Vitals von Google. In den letzten Monaten haben wir bei Hallam einer Reihe von Kunden geholfen, die Leistung ihrer Website zu verbessern, sowohl in Bezug auf unsere Geschwindigkeitsprüfungen als auch auf direkte Verbesserungen durch unser Entwicklungsteam.

Wenn Sie diesen Artikel hilfreich fanden, sollten Sie auch unser eBook zur Website-Performance lesen, das einen tieferen Einblick in einige der allgemeineren Empfehlungen zur Seitengeschwindigkeit gibt, von denen jeder profitieren kann, der eine Website erstellt oder verwaltet.