Pagespeed - Cumulative Layout Shift - Adsense Killer - Google spinnt!

[Hanzo2012]

Ich hab's jetzt mit AdSense getestet, sowohl normal als auch mit simuliertem Mobilgerät. Gleiches Ergebnis: Alles grün. Und ich habe es parallel dazu auch noch mit der Version des Plugins aus dem Store probiert - auch hier alles grün (Desktop & simuliertes Mobilgerät).

[supervisior]

Na dann gibts eigentlich nur die schon erwähnte Möglichkeit, dass aus diesem height:auto in allen DIVs in Kombination mit dem Adsense Anzeigen Code impliziert wird, dass sich der Content verschieben "könnte", weil im Zweifelsfalle zum Negativen hin eine Bewertung erfolgt. Zumindest muss man bei diesem Plugin davon ausgehen, dass es so ist.

Ich hab also Konsequenz daraus jetzt mal eines gemacht und die Anzeige, die sich bei mir onTop präsentiert nach unten verschoben. Das Plugin honoriert das zwar, aber eben nicht grün....

Mich kotzt das förmlich an. Alle meine Seiten egal in welchem Projekt laden bis zu 100x schneller als der Rest der Welt. In Folge dessen lädt auch der Rest an statischen Sourcen x-fach schneller als wie beim Rest der Welt, aber Google attestiert mir bei den mobilen Geräten ich hätte langsame Seiten.

[supervisior]

Also dieses Plugin ist nur bedingt brauchbar, zumindest in der aktuellen Version. Vergleicht man ein und die gleiche URL jeweils mit diesem Plugin und Pagespeed Insight ergeben sich himmelweite Unterschiede zu Ungunsten von diesem Plugin, das auf deutlich bessere Werte kommt als Pagespeed.

[supervisior]

Und jetzt noch ein weiteres Manko, zumindest in jedem Fall bei diesem Plugin und hoffe nur, dass Google das nicht so handhabt. Alle meine Bilder laden verzögert, bzw. erst dann, wenn diese in den View Bereich gelangen. Eigentlich wäre es überflüssig dies duch ein eigenes Script zu machen, weil nach dem Chrome Browser nun auch der FF so ein Build-In Funktion mitbringen, aber ich möchte es nicht mehr missen.

In jedem Fall scheint dieses Plugin das verzögerte Laden so zu interpretieren, dass es dadurch zu einem Verschieben des Contents kommt und deswegen schon mal vorab eine schlechtere Bewertung abgibt bei der es aber nicht bleibt. Scrolled man in einer Listing oder in einer Seite nach unten, wo sich Bilder befinden und diese folglich erst dann geladen werden, verändert dieses Plugin die Messung zum Schlechteren hin.

So richtig paradox wird das Ganze aber, wenn einerseits durch das verzögerte Laden die Ladezeit begünstigt wird, aber man im Gegenzug das eigentlich positive wieder abgewertet bekommt, weil sich daduch der Content verschieben könnte.

Google spricht diese Problematik sogar an
https://developers.google.com/web/funda ... -and-video
und empfiehlt ein Platzhalter Bild, wofür ich aber einen Base64 Schnipsel mit wenigen Bytes verwende. Google will also, dass man eigentlich auf ein verzögertes Laden von Bildern verzichtet, weil es die Verschiebung von Content höher bewertet. Für mich ein Widerspruch in sich.

[Hanzo2012]

Wenn dein Platzhalterbild die richtigen Dimensionen hat, sollte es doch zu gar keiner Verschiebung des Contents kommen?

[supervisior]

Wenn dein Platzhalterbild die richtigen Dimensionen hat, sollte es doch zu gar keiner Verschiebung des Contents kommen?

Richtig, wobei das ohnehin nicht passieren kann. Erstens weil sich die Größe des Bildes durch object-fit:cover automatisch an die richtige Größe anpasst und zweitens weil der darumliegende Content (Text) die Bildgröße bestimmt. Es kommt also noch nicht mal theoretisch zu einer Verschiebung.

[supervisior]

Hier nun ein hoffentlich letztes Update, das aber einen endgültigen Status ermöglicht.

Hätte ich nicht schon von Beginn an so kompliziert gedacht, wäre ich schon viel früher draufgekommen, dass dieser CLS Mist vollkommen primitiv arbeitet. Hier wird nicht großartig analysiert, sondern im HTML Quellcode einfach nach bestimmten HTML Attributen gesucht, die eine Content Verschiebung auslösen könnten. Javascript und CSS und wenn letzteres nicht inline definiert ist, ist bei der Analyse komplett außen vor. Nahezu außen vor sind auch Anzeigen, aber nur bedingt. Wenn man z.B. im Kopf einer Seite eine Anzeige stehen hat, dann lädt diese typischerweise langsamer als der Rest des Contents. Dies gilt besonders dann, wenn man den Adsense Anzeigen verzögert laden lässt. Was also eigentlich und sich vermeintlich positiv auf den Pagespeed Score auswirken soll und das auch tut, wird durch die dadurch besonders auftretende Content Verschiebung wieder zunichte gemacht. Diese Verzögerungsfunktion zu entfernen löst das Problem aber nur bedingt, weshalb man im Falle dessen darauf verzichten sollte Anzeige gleich im Kopf zu platzieren.

