So optimieren Sie das Page Experience Update auf Unternehmensebene (internationale Fallstudie)

SEO in seiner Gesamtheit ist ein riesiges Thema, ganz zu schweigen vom technischen Aspekt.

In den letzten Monaten war es schwierig, im Bereich der technischen SEO umherzuwandern, ohne das Google Page Experience Update und die Core Web Vitals zu berühren oder davon zu hören.

Sie fragen sich vielleicht, was es ist und wie es sich auf Sie auswirkt, oder haben Zweifel, wie Sie damit arbeiten können, um Ihre Website zu optimieren – und das aus guten Gründen!

Das Ziel ist es, Ihnen die notwendigen Inputs in Form einer Fallstudie zu geben, die Sie in den letzten Tagen vor dem „Launch“ auf Ihrer eigenen Website (oder der eines Kunden) verwenden können.

Aber wir müssen kriechen, bevor wir gehen, also fangen wir mit den Grundlagen an.

Was ist CWV und warum wird es repariert?

Core Web Vitals ist eine Reihe spezifischer Metriken, die Google verwendet, um die Benutzererfahrung einer Website zu bewerten.
Die Absicht besteht darin, diese Metriken zu verwenden, um zu bewerten, wie eine Website in Bezug auf ihren Inhalt eingestuft wird, und um eine zufriedenstellende Benutzererfahrung sicherzustellen.

Das ist so, als würde ein echter Benutzer entscheiden, eine langsam ladende Website oder eine mit einer herausfordernden Benutzeroberfläche zu verlassen, egal wie gut der Inhalt ist.

Core Web Vitals besteht aus drei spezifischen Seitengeschwindigkeitsschätzungen und Benutzerinteraktionswerten:

1. Größte zufriedene Farbe
2. Erste Eingangsverzögerung
3. Kumulative Layoutverschiebung

Die Werte werden einzeln auf Desktop und Mobilgerät ausgewertet, um die Erfahrung auf verschiedenen Darstellungsbereichen und Netzwerkadaptern zu berücksichtigen.

LCP (Largest Contentful Paint) – Ladeerfahrung

LCP drückt aus, wie lange es dauert, bis die meisten Inhalte einer Website auf dem Bildschirm des Benutzers verfügbar (gerendert) sind.

Wenn Core Web Vitals der Ansicht ist, dass eine Optimierung für diesen Parameter verfügbar ist, basiert sie häufig auf den Front-End-Dateien (HTML, CSS, Bilddateien).

Das liegt daran, dass zu viele Dateien erforderlich sind, um die Site im Browser des Benutzers darzustellen. Es kann auch sein, dass die Dateien zu groß sind oder dass der Server nicht genügend Kapazität hat, um sie rechtzeitig auszuliefern.

Eine vorgeschlagene Lösung kann darin bestehen, sicherzustellen, dass diese Dateien kleiner sind, über weniger HTTP-Anforderungen gesendet werden und den Server so zu skalieren, dass er dem Datenverkehr und der Größe der Website entspricht.

FID (First Input Delay) – Interaktivität

FID drückt aus, wie lange es dauert, bis ein Benutzer mit dem Drücken von Site-Schaltflächen, Berührungen des Touchscreens, Tastatureingaben usw. interagieren kann.

Probleme in dieser Kategorie werden oft durch die Menge an Interaktion und DOM-Rendering verursacht, das dynamisch ist oder auf Javascript basiert.

Der Browser priorisierte das Laden dieser Skripte und akzeptierte vor dem Laden keine Benutzerinteraktion. Je schwieriger es ist, diese Skripte zu laden und auszuführen, desto länger dauert es, bis Sie mit der Website interagieren.

FID wird theoretisch verbessert, indem die Zeit zwischen der angezeigten Seite verkürzt wird, bis sie eine Interaktion ermöglicht. Mit anderen Worten, es ist möglich, Ihre JavaScript-Dateien bei Bedarf in kleinere Teile aufzuteilen.

Auf diese Weise können Sie das Laden der wesentlichen Elemente für die Nutzung der Website (Klicks, Taps, Slider-Interaktionen usw.) priorisieren – Animationen, Effekte und andere außergewöhnliche Funktionen müssen sekundär geladen werden.

Praktisch wird FID als individuelle Benutzermetrik gemessen – es misst nicht die Zeit, bevor ein Benutzer damit interagieren kann, sondern die Zeit, bevor ein Benutzer damit interagiert. Eine hohe Punktzahl bei dieser Metrik ist möglich, wenn der Nutzer z. B. durch Ladeanimationen oder Platzhalter für große Datensätze Informationen erhält, dass die Seite nicht verfügbar ist.

