Im vorherigen Artikel zur den Google Core Web Vitals Werten habe ich gezeigt, was das genau ist und warum diese Kennzahlen wichtig sind. Heute gehe ich nun in die Praxis und analysiere zwei eigene Blog dahingehend und versuche eine Optimierung dieser wichtigen Werte vorzunehmen.
Dabei zeige ich, welche Tools ich dafür verwende, welche Änderungen ich vornehme und was da am Ende ggf. schon gebracht hat.
Zudem gehe ich darauf ein, warum es auch hier keine gute Idee ist alles blind zu optimieren, was Google ggf. als Fehler anzeigt.
Optimierung der Google Core Web Vitals Werte
Wie im ersten Artikel über die Google Core Web Vitals geschrieben gibt es 3 Werte, die Google mittlerweile zusätzlich analysiert, um einzuschätzen, wie gut eine Website für die Nutzer optimiert ist. Auch wenn es sich bei den Werten um relativ technische Aspekte handelt, wirken sich diese doch sehr auf die Nutzungserfahrung aus.
Neben dem Largest Contentful Paint (die Ladezeit des größten Inhaltselements) und dem First Input Delay (Dauer bis zur ersten Interaktion durch den Nutzer) ist zumindest bei meinen Blogs und Websites vor allem der Cumulative Layout Shift (Designelemente, die sich während oder nach dem Laden der Website noch ändern) ein Problem.
Zumindest zeigt mir die Google Search Console genau das Problem bei einigen Projekten an, während die anderen bei mir so gut wie keine Rolle spielen.
In diesem Artikel optimiere ich 2 größere Blogs von mir, denn zumindest bei mir scheinen die kleineren Websites oft keine Probleme mit den Gooogle Core Web Vitals zu haben. Teilweise gibt es aber auch anscheinend zu wenige Daten bzgl. der Core Web Vitals bei kleinen Websites und die Analyse bleibt hier in der Search Console leer.
Selbständig im Netz Optimierung
Mein immer noch größter Blog ist insgesamt recht gut optimiert und zeigt gute Performance-Werte. Schaue ich mir hier die Google Core Web Vitals an, dann zeigt sich, dass zumindest die Desktop-Version meines Blogs ein kleines Problem hat.
In dem folgenden Screenshot sieht man, dass die mobile Version insgesamt okay ist. Es gibt hin und wieder mal ein Problem mit dem First Input Delay (FID), aber da scheint der Messwert knapp unter der Grenze von 100 ms zu liegen und je nach aktuellen Messwerten mal leicht darüber zu sein.
Die Computer-Version meines Blogs ist allerdings durchgehend rot und das bedeutet Handlungsbedarf. Hier wir für alle Seiten des Blogs ein CLS-Fehler gemeldet. Dieser liegt hier über 0,25, was bedeutet, dass dies auf jeden Fall optimiert werden sollte.
Mit dem Cumulative Layout Shift ist das Problem gemeint, dass sich das Layout während des Ladevorgangs oder danach noch verändert. Das kennt man von vielen Websites, wo man was anklicken will, sich dann aber noch ein Banner öffnet oder ein anderes Element und man klickt dann auf das falsche.
Welche Elemente sich nach dem Laden noch verändern, kann man zum einen herausfinden, in dem man einfach mal genauer hinschaut. Welche Elemente verändern sich nach dem Laden noch. Am PC ist aber durch DSL meist schlecht erkennbar, da es sehr schnell geht.
Bei meinem Blog gab es in der Vergangenheit vor allem mit der mitscrollenden Navigation Probleme. Die Hauptnavigation wurde beim Herunterscrollen einer Seite oben mit angezeigt und scrollte mit. Das ist für die Nutzer eine nützliche Sache, wie ich finde, aber Google definierte es als Problem. Ich habe diese mitscrollende Nav. deshalb vor einer Weile deaktiviert.
Richtig analysieren kann man CLS-Probleme mit den Google Chrome Entwickler-Tools, die man unter den drei Punkten oben rechts und dort dann bei “Weitere Tools > Entwicklertools” findet. Dann geht man auf “Elements” und dann weiter unten auf “Rendering”. Dort kann man einen Haken bei “Layout Shift Regions” klicken.
Lädt man die Seite dann neu, werden CLS-Regionen blau hinterlegt angezeigt. Bei meinem Blog Selbständig im Netz wurde der komplette innere Content-Teil samt Header blau markiert. Das war schon komisch, zumal ich die mitscrollende Navigation, wie schon gesagt, vor einer Weile deaktiviert habe. Daran scheint es also nicht zu liegen.
Um Veränderung am Layout noch besser zu erkennen, drosselt man die Internet-Geschwindigkeit am besten künstlich. Das ist in den Entwicklertools unter “Network” möglich, wo man “Fast 3G” auswählt.
Zu guter Letzt startet man die Aufnahme der Screenshots während des Ladens durch einen Klick auf den Kreispfeil-Button unter “Performance”. Dadurch wird die Seite neu geladen und es werden Screenshots gemacht:
Hier zeigt sich ein Problem, nämlich bei der Navigation. Ich nutze einen lokal auf dem Server gespeicherten Google Font für die Navigation, der bei der normalen Nutzung schnell geladen wird, aber bei langsameren Internet ein Problem ist. Denn zuerst werden die Navigations-Punkte in einer anderen Schrittart (Arial) angezeigt.
Nach einer Weile, wenn dann der Google Font komplett geladen wurde, verändert sich die Schrift der Navigation dann so, wie sie sein soll. Das führt in meinem Fall dazu, dass die Nav. erstmal zweizeilig wird, bevor der schmalere Google Font dann die Nav. korrekt anzeigt.
Ich habe hier einige Dinge ausprobiert und immer wieder mit den Entwickler-Tools von Chrome getestet, was das bewirkt.
Ich habe im Header einen Preload-Befehl eingebaut, der meinen Google Font in den verschiedenen Versionen vorlädt. Hier ein Beispiel:
<link rel="preload" as="font" href="/fonts/fjalla-one-v5-latin-regular.woff2" type="font/woff2" crossorigin="anonymous">
Zudem habe ich im CSS-Befehl für das Laden des lokalen Google-Fonts noch den Befehl
font-display: block;
eingebaut. Das sorgt dafür, dass der Text im Browser erst dann angezeigt wird, wenn der dafür vorgesehene Font wirklich geladen wurde. Andernfalls wird eben erstmal Arial genutzt und der Text angezeigt, bevor es dann einen Wechsel auf den richtigen Font gibt. Das ist ein häufiger Grund für CLS-Fehler.
Das Ergebnis ist, dass das Tool nach einem CLS-Wert von 0,355 danach keine CLS-Fehler mehr feststellt.
Auch die Screenshots aus dem Chrome Entwicklertools Test sehen besser aus. Hier wird keine Veränderung der Navigation mehr angezeigt:
Damit sollte auf Selbstständig im Netz das CLS-Problem behoben worden sein.
Abenteuer Brettspiele Optimierung
Auf Abenteuer-Brettspiele.de gibt es bei der mobile Version zu optimierende Elemente bzgl. CLS (orange), während die Desktop-Version kritische CLS-Fehler (rot) anzeigt.
Auch hier habe ich mir im Chrome angeschaut, wo das Problem liegen kann und welche Elemente blau markiert werden.
Zum einen ist es der Header, der sich zwar von der Größe her nicht verändert beim Scrollen, aber das Hintergrundbild im Header verschiebt sich beim Scrollen, was ein hübscher Effekt ist, aber Google wohl stört. Ich habe diesen Effekt deaktiviert, indem ich den JavaScript-Code dafür entfernt habe.
Zudem habe ich hier eine mitscrollende Hauptnavigation, die ebenfalls ein netter Effekt ist, aber Google wohl ebenfalls nicht gefällt. Ich habe die mitscrollende Navigation deshalb raus genommen, indem ich das Plugin myStickymenu deaktiviert habe.
Ebenfalls fällt auf, dass beim Herunterscrollen der Content ebenfalls komplett blau angezeigt wird. Hier habe ich als Ursache die Lazy Load Einstellung des Plugins a3 Lazy Load ausgemacht, die dafür sorgt, dass Bilder nachgeladen werden, wobei der Platzhalter beim Laden aber größer als das Bild selbst ist. Das sorgt für einen Cumulative Layout Shift im gesamten Content.
Da WordPress Lazy Loading nun aber auch von Hause mitbringt, habe ich das Plugin ebenfalls deaktiviert.
Die Google Search Console zeigt bei den Core Web Vitals der Computer-Ansicht nach der Optimierung nun schon eine Verbesserung, aber ich werde hier noch weiter daran arbeiten.
Performance vs. Nutzungserlebnis
Die Core Web Vitals wurden von Google natürlich nicht ohne Grund mit in die Website Analyse der Search Console und damit auch in die Rankings aufgenommen. Zu lange Ladezeiten, “springende” Website-Elemente und so weiter nerven einfach und sollten deshalb behoben werden.
Doch wie immer bei Optimierungen (ähnlich wie bei SEO) stellt sich auch hier die Frage, wie sehr sollte man die Werte optimieren und sollte man nur auf die Zahlen schauen. Nicht alles, was Google als Problem bzgl. der Core Web Vitals anzeigt, ist meiner Meinung nach wirklich ein Problem.
So ist der leicht scollende Hintergrund im Header meines Brettspiel-Blogs und auch die mitscrollende Hauptnavigation ja kein Fehler oder stört. Im Gegenteil, die Hauptnavigation immer nutzen zu können, wissen sicher viele Nutzer zu schätzen.
Ich habe diese Dinge zwar nun erstmal rausgenommen, bin mir allerdings nicht sicher, ob das auf Dauer so bleibt. Ich werde die Core Web Vitals Beurteilung in der Search Console weiter beobachten und schauen, was die Auswirkungen meiner Optimierung sind. Zudem werde ich beobachten, welche Auswirkungen auf die Seitenaufrufe etc. die Entfernung der mitscrollenden Nav. hat. Ich würde nicht ausschließen, dass ich diese später wieder aktiviere.
Andere Probleme, wie der Font-Wechsel in der Hauptnavigation von Selbständig im Netz, müssen aber behoben werden, da das einfach nervige Webdesign-Fehler sind. Dabei zeigt sich, dass es natürlich interessant ist, wenn man das eigene Theme anpasst, also z.B. die Fonts manuell ändert. Allerdings kann das eben Auswirkungen auf das Webdesign haben, mit denen man nicht rechnet.
Wer also CSS und HTML nicht wirklich gut beherrscht, der sollte sich lieber ein Theme suchen, welches den eigenen Vorstellungen schon sehr gut entspricht und wo Layout-Änderungen durch vorhandene Einstellungen im Backend möglich sind. Zudem sollte das Theme natürlich auch beim Test bzgl. der Google Core Web Vitals gut abschneiden.
Ich werde nun nach und nach meine weiteren Blogs und Websites dahingehend analysieren und schauen, welche Probleme es dort vor allem hinsichtlich des Cumulative Layout Shift und der anderen Core Web Vitals Werte gibt.
Fazit
Eine Website schön und schnell zu machen reicht heute nicht mehr aus. Google analysiert immer stärker, wie Websites bei den Nutzern ankommen und welche Probleme es bei der Benutzung ggf. gibt.
Die Google Core Web Vitals sind sehr hilfreiche Werte, die auf grundsätzliche Probleme bei Websites hinweisen und wie man vor allem an meiner Optimierung dieses Blogs hier sieht, gab es da ein paar Probleme, auf die ich ohne die Google-Werte wohl nicht aufmerksam geworden wäre.
Habt ihr euch die Google Core Web Vitals eurer Website schon mal angeschaut und gibt es da Probleme?
Und wenn ja, wie habt ihr diese behoben?
Wer wir sind und wie wir arbeiten. In unserem Büro im Zentrum von Köln arbeiten ausgebildete Redakteur/innen an der Ausarbeitung erstklassiger Inhalte, auf die du dich verlassen kannst. Sämtliche Artikel werden nach dem Vier-Augen-Prinzip publiziert: Nach Fertigstellung der Rohfassung werden die Texte von (mindestens) einem/r anderen Redakteur/in auf orthografische und inhaltliche Richtigkeit hin überprüft.
Diese Seite ist ein Angebot der 4pub GmbH mit Sitz in Köln. Wir haben uns auf den Betrieb hochwertiger redaktioneller Online-Portale spezialisiert und berichten stets redaktionell unabhängig.
- Danke für 16 tolle Jahre - 13. Juli 2023
- So erstellst du deine erste Newsletter-Mail in 10 Schritten mit CleverReach - 13. Juli 2023
- Die 5 besten Features des Amazon Affiliate WordPress Plugin – AAWP - 12. Juli 2023
Hallo Peer, ich habe auch das Problem mit dem “Layout Shift”. Der Hintergrund bei mir ist, dass Werbung über Apis geladen wird und die Bilder dort leider keine Größenangaben mit bekommen. Als Minderung behelfe ich mir mit einer CSS min-height Angabe. Mehr kann ich da leider nicht machen.
Grundsätzlich fällt mir nun auch auf, dass ich in der letzten Zeit zu nachlässig mit dem manuellen Integrieren von Bildern war. Aus Bequemlichkeit (CSS skaliert sie schon richtig) hatte ich auf je individuelle Größenangaben verzichtet.
Warum behältst du eigentlich einen speziellen Webfont? Ich hätte bzw. habe so etwas schon vor längerer Zeit rausgeworfen, um auf bessere Geschwindigkeiten zu kommen. Arial oder Verdana reicht doch.
Das ist natürlich immer ein Abwägen. Aus Performance-Gründen wären es ohne Webfont schneller, aber Wiedererkennungswert und Design spielen ja auch eine Rolle. Und so lange dadurch keine großen Probleme bzgl. der Performance entstehen, nutze ich diese dann doch gern. Mache ich ja auch vielen Websites.
Arial und Verdana sind nicht mehr Web Safe. Mobil werden sie unter Android meist mit Roboto ersetzt bzw. haben dort den entsprechenden Alias bekommen. Gerade bei Verdana ist das heikel, da sie spezielle Höhen und Breiten besitzt und ein Austausch unangenehme »Verschiebungen« nach sich zieht.
Ich habe mich aus Performancegründen von Webfonts verabschiedet. Es gibt ja auch schöne Standardfonts und ich mag das schnelle laden, da ich auch alle Seiten ohne CMS wie WordPress mache sondern selbst programmiere. Die Images lade ich allerdings mit lazyloading.
Stimmt. Vor allem gibt es in CSS inzwischen die System Font Stacks, sodass immer die jeweilige Systemschriftart verwendet wird. Nur der Wiedererkennungswert leidet.
Hallo Peer, danke für deinen Artikel. Ich habe heute intensiv an meinem CLS-Wert gearbeitet. Nach etlichen Jahren mit Webfonts, habe ich mich heute davon verabschiedet. Somit kam ich von CLS 0,35 auf 0,00. Egal was ich mit Webfonts versuchte, es hat nichts genützt.
Moin Peer4,
kurze Frage. Ich beschäftige mich mit dem Thema noch nicht lange und bin auch eher Anfänger. Meine GSC zeigt mir unter Mobil alle Webseiten grün als gute URLs an. Unter Computer wird mir allerdings keine einzige URL angezeigt, also der Graph ist eine Flatline auf 0. Was kann da falsch laufen?
Gruß,
Ralf
Das kann daran liegen, dass es noch zu wenige Daten dafür gibt. NBei eher neueren kleinen Websites von mir, die zudem vor allem mobil aufgerufen werden, war das auch so. Mit der Zeit sollten dort aber auch Daten zu sehen sein.
Hallo Peer,
ein bereichernder Blog, den du betreibst.
Ich habe ein Problem welches echt seltsam ist.
Vielleicht hast du eine Idee:
Meine Seite hatte bis zum 9. Nov 106 gute URLs.
Am gleichen Tag zeigte mir die Grafik plötzlich 77 zu optimierende URLs an.
Gut ich habe dann an der Seite gearbeitet und die Werte unter die von Google gewollten Werte bekommen.
Abschließend habe ich die Seiten überprüfen lassen und alles wurde für gut befunden – keine Fehler oder Verbesserungshinweise mehr.
Die gelben zu optimierenden URLs waren nun verschwunden.
Obwohl alles ok ist werden nun keine guten URLs angezeigt.
Ich warte nun schon seit Anfang Dez. auf eine Veränderung der Grafik, doch es bleibt bei Null gute-, schlechte- und zu optimierende URLs.
Ich weiß nicht warum nun keine guten URLs angezeigt werden.
Ich glaube die Seite ist auch im Ranking deswegen stark abgerutscht.
Die Webseite existiert übrigens schon länger als 15 Jahre und ist nicht neu.
Über einen Tipp würde ich mich freuen.
Schönen Tag noch 🙂
Grüße
Uwe
Immer mal wieder gibt es auch in der Google Search Console Updates und das kann dazu führen, dass auf einmal viele URLs als problematisch angezeigt werden.
Wenn keine Seiten angezeigt werden, dann liegt es laut Google ja in der Regel daran, das zu wenig Aufrufe existieren. Es gibt also nicht genug Daten, um die Seiten zu bewerten.
Wie viele Aufrufe hat denn deine Website ca. im Monat?
Danke für deine Antwort Peer,
zu wenige Klicks, hmm, wegen der Pandemie kann das sein, es geht ja um touristische Aktivitäten. Von der Google Search Konsole habe ich diese Info bekommen:
527 Klicks (Web) und 26,6K Impressionen (Web).
Über My Business haben fast 6000 mein Unternehmen angesehen.
Ich habe mir nur Sorgen gemacht weil die Jahre vorher immer durchweg was angezeigt wurde.
Parallel dazu will Bing absolut meine Seite nicht crawlen, deshalb dachte ich da ist etwas Faul.
Nochmals Danke und viel Freude bei deinem Blog.
Grüße
Uwe
Bei meiner Tourismus-Website sind die Besucherzahlen auch eingebrochen:
https://www.trending.de/affiliate-websites/corona-auswirkungen-auf-affiliate-websites-beispiele-traffic-einnahmen-und-mehr/1006399/
Ich denke mal, dass es daran liegt, dass derzeit keine Daten in der Search Console angezeigt werden.
Hallo Peer,
wiedermal vielen Dank für deinen ausführliche Erklärung zum Finden von CLS Problemen mit Hilfe des Entwicklertools. Ich war zuerst vergeblich auf diversen englischsprachigen Seiten unterwegs und konnte keine Lösung finden. Zum Schluss bin ich dann, wie immer, bei dir auf dem Blog gelandet.
Bei mir war das CLS Problem durch das Laden von FontAwesome entstanden (ein Drop-Down Pfeil im Hauptmenü).
Herzliche Grüße und alles Gute
Michael
Aktuell haben wir das Problem auch, da wir das CSS ladeoptimiert in 2 Batchen laden haben wir auch einen CLS-Fehler mit mehr als 0,25. Der Pagespeed nimmt dadurch ab wenn man viele Dinge vorab laden muss.
Unser Beispiel: wedot.ch