Das eigentliche und viel gravierende Problem sind fehlende Größenangaben width & height bei den Bildern. Dabei spielt es für diese CLS Analyse überhaupt keine Rolle, ob diese Werte stimmen. Deswegen kann man auch Phantasiewerte verwenden, wenn die Größen durch CSS bestimmt werden. Hauptsache diese Angaben existieren und genau das hat bei mir dazu geführt, dass ich von einem Wert 0 wie jetzt einen Wert schlechter als 0,25 hatte.

Im Grunde genommen ist alles weit weniger dramatisch, aber auch viel primitiver. Zumal man diesen Wert auf einfachste weise faken kann.

[supervisior]

So für alle jene, die es nun ganz genau wissen wollen, hier dann doch noch ein Update, aber nicht unmittelbar, was dieses CLS unmittelbar anbetrifft.

Google hat offenbar seine Kriterien hinsichtlich Pagespeed auch in anderen Bereichen geändert, bzw. den Schwerpunkte abgeändert, was man nun noch weniger nachvollziehen kann. Konkret damit gemeint ist der sog. "First/Largest Contentful Paint". Also die Bewertung wie lange es dauert bis erstmalig was im Browser sichtbar wird und dafür diese Thumbnails im Testergebnis angezeigt werden.

Wenn es bei den bekannten Optimierungen zumeist darum geht das Ladeverhalten zu beeinflussen, sodass wichtiges zuerst und weniger wichtiges erst später oder verzögert geladen werden soll, dann zielt so was vorrangig auf Bilder ab. Unter dem Begriff "lazy load" ist dies vermutlich eher bekannt, jedoch gibt es in diesem Zusammenhang einen paradox wirkenden Sinneswandel bei Google. Geht es um mobile Geräte, ist neuerdings alles schädlich, was irgendwas an der Ansicht verzögert laden/anzeigen lässt. Wer also meint er tut was Gutes in dem er seine Bilder durch ein Script verzögert laden lässt, wird dafür nun bestraft, aber eben nur bei mobilen Geräten. Bei Desktop Geräten hätte Google es gern andersherum, also bitte lazy loaden.

Doppelt paradox ist das Ganze nun auch noch, weil Google im Chrome Browser und neuerdings auch der Firefox eine integrierte Funktion besitzen, die genau das macht, also die Bilder verzögert lädt und das trotz dessen, wie Google es bei den mobilen Geräten im Pagespeed Test haben will.

[staticweb]

> Konkret damit gemeint ist der sog. "First/Largest Contentful Paint". Also die Bewertung wie lange es dauert bis erstmalig was im Browser sichtbar wird und dafür diese Thumbnails im Testergebnis angezeigt werden.

LCP wurde neu eingeführt und bewertet den größten Block over the fold.

> Geht es um mobile Geräte, ist neuerdings alles schädlich, was irgendwas an der Ansicht verzögert laden/anzeigen lässt.

Das steht wo und hat konkret welche praktischen (!) Auswirkungen?

> Doppelt paradox ist das Ganze nun auch noch, weil Google im Chrome Browser und neuerdings auch der Firefox eine integrierte Funktion besitzen, die genau das macht, also die Bilder verzögert lädt und das trotz dessen, wie Google es bei den mobilen Geräten im Pagespeed Test haben will.

Das Loading Attribute gibt es bereits seit Chrome 76, also ca. einem Jahr, Warum soll das schädlich sein, wenn es z.B. vom mobilen Chrome unterstützt wird? Wenn dann geht es maximal um Implementationen in Browser die das Attribute nicht unterstützen und stattdessen die Intersection Observer API nutzen.

[supervisior]

> Konkret damit gemeint ist der sog. "First/Largest Contentful Paint". Also die Bewertung wie lange es dauert bis erstmalig was im Browser sichtbar wird und dafür diese Thumbnails im Testergebnis angezeigt werden.

LCP wurde neu eingeführt und bewertet den größten Block over the fold.

> Geht es um mobile Geräte, ist neuerdings alles schädlich, was irgendwas an der Ansicht verzögert laden/anzeigen lässt.

Das steht wo und hat konkret welche praktischen (!) Auswirkungen?

> Doppelt paradox ist das Ganze nun auch noch, weil Google im Chrome Browser und neuerdings auch der Firefox eine integrierte Funktion besitzen, die genau das macht, also die Bilder verzögert lädt und das trotz dessen, wie Google es bei den mobilen Geräten im Pagespeed Test haben will.

Das Loading Attribute gibt es bereits seit Chrome 76, also ca. einem Jahr, Warum soll das schädlich sein, wenn es z.B. vom mobilen Chrome unterstützt wird? Wenn dann geht es maximal um Implementationen in Browser die das Attribute nicht unterstützen und stattdessen die Intersection Observer API nutzen.

Es geht nicht darum was neu eingeführt wurde, sondern dass gleiche Attribute je nach Gerät unterschiedlich ausgelegt werden. Das steht nirgendwo geschrieben, aber lässt sich praktisch reproduzieren.

[elmex]

Hehehe
*duck und weg*

Zu spät! Hast Du die virtuelle Ohrfeige nicht gespürt?

Nö, hab mich ja professionell geduckt

[supervisior]

Hehehe
*duck und weg*

Zu spät! Hast Du die virtuelle Ohrfeige nicht gespürt?

Nö, hab mich ja professionell geduckt

Wart' nur, der Schmerz einer bajuwarischen Gnackwatschn kommt zeitverzögert!

[elmex]

Hast du wohl schon wieder dem Seehofer sein Weissbier weg getrunken, du weisst doch, wir Preussen vermöbeln euch jedesmal