CLS (kumulative Layoutverschiebung)

CLS gibt an, ob die Website neue Schaltflächen, Texte oder Bilder nach anderen Inhaltselementen auf einer Website platziert – wenn die Website Elemente asynchron lädt, kann dies die Struktur des ursprünglichen Layouts verändern und das Benutzererlebnis erheblich stören.

Nicht optimierte Bilddateien verursachen häufig dies oder mögliche Webfonts, die nicht vorab geladen werden können und angezeigt werden, nachdem das anfängliche Markup vorhanden ist. Eingebaute Widgets von Drittanbietern können ebenfalls zu einer Verschiebung des Layouts führen.

Die Lösung besteht oft darin, den Inhalt vorab zu laden. Auf diese Weise sind Elemente vorhanden, die das Layout verschieben können, bevor die Seite zum ersten Mal angezeigt wird.

Alternativ können Sie verschlossene Container für Ihre Inhalte verwenden. Auf diese Weise ändert sich die Platzierung des ursprünglichen Inhalts nicht, wenn einige Elemente angezeigt werden.

[Fallstudie] Erhöhen Sie das Crawl-Budget auf strategischen Seiten

Der größte Teil des Traffics von Manageo stammt aus der organischen Suche. Dieser Traffic beruht hauptsächlich auf Long-Tail-Suchen, wodurch die Notwendigkeit entsteht, für Millionen von Schlüsselwörtern gleichzeitig zu optimieren. Das Crawl-Budget wurde schnell zu einem Problem.

Lesen Sie die Fallstudie

Zeit zu gehen

Nachdem wir uns nun um die Grundlagen gekümmert haben, ist es an der Zeit, es anzuwenden, und genau das haben wir mit einem Kundenfall getan.

Dieser spezielle Fall hat Spaß gemacht, weil er verschiedene Fehlertypen hatte und sich daher auf verschiedene Bereiche der Optimierung konzentriert.

Es gibt viele Schwerpunkte und Aktionspunkte, die im gesamten Koffer zu beachten sind – also schnallen Sie sich an und genießen Sie die Reise.

Ich begleite Sie durch:

• Der Fall
• Was wir in dem Fall gemacht haben
• Warum wir so gehandelt haben
• Die zentralen Thesen

Der Fall: Logpoint; internationales Cybersicherheitsgeschäft

Die Website Logpoint.com arbeitet im Bereich Cybersicherheit und ist eine weltweit bekannte Marke.

Da es sich um ein großes internationales Unternehmen handelt, läuft ziemlich viel Verkehr über die Website. Daher ist es wichtig sicherzustellen, dass die Besucher die bestmögliche Erfahrung machen – und daher ein noch fortschrittlicherer Fall für die Core Web Vitals.

Die Benutzererfahrung setzt sich aus vielen verschiedenen Faktoren zusammen, aber insbesondere Core Web Vitals spielen eine herausragende Rolle bei der Gestaltung und Messung der Erfahrung als Ganzes.

Das obige Bild zeigt die Situation vor Beginn unserer Optimierung von Core Web Vitals. Die Ausgangslage für Logpoint war im Vergleich zu vielen anderen bekannteren Unternehmen nicht so schlecht, aber wie die Grafik zeigt, gibt es Raum für Verbesserungen.

Das kann auch etwas sein, mit dem Sie sich identifizieren können.

Es ist entscheidend darauf zu achten, dass jede mögliche URL in die Kategorie „gute URL“ fällt, weil sie zur besten User Experience führt und weil Google Core Web Vitals Mitte Juni 2021 mit seinem Update zu einem Rankingfaktor macht: Google Page Erfahrung.

Was wir in dem Fall gemacht haben

Während unserer Optimierung hat sich die gesamte Situation von Core Web Vitals stark verändert. Als wir anfingen, waren die Hauptprobleme LCP- und CLS-Probleme sowohl im Mobil- als auch im Desktop-Format – und natürlich die Seitengeschwindigkeit.

Die Welt ändert sich und Websites auch – wenn Sie also vor einem halben Jahr für CWV optimiert haben, sieht es jetzt vielleicht anders aus.

Google Search Console (Core Web Vitals)

Als erstes haben wir uns mit den verschiedenen Fehlertypen befasst und herausgefunden, welche URLs betroffen waren. Wie Sie vielleicht bereits wissen, bietet die Google Search Console und ihre Registerkarte „Core Web Vitals“ einen Überblick über das mobile und das Desktop-Format.

Geht man einen Schritt weiter in die Berichte der Formate, erscheint eine Übersicht der Fehlerarten, wo man bei einem bestimmten Fehler noch weiter gehen kann.

