Nur für den Fall, dass jemand mit "Core Web Vitals" (noch) nix anfangen kann, unter https://web.dev gibts die entsprechenden Informationen dazu.
Den bekannten Kritikern sei bereits an dieser Stelle gesagt, dass man das Thema "Core Web Vitals" nicht kleinreden sollte. Es wird sich zwar erst in der Praxis zeigen, welche Auswirkungen dieser neue Ranking Faktor haben wird, aber vor dem Hintergrund welchen Tam Tam Google damit schon seit letztes Jahr macht, können die Auswirkungen nicht ganz so unerheblich sein. Auch wenn es mit den Core Web Vitals primär darum geht, dass eine Webseite den Anforderungen der Core Web Vitals entspricht, gibt es noch 2 weitere Faktoren, die, wenngleich nachrangig wirkend, vermutlich noch größere Auswirkungen haben können.
Google sieht mit den Core Web Vitals vor, dass man bereits in den Suchergebnissen sehen wird, ob eine Seite den Core Web Vitals entspricht. Diese Kennzeichnung wird sicherlich nicht großartig die Optik stören, wobei 9 von 10 damit vermutlich gar nichts anfangen werden können. Nichtsdestotrotz könnte es aber trotzdem sein, dass sich jemand im Sinne des Suchenden beeinflusst sieht. Beeinflusst insofern, wenn er aus einer schlechten Web Vitals Kennzeichnung impliziert, dass er womöglich von einem Click absieht, wenn er durch diese Kennzeichnung schon vorher weiß, dass ihn eine langsam ladende Seite erwarten könnte. Das ist zu diesem Zeitpunkt zwar nur eine Spekulation, aber ausschließen darf man es nicht, zumal auch nicht ganz abwegig.
Der nächste Faktor besteht darin, dass Google ebenso angedroht hat beim Aufruf einer Seite aus den Suchergebnissen eine Art Zwischenseite einzublenden, die solange stehen bleibt bis die angeforderte Seite dann mal lädt. Diese Zwischenseite soll aber nur dann erscheinen, wenn eine Seite dauerhaft und auffallend langsam lädt. Es bleibt dem Einzelnen überlassen, wie er so eine Zwischenseite interpretiert. Im günstigsten Fall passiert gar nichts, im schlechtesten Fall bricht er den Ladevorgang ab, was besonders bei mobilen Geräten der Fall sein dürfte.
Das nun paradose an den Core Web Vitals ist, dass es dabei eigentlich gar nicht um Geschwindigkeit geht, zumindest nicht um Geschwindigkeit des Ladens einer Seite. Eine länger andauernde Erstreaktion des Servers wird im Falle dessen zwar beanstandet, hat aber nur eine nachrangige Auswirkung auf das Gesamtergebnis. Man kann mit einem bllitzschnellen dediziertem XXL Server also ein gleich gutes oder schlechtes Ergebnis produzieren wie mit einem 5,- € Shared Hosting. Da fragt man sich natürlich unweigerlich:"Was soll der Sch....?"
Die Frage und der Sinn dahinter kann sicherlich nur Google selbst beantworten. Ich für meinen Teil interpretiere die Core Web Vitals so, dass es hierbei nicht um die Ladezeit geht, sondern um die Anzeigezeit wie lange es dauert bis was im Browser angezeigt wird NACHDEM alle Daten vom Server geladen wurden. Das eigentliche Laden der Daten bleibt bei den Core Web Vitals fast gänzlich unberücksichtigt. Vor diesem Verständnis erklärt sich dann zumindest warum die Server Ausstattung und das Hosting eigentlich fast keine Rolle spielen.
So, nun zum eigentlichen Thema: Core Web Vitals: Wie man seine Seite auch mit Adsense & Co. schnell bekommt.
Wer Adsense, also Anzeigen auf seiner Seite hat, kennt das Problem bereits, dass man mit Ads keinen guten Pagespeed Score bekommt. Das gilt im Übrigen auch, wenn man Google Analytics, den Tag Manger oder Fratzenbuch & Co. auf seiner Seite eingebunden hat. Das Problem mit Ads kann man gut bis sehr gut lösen. In Ermangelung, dass ich weder GA noch das Fratzenbuch verwende, kann ich dazu leider keine Aussage treffen.
Mal abgesehen davon, dass mit Adsense sehr viele externe Requests ausgeführt werden und diese maßgeblich dazu beitragen, dass das Rendern der Seite dadurch verzögert und sogar blockiert wird, bringen es exerne Aufrufe mit sich, dass die Anzeigen nur verzögert angezeigt werden können. Ein Umstand an dem sich so gut wie gar nichts ändern lässt. Es sind zwar diverse Script Lösungen im Umlauf (auch aus meiner Feder), die das Laden des Adsense Code verzögern sollen, damit das Rendern des Codes der eigenen Seite nicht beeinflusst wird, aber diese Scripts machen alles nur noch schlimmer. Zumindest aus Sicht der Core Web Vitals. Wer solche Scripte verwendet, sollte sie entfernen. Warum? Weiterlesen.
Bei den Core Web Vitals gibt es zwar viele Punkte, die es zu berücksichtigen gilt, aber 2 stechen dabei besonders hervor und werden dementsprechend höher gewertet als andere. Bei einem dieser beiden Punkte geht es um kumulierte Layout Verschiebung, kurz CLS. CLS beschreibt den sicherlich jedem bekannten Seiteneffekt, wenn einzelne Inhalte nur langsam laden und wenn sie dann geladen sind dazu führt, dass man an eine Stelle klickt, die vor dem Laden noch nicht sichtbar war. Im worst case handelt es sich dabei um eine Anzeige und daran stört sich Google erheblich. Hat man also so ein besagtes Script im Einsatz, dass das Laden von Anzeigen verzögert, verschlimmbessert man es gewissermaßen, sodass man in gutem Glauben etwas für ein schnelleres Laden getan zu haben einen schlechteren Score bekommt. Also wech damit!
Bei CLS geht es aber nicht nur um Ads, sondern generell um alles was dazu führt, dass Inhalte verlangsamt angezeigt werden. Eine Verzögerung kann auch dadurch erfolgen, dass man z.B. mit CSS eine Verzögerung definiert hat oder weil man Inhalte animiert darstellen lässt. Alles stellt im Sinne von CLS eine Abwertung dar, aber nicht generell auf die gesamte Seite bezogen. Wenn man einen Pagespeed Test macht, lädt Google zwar den gesamten Quellcode, aber nicht den Code oder Sourcen, die erst dann erscheinen, bzw. geladen werden, wenn der jeweilige Inhalt sichtbar wird. Im maßgeblichen Fokus steht der Bereich, der nach dem Laden ganz oben steht also "above the fold" ist. Wenn in diesem sensiblen Bereich egal was und wodurch verzögert angezeigt wird, gibt es für CSL eine schlechte Bewertung. Hat man nun Anzeigen in Gebrauch, forcieren diese durch ihr naturgemäß langsames Ladeverhalten eine CLS Abwertung. Das ließe sich zwar bedingt dadurch beeinflussen, dass man dem <ins> Tag bei Adsense Anzeigen eine fixe Höhe gibt, löst das Problem aber nur sehr bedingt. Deswegen kann man was wesentliches nur dadurch erreichen, dass man alle Anzeigen oberhalb der Knickfalte entfernt. Leider mit der Konsequenz behaftet, dass man dann ggf. weniger Einnahmen generiert. Eine schnelle Seite im Sinne der Core Web Vitals ohne Einnahmenverlust geht einfach nicht. Das gelingt noch nicht mal mir als Speed Junkie.
Nichtsdestotrotz stellt Adsense & Co. ein maßgebliches Hindernis dar, das sich unweigerlich auf die Core Web Vitals auswirkt, zumindest wenn man sich keine entsprechende Lösung dafür ausdenkt. Lösung heißt aber nicht cheaten auch wenn die nachfolgende Beschreibung dieser Lösung den Anschein erwecken könnte!!! Ich muss vorausschicken, dass diese Lösung nicht für jeden anwendbar ist, weil man dafür nicht nur das Theme/Template bearbeiten muss, sondern mitunter auch PHP Dateien anpassen muss. Und nein, dafür gibts auch kein Plugin, wobei es fraglich ist, ob man so was überhaupt über ein Plugin lösen kann.
Maßgebliche Hilfestellung um diese Lösung ausarbeiten zu können, hat mir der Cookie Consent gegeben. Gewissermaßen hat mir der Cookie Consent in die Hände gespielt, wobei ich diese Abfrage mehr als wörtlich nehme. Es geht dabei also nicht nur darum relevante Scripte von Adsense bis zur Zustimmung zu blockieren und somit auch die damit verbundenen Cookies. Ich habe diese Blockierungen auf den kompletten Seiten Inhalt erweitert. Ruft man also eine Seite erstmalig auf, wird nur das für diese Anzeige notwendige geladen, aber nicht nur optische Sachen, sondern der komplette PHP und Datenbank Rotz. Was also tatsächlich geladen wird, ist nur ein Bruchteil dessen, was für die gesamte Seite beladen werden muss. Ich lasse also nicht einfach nur einen Banner oder einen Layer anzeigen, sondern quasi nur die absolute Schmalspur Version einer Seite.
Nachdem es dafür nur ein Kilobytes braucht, erfolgt der Ladevorgang exorbitant schnell, sodass für das Laden des durch PHP generierten Hauptdokumentes weniger als 20ms vergehen. Zusätzlich nutze ich die Server/PUSH Funktion, die zwar jeder hat, aber fast keiner zu nutzen weiß. Mit dieser PUSH Funktion lade ich alle wichtigen statischen Sourcen wie z.B. CSS, Javascript, Bilder und auch den Adsense Code VOR. Entscheidend bei dieser PUSH Funktion ist, dass das Vorladen anders also beim HTML preload bereits erfolgt noch bevor 1 Byte für den Response Body, also der eigentliche Quellcode geladen wird. Außerdem wird der Code weder gerendert noch geparsed, sodass es keinen Einfluss auf die Anzeige hat. Durch dieses Vorladen hat der Browser schon alles im Speicher, was er ansonsten später erst alles laden muss. Man mag es kaum glauben, aber daraus resultiert eine erhebliche Zeitersparnis, wenn der Nutzer dann seine Cookie Entscheidung getroffen hat. Egal welche Entscheidung der Nutzer trifft und vor dem Hintergrund, dass er schon alles benötigte an Daten schon geladen hat, erfolgt die Anzeige fast nur mehr aus Daten, die der Nutzer schon im Browser Cache hat.
Ich wusste vorab nicht, ob mein Plan gelingt, aber obwohl meine Seiten schon vorher blitzschnell waren, hat es vor dieser Lösung bei den Desktop Rechnern nicht für einen "grünen" Score gereicht. Jetzt bin ich mit allen Seiten und Geräten im grünen Bereich und nach Maßgabe der Core Web Vitals sind meine Seiten deutlich besser als vorher.
Nachmachen....