Von der Übersicht aus ist es möglich, einen letzten Schritt weiter zu gehen, und von hier aus begann unsere Arbeit.

Jede URL, die von dem Fehlertyp betroffen ist, wird in diesem speziellen Schritt angezeigt, sodass Sie mit unserer Analyse beginnen können.

PageSpeed-Einblicke

Nachdem wir wussten, welche URLs betroffen waren, bestand unser nächster Schritt darin, sie zu analysieren, um die Elemente zu lokalisieren, die die Fehler verursachten. Hier kommt PageSpeed ​​Insights ins Spiel. Durch die Analyse der URLs haben wir den PageSpeed ​​Health Score verstanden, konnten uns aber auch die Elemente ansehen, die zu den Fehlern beigetragen haben.

Chrome DevTool – Leistungsanalyse

Um die Fehlertypen und Elemente, die sie verursachen, klar zu machen, haben wir die Leistungsanalyse im DevTool verwendet. Durch den Vergleich dieses Tools mit PageSpeed ​​Insights und den Core Web Vitals-Berichten haben wir sichergestellt, dass wir einen umfassenderen Überblick über die Erkenntnisse erhalten, die durch die verschiedenen Mittel bereitgestellt werden, und wie sie zueinander in Beziehung stehen.

Jedes Tool allein bietet eine einzigartige Perspektive auf die Details, die wiederum das größere Ganze schaffen.

Sobald die Profilerstellung abgeschlossen war, erschien im Abschnitt „Erfahrung“ eine Reihe roter Kästchen . Diese zeigten eine Elementladung an, die das Layout irgendwie veränderte, indem sie sich selbst bewegte oder benachbarte Elemente herumschob.

Durch Klicken auf ein Element werden hilfreiche Informationen angezeigt:

• Punktzahl
  Dieser Wert gibt an, wie viele Punkte dieses bestimmte Element oder Ladeereignis bei der Berechnung des kumulierten CLS-Scores einnimmt. Die Fakten basieren darauf, wie lange das Laden dauert, wie spät es im primären Thread-Prozess lädt oder wie viel es sich bewegt oder bewegt benachbarte Elemente herum.
• Kumulative Punktzahl
  Dieser Wert gibt die Summe aller CLS-Ereignispunkte an, um zu bestimmen, wie schlecht die kumulierte Situation für die gegebene Seite ist. Um den Standards von Google gerecht zu werden, darf der kumulierte CLS-Score 0,1 Punkte nicht überschreiten. Es wird empfohlen, dass der Score noch niedriger ist, da CLS ein individuell berechneter Wert ist und vom Crawler von Google möglicherweise schlechter bewertet wird als bei der Berechnung des Scores seinen Computer.
• Hatte kürzlich Input
  Dieser Wert gibt an, ob mit dem Element interagiert wurde, bis die Layoutverschiebung auftrat. Bei einer statischen HTML-Seite ist dies selten ein Wert, um den man sich Sorgen machen muss. Meistens sagt es aus, ob eine Benutzereingabe die Layoutverschiebung verursacht hat oder nicht.
• Umgezogen von / Umgezogen nach
  Dieser Wert gibt an, wo das Element ursprünglich war und wo seine neue Position nach dem Verschieben war. Es ist nicht ungewöhnlich, dass das Bauteil mehrere Bewegt-von- / Bewegt-auf-Werte hat, wenn es mehrmals verschoben wurde. Wenn Sie den Mauszeiger über die Werte bewegen, wird auf dem Bildschirm eine Übersicht darüber angezeigt, wo sich das Element vor und nach der Layoutverschiebung befand.
• Zugehöriger Knoten
  Dieser Wert verweist auf den DOM-Knoten im Dokumentenfluss, der verschoben wurde. Je nachdem, wo sich der Fehler befindet, gibt dies einen guten Hinweis darauf, welches Element entweder die Verschiebung verursacht hat oder von einem benachbarten Element beeinflusst wurde, das dann wiederum die Verschiebung verursacht hat.

Die Ursache von Fehlern

Der Hauptgrund für die LCP-Fehler war ein Hero-Image, das auf jeder Seite der Website erschien.

Natürlich gibt es viele Möglichkeiten, ein Heldenbild wie dieses durch Komprimieren und Ändern der Größe zu optimieren, was eine der wichtigsten Möglichkeiten gewesen wäre, wenn Logpoint sein Design und Layout beibehalten wollte. Dies war jedoch nicht der Fall, also haben wir das Heldenbild entfernt, das die meisten LCP-Fehler behoben hat.

Eine weitere Ursache für die LCP-Fehler war die Codestruktur. Logpoint verwendet einen Page Builder, was dazu führt, dass der Builder Grenzen setzt, wie sowohl Design als auch Code strukturiert werden können.

An einigen Stellen auf der Website wies das gesamte Layout Mängel auf, z. B. wurden p -Tags in h1 verschachtelt, was dazu führte, dass Textelemente zu Largest Contentful Paint wurden. Um dies zu beheben, haben wir die Website gefegt, um die Codestruktur zu rationalisieren und zu optimieren.
Wie erwähnt, war CLS auch ein Teil des Problems, und es wurde hauptsächlich durch zwei Elemente ausgelöst – die sich tatsächlich gegenseitig beeinflussten.

Die zwei Elemente

Zunächst einmal hatte Logpoint Youtube-Einbettungen auf seiner Website und um die Ladezeit zu verkürzen, implementierten sie ein Vorschaubild. Das Problem war, dass sowohl das Thumbnail als auch das Video gleichzeitig geladen wurden, woraufhin das Video per JavaScript-Code entfernt wurde. Dies führte zu erheblichen Layoutverschiebungen auf der Website.

Das zweite Element, das CLS betraf, war der auf der Website implementierte CookieBot. Wie erwartet erteilte der CookieBot Berechtigungen für die Videos, sodass sie nicht angezeigt werden konnten, bis die Zustimmung erteilt wurde.

Hier interagieren die beiden Elemente miteinander. Der JavaScript-Code, der das Video entfernt, wurde vom Entwickler speziell erstellt und so programmiert, dass er mit der CookieBot-Einwilligung interagiert.

Um das Problem zu beheben, haben wir das Skript geändert, wodurch das Laden des Videoelements und das Laden des Skripts selbst verzögert wurden.

Es ist wichtig zu erwähnen, dass Logpoint eine große Website mit vielen Komponenten ist, die alle auf unterschiedliche Weise miteinander interagieren. Das, kombiniert mit dem Theme und dem Page Builder, macht die Website komplex und schränkt auch einige der Optimierungsmöglichkeiten ein.

PageSpeed ​​war betroffen

Dies wirkte sich natürlich auf die PageSpeed ​​aus. Während wir uns also auf Core Web Vitals konzentrierten, arbeiteten wir auch daran, diese zu optimieren. Dazu haben wir die Plugins installiert: WP Engine für schnelles Hosting, WP Rocket für großartiges Caching und Optimierung von HTML, CSS und JS und schließlich CloudFlare für einen großartigen DNS-Anbieter.

Sprachvariationen haben neue Core Web Vitals-Fehler verursacht…

Während wir optimierten, nahm Logpoint erhebliche Änderungen an seiner Website vor und veröffentlichte viele neue Seiten in verschiedenen Sprachen, mit neuen Elementen und Layouts, die dazu führten, dass neue Core Web Vital-Fehler auftauchten – ein neuer Typ von CLS-Fehler musste nun behoben werden.

Noch einmal haben wir unseren Analyseprozess durchlaufen. In diesem speziellen Fall wurden die Layoutverschiebungen durch ein Chat-Plugin eines Drittanbieters verursacht. Meistens wird dieser Fehler durch Hinzufügen und Ändern von CSS-Regeln behoben, aber da der Chatbot von einem Drittanbieter implementiert wurde, konnten wir ihm kein benutzerdefiniertes CSS hinzufügen.

Daher war unser Ziel, sowohl eine Update-Anfrage bei den Entwicklern des Plugins zu stellen, da das Hinzufügen einen sichtbaren Tribut auf einer ansonsten sehr gut funktionierenden Website forderte, als auch alternativ ein Chat-Plugin mit einer besseren Ladepriorisierung zu finden.

Warum wir getan haben, was wir getan haben

Dass Core Web Vitals zum Rankingfaktor werden, verändert grundlegend die Funktionsweise der Rankings durch Suchmaschinen. Eine schlecht gestaltete Website, die keinen Fokus auf die Benutzererfahrung hat, wird es einfach nicht mehr schaffen.

Das Ziel von Google ist es, Website-Eigentümern dabei zu helfen, Websites zu erstellen, die sich auf die Benutzererfahrung konzentrieren, und indem sie Core Web Vitals als Ranking-Faktoren einbeziehen, tun sie genau das.

Google ist nicht dafür bekannt, mit offenen Karten zu spielen oder uns im Voraus über ihre Updates zu informieren, aber mit ihren Core Web Vitals und Page Experience Update wurden wir tatsächlich früh im Prozess informiert.

Das gab uns natürlich Zeit, uns das Wissen von Core Web Vitals anzueignen, aber es bedeutete auch, dass viele Elemente und Ideen in der Zeit von der Einführung bis jetzt noch nicht endgültig entschieden und geändert wurden.

Dies beinhaltete die Ergebnisse eines perfekten Core Web Vitals-Scores – nur gute URLs.

Zu Beginn war ungewiss, wie sich der Rankingfaktor Core Web Vitals auf die URLs auswirken würde. Dies ist schon seit geraumer Zeit ein Thema – aber diesen Juni werden wir alle mit Sicherheit mehr über die Auswirkungen wissen.

„Seiten, die bei Core Web Vitals die Bewertung „gut“ erhalten, erreichen ein erstrebenswertes Niveau der Benutzererfahrung und könnten einen Schub in der Seitenerfahrungskomponente des Rankings erhalten.“
– Google-Dokumentation

Ebenso ist unklar, ob ein Core Web Vitals-Bericht, der nicht alle Fehlertypen beherrscht, negativ betroffen wäre oder sich dennoch positiv auswirkt.

„Wenn Sie Seiten haben, die bei mindestens einer der Core Web Vitals-Metriken nicht „gut“ sind oder die anderen Kriterien für die Seitenerfahrung nicht erfüllen, empfehlen wir, sich im Laufe der Zeit auf Verbesserungen in diesen Dimensionen zu konzentrieren. Obwohl alle Komponenten des Seitenerlebnisses wichtig sind, werden wir Seiten mit den besten Informationen insgesamt priorisieren, auch wenn einige Aspekte des Seitenerlebnisses unterdurchschnittlich sind.“
– Google-Dokumentation

Darüber hinaus ist eine Idee für ein Core Web Vitals-Badge auf dem Reißbrett – so wie wir es vom AMP-Badge kennen. Auch dies ist noch nicht endgültig entschieden.

„Die allgemeine Richtlinie lautet, dass wir diese Kriterien auch verwenden möchten, um ein Abzeichen in den Suchergebnissen anzuzeigen, und ich denke, dass diesbezüglich einige Experimente durchgeführt wurden. Und dafür müssen wir wirklich wissen, dass alle Faktoren konform sind. Also, wenn es nicht auf HTTPS ist, dann im Wesentlichen, selbst wenn der Rest in Ordnung ist, dann wäre das nicht genug.“
– John Mueller, Webmaster-Trendanalyst, Google

Auch wenn es viele Unsicherheiten gab, eines ist sicher! Core Web Vitals ist hier, um zu bleiben und wird ein großer Teil des Kampfes um organischen Traffic werden – und deshalb haben wir uns besonders bemüht, die Core Web Vitals-Fehler auf Logpoint zu beheben.

Die zentralen Thesen

Am Ende des Weges ist es nur angebracht, darauf zurückzublicken, wo wir angefangen haben – und hoffentlich hat Ihnen dieser Fall das Wissen und die Werkzeuge vermittelt, um auf eigene Faust zu gehen.

Core Web Vitals ist etwas, von dem ich prognostiziere, dass es die Zukunft von SEO ist. Wir sind immer weiter dazu übergegangen, uns auf organischen Traffic zu verlassen, um das Wachstum zu beeinflussen, und Core Web Vitals ist nichts anderes als ein Bericht über ein perfektes Benutzererlebnis.

Wenn wir den Benutzer befähigen und ihm ein Produkt geben, das seine Zeit wert ist, dann werden sie natürlich damit interagieren wollen.

Logpoint, der Star der Show, hat dank der Erkenntnisse aus Core Web Vitals eine Transformation durchgemacht, die es uns ermöglicht, LCP- und CLS-Probleme sowie Integrationen von Drittanbietern und eine insgesamt chaotische Codestruktur zu bewältigen.

Indem wir uns an die Best Practices hielten und gleichzeitig Perspektiven auf die Erkenntnisse von Core Web Vitals zogen, konnten wir die technischen Aspekte der Website so umdrehen, dass sie sich von der Masse abhebt – das liegt bei Google .

Ein abschließender Rat

Ein freundlicher Rat von mir, bevor wir zum Abschluss kommen, ist, sich auf die Optimierung Ihrer Core Web Vitals zu konzentrieren – nicht nur wegen des Ranking-Faktors, sondern auch, weil es einen massiven Einfluss auf die Besucher Ihrer Website hat – und das ist nicht alles, was SEO ist um?

Es erhöht nicht nur die Verweildauer auf der Website, sondern verringert auch die Absprungrate und führt hoffentlich zu höheren Rankings und Conversions.

Geschrieben in Zusammenarbeit mit Andre Vestergaard, Technical SEO Specialist bei Bonzer.