On-Demand Webinar: Was sind Google Web Vitals, wie beeinflussen sie in Zukunft den E-Commerce-Shop und wie optimiere ich meinen Shop dafür?

SEO Page Performance - Insights und Best Practices

Das erfahren Sie im Webinar:

  • Was sind Web Vitals?

  • Wie kann ich diese messen?

  • Wie verbessert man Page Speed effektiv?

Und wenn Sie nicht wissen was TTFB, FMP, FCP, LCP, FID und CLS bedeuten und was das mit Ihrer Website zu tun hat, sollten Sie dieses Webinar besser nicht verpassen!

Jetzt online ansehen:

Die Referenten

Matthias Hotz ist Head Of Technical SEO bei der diva-e Advertising und war vorher Teamleiter und Entwickler bei der 1&1 Internet AG, unter anderem verantwortlich für DSL, Mobile und Hosting Shops. Er war Speaker auf SEO Konferenzen wie der SMX und dem SEO Day. Bei der diva-e Advertising entwickelt er SEO Tools und betreut Kunden, wenn es um Analyse und Optimierung von technischen SEO Maßnahmen geht. In seiner Freizeit betreibt er das kostenlose SEO Tool seorch.de.
Matthias Hotz
Head Of Technical SEO, diva-e Advertising
Christian Paavo Spieker ist Entrepreneur und SEO Evangelist. Schon 1995 gründete er das Unternehmen Concept Advertising in München, das er zu einer der führenden Webdesign-Agenturen ausgebaut hat. 2006 folgte die One Advertising AG, die seit 2017 zur diva-e Family gehört. Seitdem ist Christian CEO der diva-e Advertising.
Christian Paavo Spieker
Founder & CEO, diva-e Advertising

Transkript zum Webinar: Wie optimiere ich meinen E-Commerce-Shop nach Google Web Vitals

Intro

Angela Meyer: Ein herzliches Willkommen zu unserem heutigen Webinar. Heute gibt unser SEO-Experte Matts Tipps, wie ihr euren E-Commerce Shop optimieren könnt. Und wenn Matts ihn zu Worte kommen lässt, darf Paavo auch noch etwas dazu sagen. Das ist euer Stichwort. Und ich freue mich auf unsere SEO-Experten Matts und Paavo. Ich übergebe jetzt euch das Wort und wünsche den Zuschauern viel Spaß beim Zuhören. Ihr seid dran.

Christian Paavo Spieker: Danke, Angela. Wie immer sensationales Intro. Matts, swipe the Slide.

Matthias Hotz: Ich tue. So.

Christian Paavo Spieker: Ja, kurz zu meiner Person. Für die, die mich nicht kennen: Paavo. Bin finnischer Abstammung, daher dieser wunderschöne Vorname. Ich bin Gründer und CEO der diva-e Advertising. Mache seit 1997 SEO. Bin demzufolge schon ein ziemlich alter Sack. 49 Jahre, habe zwei Kinder: Annalena und Timo. Bin im BVDW-Expertenbeirat. Und habe so ein paar Hobbys, die man halt so hat als Mann. Die sind immer ziemlich viele. Deshalb haben wir jetzt Punkt, Punkt gemacht. Aber alles, was so ein bisschen Räder hat, Downhill. Und natürlich SEO ist wirklich meine große Leidenschaft seit langer, langer Zeit. Seitdem ich es damals entdeckt habe. Ich weiß nicht, ob es '97 war. Es ist schon arg früh. Aber so '98 muss es gewesen sein. War vor Google auf jeden Fall. Und ja, wenn es rankt, ist es SEO. Wenn nicht, dann ist es irgendwie doof. Das ist das Coole und das Geile auch am SEO, was mir jeden Tag wieder Spaß macht. Die Ergebnisse sind immer relativ schnell sichtbar oder bewertbar. Ja, ich habe jetzt meinen Facebook-Account gemoved zu LinkedIn. Weil die russischen Heiratsanträge, die wurden mir jetzt ein bisschen zu viel in letzter Zeit.

Also, wenn mir jemand SEO-mäßig folgen will, dann bitte auf LinkedIn: /PAAVO-spieker/ Und da könnt ihr mich dann finden. Und jetzt müssen wir ein bisschen Gas geben. Weil ich habe mir sagen lassen, um 15:30, glaube ich, wird der NASDAQ-Handel eröffnet, mit Aktien. Da geht es halt richtig ab. Und da geht immer GoToMeeting bisschen in die Knie. Und da die Google-Aktie irgendwie so wieder über 1500 US-Dollar-. Mein Gott, ich kann mich noch erinnern, ich habe sie, glaube ich, für 85 Dollar gekauft, damals 2004. Ach, alte Männer und Aktien. Gebe ich jetzt zu meinem werten Kollegen und wohl dem besten Technical SEO des Landes, Matts, nach Karlsruhe.

Matthias Hotz: Hallo. Ob ich der beste bin, sei mal dahingestellt. Ich bin der Matthias, Matts. Ich höre auch auf: "Hey du!" Eigentlich bin ich Frontend-Entwickler. Aber stimmt. Ich kann HTML. Ich kann CSS. Ich kann auch Backends bauen mit PHP, NoteShare, Python und so weiter. Eigentlich bastle ich gerne SEO Tools. Programmiere gerne. Und kenne mich im technischen SEO ziemlich gut aus. War vorher bei Pentair. Das ist ein, wenn man es schon von Aktien haben, ist eine Fortune 500. Einer der größten US-Konzerne. Ist aber eher so für B2B. Dann war ich bei 1&1 ein paar Jahre. Habe dort die Webshops gebaut. War da Teamleiter. Und habe die Shops, wenn ihr DSL-, Mobilfunk- oder Hosting-Verträge bestellt habt, die sind mehr oder weniger über meinen Tisch gegangen. Hobbys: Ja, ich baue gerne Software. Aber ich bewege mich auch gerne auf dem Fahrrad, am liebsten jeden Tag. Und ich bin jetzt seit sechs Jahren bei der diva-e für Advertising. Dann darf jetzt der Paavo noch was erzählen.

Christian Paavo Spieker: Darf ich auch noch was erzählen? Ja, man darf ja normal keine Werbung machen in einem Podcast. Das kommt ja immer ziemlich schlecht. Aber ich mache es jetzt. Ist ja gar kein Podcast. Ist ein Webinar. Aber ich sage es jetzt trotzdem mal. Wir haben halt mit SEO '99 angefangen. 2006 haben wir die One Advertising gegründet, die viele von euch kennen. 2015/2017 haben wir den SEMY Award für Beste SEO Agentur gewonnen. Dann haben wir gemerkt, dass wir doch immer echt viel Technik brauchen, bei uns in der Agentur. Und dann haben wir uns kurzerhand mit der diva-e zusammengetan. Und sind zur diva-e Advertising geworden. Da hatten wir jetzt viele Ressourcen im Adobe-, Bloomreach-, SAP-Bereich. Spryker ist natürlich eines unserer Babys. Und dann sind wir BVDW-zertifiziert. Zu unseren Kunden: Sind wir ganz stolz. Sind 20 Prozent der deutschen DAX-Unternehmen. Also, für die kühlen Kopfrechner: Es sind vier bis fünf, je nachdem wie man es jetzt sieht. Aktueller Stand. Mit einem leichten Schmunzeln. Und Matts, bitte den nächsten Slide.

Matthias Hotz: Wirecard ist nicht mehr Kunde? (lacht) War ein blöder Witz. Nein, Wirecard war nie Kunde.

Die Historie der Google Algorithmus-Updates

Christian Paavo Spieker: Ach, gehört dazu. Bisschen Schwund ist ja immer. Ja, Google Updates. Klar, für die SEOs unter euch, die jetzt schon ein bisschen länger dabei sind: Das erste große Update, was mir so in Erinnerung geblieben ist, war 2003, das Florida Update. Das hat uns allen SEOs damals-. Da waren wir ja alle so im Arbitagegeschäft. Da war ja Google Update immer was ganz Schlechtes, eigentlich. Weil irgendwie war ja irgendwie immer ein neues Algo-Update oder irgendwas. Aber der Florida 2003, der war wirklich hart. Da gab es so Seiten, die hatten da wirklich so 60, 70, 80.000 User am Tag. Und hatten danach irgendwie zehn.

Dann gab es das Austin Update kurz danach. Das hat dann nochmal das gut gemacht-, oder die Seiten erwischt, die Florida nicht erwischt hat. Also, die SEOs haben immer so ein bisschen gekämpft mit diesen Updates. Oder gegen diese Updates. Sind den Updates hinterhergehechelt. Viele sagen auch, die Updates gibt es eigentlich nur, damit die SEOs beschäftigt sind. Hat sich dann so ein bisschen gedreht nach Panda, Pinguin. Dann war die Geschichte mit den Links 2009. Da hat Google natürlich ganz schlau die ganzen Link-Bilder einfach mal schön vom Tablett gefegt, indem sie quasi Links verboten haben. Und Visual Playtray Penalties vergeben haben.

Aber so das erste, sagen wir mal, User Update, nach Caffeine und Hummingbird und was alles so da war, war natürlich Mobile Friendly Update. Das war ja 2015. Glaube, im Februar oder so haben die angekündigt: "Wenn du keine Mobilseite hast, dann läuft es- dann wird es ganz, ganz schlecht mit den Google Rankings." Google hat ja schon 2013 angefangen, bei uns, bei den Agenturen zu pitchen: Mobile, Mobile, Mobile. Wir hatten damals ein Conversion, also ein Umsatz-Share. Also ein Umsatz von 96 Prozent war auf Desktop. Und Mobile war eigentlich eher weniger. Weil natürlich die Conversion da nicht so wirklich stattgefunden hat. Und da hat sich Google gedacht: "Jetzt machen wir mal einen ganz anderen Move. Wir kündigen jetzt an, dass am 21.4.2015 eben ein Mobile Friendly Update kommt. Und wenn ihr da nicht mobile und responsive seid, dann macht es bäm." Dann sind alle losgelaufen bei uns. Telefone haben heiß geglüht. Wir haben das Update gemacht. Es ist natürlich nichts passiert. Aber alle Seiten waren dann zumindest ansatzweise mobile. Da gab es dann mehrere Rollouts noch davon.

Es gab das Mobile Speed Update 2018. Und da hat man schon gesehen, es geht alles Richtung User. Und da wir ja auch wollen, dass unsere User alle glücklich sind. Und alle SEOs sich eigentlich nur noch danach richten sollten. Weil dann sind sie eigentlich konzeptionell immer ganz gut damit gefahren. Hat Google natürlich jetzt, nach dem BERT Update und was es da noch alles gab in letzter Zeit, eben das Page Experience Update für 2021 angekündigt. Aber jetzt nicht mit einem harten Datum. Aber natürlich ganz klare Aussage wieder: "Also, wenn natürlich die Experience nicht passt, die UX nicht passt. Wenn der User eine schlechte Experience auf eurer Website, eurem Shop oder wo auch immer hat, dann wird es sehr negativ sein." Das wissen wir eigentlich schon länger. Also, alle Tests bei uns ergeben ja, dass die Seiten oder die Shops, weil deswegen reden wir ja heute über Shops. Weil da lässt sich natürlich der Erfolg am besten immer messen. Weil wenn halt da kein Umsatz mehr kommt oder der Umsatz wegbricht, die Conversion Rate wegbricht, dann merke ich es natürlich immer. Und dann hat es natürlich signifikante Auswirkungen. Und dass da die User Experience, die Time on Site, Back to Surp Rate, da gibt es ja verschiedene Mechanismen, die da greifen, wie Google das messen kann. Da kommt der Matts dann gleich dazu, im Detail große Auswirkungen hat. Das haben wir natürlich schon lange gemerkt. Und deswegen sind wir ganz froh darum, dass jetzt Google wieder mal so einen Schritt geht. Und dass mit dem Page Experience Update 2021 da noch mal ein richtiger Bäng gesetzt wird. Und der erste Schritt dazu sind die Web Vitals. Nein, da wiederum der erste Schritt: die Core Web Vitals. Und dazu hat der Matts jetzt ganz, ganz viel tolle Folien vorbereitet. Und Matts, let's go. Lass uns vital werden.

Einführung in die Google Web Vitals

Matthias Hotz: Dann lass uns vital werden. Also Web Vitals wurde angekündigt dieses Jahr. Ich glaube, die meisten SEOs haben es gar nicht so wahrgenommen. Es war halt wieder so ein Eintrag in Google Blogs et cetera. Wenn man so ein bisschen genauer da reingelesen hat, konnte man bisschen, ja, alarmiert werden. Um was geht es da? Also, Web Vitals ist erst mal nur die Überschrift über dem Ganzen. Also, die Idee dahinter ist mehr oder weniger, dass man User Experience messbar machen kann. Google will die User Experience auf einer Website bewerten könne. Das erzähle ich schon seit ein paar Jahren, dass Google immer mehr dahin geht zu verstehen, wie eine Website für den Benutzer funktioniert. Sind die Buttons schön groß? Kann man da toll klicken? Sind die Graphen angenehm zu lesen? Lauter so Sachen. Und das passiert jetzt.

Also, Web Vitals, das, was ich euch jetzt da nachher erzähle, geht erst mal mehr oder weniger. Viele werden denken, das hat ja mit Page Speed oder Page Performance zu tun. Allerdings nicht so zwangsläufig. Da Page Speed und Page Performance sehr komplizierte Regeln sein können, sehr viele Abhängigkeiten haben können. Es gibt zig Messmetriken, zig Hebel, an denen ich stellen kann. Das, was ich euch gleich erzähle, sind erst mal ein paar Einträge. Der Fokus von Google ist klipp und klar. Dinge, die zu einer wirklichen Verbesserung der User Experience führen, im ersten Schritt. Was da noch kommt, werden wir dann mal sehen. Es ist angekündigt, laut Google, auf 2021. Sprich, dort wird es als Rankingfaktor in den Google-Algorithmus eingehen, höchstwahrscheinlich. Wie stark die Bewertung sein wird, bleibt abzuwarten. Und zum Start hat Google die Core Web Vitals veröffentlicht. Da gibt es auch unter der URL, die ihr da seht, quasi einen Eintrag, wo das alles beschrieben wird.

Google Core Web Vitals

Und ich möchte euch diese Core Web Vitals mal genauer vorstellen. User Experience war in der Vergangenheit schon mehrfach Rankingfaktor, beziehungsweise ist Rankingfaktor. Wo Google gemerkt hat, dass über 50 Prozent ihrer User Smartphones benutzen, um sich in Google zu bewegen, haben sie Mobile First eingeführt. Sicherheit im Netz, wo es sehr viele Vorfälle gab et cetera, gab es dann Hinweise, wenn eine Website keine Verschlüsselung unterstützt. Die Interstitials, die irgendwann zuhauf kamen, haben eigentlich den User nur noch genervt. Also gab es die Penalty im Algo. Dass wenn, ja, Intrusive Interstitials, haben sie es genannt, kamen, gab es einen aufs Dach. Wenn Malware oder Phishing auf der Website entdeckt wird, fliegt die Domain aus dem Index. Ich kriege einen Hinweis in der Google Search Console, dass ich das zu fixen habe.

Und so gab es eben, wie der Paavo schon gesagt hat, diverse User-Experience-Geschichten, die darauf abgezielt haben, jetzt nicht rein den Content einer Website zu bewerten, oder die Backlinks, die sie hat, oder was auch immer. Sondern eben die Erfahrung der Nutzer zu bewerten. Die Web Vitals erweitern das jetzt. Die sind quasi, wie die Faktoren da oben, messbare User Experience. Und dann fangen wir auch schon mal an.

Das sind im ersten Schritt-. Web Vitals ist der Überbegriff. Google hat dann gesagt: "Wir starten jetzt mal mit den Core Web Vitals." Und das ist ein Subset. Also, ich gehe davon aus, dass die Web Vitals zukünftig erweitert werden. Das sind drei Metriken. Die nennen sich LCP, FID und CLS. Erkläre ich alles nachher im Detail. Aber mal kurz zusammengefasst: LCP bedeutet Largest Contentful Paint. Das ist, grob gesagt, die Ladegeschwindigkeit. FID ist der First Input Delay. Und das beschreibt die Interaktivität einer Website. Der CLS ist der Cumulative Layout Shift. Das ist die visuelle Stabilität einer Website. Alles das gibt es jetzt schon in der Search Console. Und man kann jetzt schon da eingehend optimieren. Beziehungsweise zumindest das monitoren, um zu sehen, ob man da ein Problem hat. Das ist jetzt die Karenzzeit, die man hat, wenn es dann nächstes Jahr Rankingfaktor wird.

Die Metriken der Web Vitals im Detail

Largest Contentful Paint (LCP)

Jetzt erkläre ich so erst mal im Detail, was es mit diesen Metriken auf sich hat. Also, der LCP, der Largest Contentful Paint, ist das Teil auf der HTML-Seite, das im initialen Viewport das größte Element ist. Also der initiale Viewport ist ja: Ihr betretet eine Website. Und dann mag die sehr lang sein. Man kann ewig scrollen. Aber das ist gar nicht so wichtig. Sondern es ist das größte Element, das ihr als erstes sehen werdet. Man sieht es auch in der Grafik da unten: Ich habe hier FCP und LCP markiert. FCP ist der First Contentful Paint. Und LCP, haben vielleicht einige von euch schon gehört von Page-Performance-Geschichten, und LCP ist der Largest Contentful Paint. Also in diesem Fall jetzt diese Grafik, die ihr da seht. Es können mehrere Dinge sein. Der Largest Contentful Paint muss jetzt keine Grafik sein. Wenn die Seite zum Beispiel ein Video hat, eine Bühne oder einen Slider, dann ist es eben dieses Element.

Es sind eben keine Elemente, die sich unterhalb des initialen Viewports befinden. Da gibt es schon ein bisschen ein Problem, weil der initiale Viewport kann ja je nach System ein anderer sein. Habe ich so einen Monster-30-Zoll-Monitor, ist der größer als auf einem Smartphone oder einem 14-Zoll. Aber erst mal verstehen, was es ist. Google gibt auch sehr exakt die Werte raus, die gut, mittel oder schlecht sind. Gut ist unter 2,5 Sekunden. Mittel: 2,5 bis 4 Sekunden. Und Schlecht sind vier Sekunden. Es ist also davon auszugehen, dass wenn es Rankingfaktor wir, alle, die langsamer als vier Sekunden ihren Largest Contentful Paint haben, in irgendeiner Weise benachteiligt werden.

First Input Delay (FIT)

Der nächste Punkt ist der FIT, der First Input Delay. Das ist jetzt die Zeit zwischen einem Klick und der Reaktion der Website. Es muss nicht zwangsläufig ein Klick sein. Es geht um die Interaktivität. Also, zum Beispiel, wenn ich anfange zu scrollen, dass es keine Verzögerungen gibt. Wenn ich die Maus über irgendwas bewege, dass der Hover-Effekt sofort sichtbar wird. Wenn ich irgendwo klicke oder ein Textfeld benutze, dass ich keine Verzögerungen habe. Das habt ihr vielleicht auch schon auf Webseiten erlebt, dass, wenn ihr klickt und es so einen mini lag hat, das fühlt sich sehr komisch an. Und eigentlich sehr unangenehm. Oder sehr unnatürlich.

Das hat den Grund, dass, wenn eine Seite visuell fertig geladen ist, kann sie immer noch langsam auf User-Eingaben reagieren, wenn ein großes JavaScript noch gepassed wird. Also, der Browser nimmt ja erst das HTML, dann hoffentlich das CSS. Und dann kann er ja schon was machen. Vielleicht hat er auch schon ein, zwei Bilder. Aber JavaScript ist-. Also, ich sehe teilweise in freier Wildbahn Seiten, die vier bis fünf Megabyte JavaScript übertragen. Und das muss vom Browser gepassed, interpretiert, heruntergeladen werden. Und je nachdem, was da drin ist, kann das eine ganze Weile dauern, bis das funktioniert. Gut ist unter 100 Millisekunden, schlecht über 300 Millisekunden.

Cumulative Layout Shift (CLS)

Dann haben wir den Cumulative Layout Shift. Da geht es um die Stabilität einer Website, während sie geladen wird. Ich habe dafür mal, bevor ich jetzt alles erkläre, ein Video gemacht. Ich lasse es mehrfach abspielen, damit man es auch sieht. Also, das Video läuft jetzt. Ihr seht das Google-Logo. Und dann reloade ich die Website. Das mache ich jetzt. Und dann seht ihr, dass das Logo noch nicht da ist. Und da unten ist ein Link. Und dann wird das Logo geladen. Ich lasse es nochmal laufen. Also das Google-Logo. Und während das Google-Logo dann geladen wird, schiebt sich der ganze weitere Inhalt nach unten. Sprich, ich befinde mich also mit meiner Maus auf diesem wichtigen Link, eigentlich plane ich schon zu klicken. Und dann springt das ganze Layout ein Stück runter.

Das sieht man, wer Twitter zum Beispiel benutzt, in letzter Zeit sehr oft auf Twitter. Dass ich bei einem Tweet bin und dann dort oben ein Video reingeladen und der Tweet ist weg. Ja, aus meinem Viewport rausgehüpft. Das ist quasi die Messung des Cumulative Layout Shift. Das passiert bei sehr vielen Webseiten, leider. Das können auch verschiedenen Elemente sein. Also, es muss kein Bild sein. Es kann ein Videoelement sein. Es kann allerdings auch eine Werbung sein oder sowas. Das lässt sich nicht in Millisekunden ausdrücken, sondern Google hat dafür eben einen Wert definiert. Gut ist unter 0,1 und schlecht ist über 0,2.

Was außer den Core Web Vitals noch zählt

Das sind die drei Core Web Vitals, die jetzt initial veröffentlicht wurden. So grenzen die sich jetzt zu Page Speed ab. Weil ein paar könnte man ja damit unterbringen. Core Web Vitals ergänzen den Page Speed und umgekehrt. Also, man muss sich nach wie vor darum kümmern, dass man eine schnelle Website hat. Aber den Page Speed kann ich manipulieren. Der Paavo, der wollte mal, es ist schon ein paar Jahre her, da hat er beschlossen: Die advertising.de damals muss eine Page Speed von 100 haben. War aber mit dem Content nicht möglich. Aber wenn man die Stellschrauben kannte, konnte man die Page Speed von 100 da raushämmern. Auch wenn sie nicht wirklich so schnell war. Der Page Speed kann, wenn man weiß, wo man drehen muss, bis zu einem gewissen Grad manipuliert werden. LCP, FIT und CLS, wie ihr es gerade eben gesehen habt, ist fast unmöglich zu manipulieren. Also, da muss ich wirklich etwas tun, um es zu verbessern.

Trotzdem sollte man sich natürlich nicht rein auf diese Core Web Vitals verlassen. Nämlich wenn die Time-To-First-Byte oder das Start Render meiner Seite sehr langsam ist, kann der Largest Contentful Paint auch nicht sehr schnell sein, beziehungsweise wird genauso langsam sein. Die Abgrenzung ist jetzt mehr oder weniger, dass sich die Web Vitals quasi explizit mit der User Experience beschäftigen. Während eine Verbesserung des Page Speeds nicht unbedingt zu einer besseren User Experience führt. Weil wenn der Largest Contentful Paint oben gegebenenfalls asynchron oder per Lazy Loading nachgeladen wird, ist er halt immer noch nicht da, obwohl die Seite, rein technisch gesehen, sehr schnell lädt. Und auch vielleicht einen sehr hohen Page Speed Score bekommt. So.

Page Speed und Web Vitals

Erst mal kurz: Page Speed und Web Vitals. Da sieht man auch, dass Google da einen ziemlichen Druck auf die Röhre bringt. Die Web Vitals sind mittlerweile in Chrome Lighthouse eingebaut. Sie sind auf WebPageTest eingebaut. Sie sind in der Search Console zu sehen. Page Speed Insights gibt sie raus. Es gibt eine von Google entwickelte Chrome Extension für Web Vitals. Und Custom JS, das auf der WebDev da oben, also auf dieser URL von Google als Beispiel veröffentlicht wurde, dass sich direkt integrieren lässt. Das zeige ich aber gleich alles. Und das haben die innerhalb von drei Monaten alles rausgehämmert. Also, sie haben in drei Monaten das in die Search Console eingebaut. In allen Page Speed Tools, die sie unter den Fittichen haben und betreuen, eingebaut. Und in Google Chromeeingebaut. Es muss also ein bisschen wichtig sein, war dann mein Gedanke.

Auswirkungen der Core Web Vitals auf den E-Commerce

So, jetzt kommen wir erst mal zu den Auswirkungen auf E-Commerce. Bevor ich euch dann am Ende erkläre, also, wie man die Web Vitals wirklich beeinflussen kann. Also, Google ändert seine Algorithmen mittlerweile fließend. Allein 2020 gab es fünf bestätigte Core Updates, wahrscheinlich mehr. Die SEOs haben da so Tracker, wo sie dann sehen, wenn viele Rankings switchen oder sich stark verändern. Dass man davon ausgeht, dass Google dann ein Update fährt. Und das passiert mittlerweile jede Woche. Also, ich ignoriere das mittlerweile. Weil es ist kein: "Wir machen einmal im Jahr oder zweimal im Jahr ein Update." Wie das vor fünf Jahren noch war. Sondern das ist rolling. Die machen gefühlt tägliche Updates.

Der nächste Punkt: Google kommuniziert selten, welche Parameter bei der Bewertung verändert wurden. Also, sie haben es kommuniziert damals beim Mobile Gaddern, wie es genannt wurde. Bei Mobile First haben sie es kommuniziert. Das waren riesige Updates. Und sie haben es jetzt auch bei Web Vitals kommuniziert. Sprich, dass sie eine konkrete Timeline angeben. Wenn Google Updates macht, machen sie das nicht, weil sie SEOs ärgern wollen. Oder weil sie Webseiten-Betreiber ärgern wollen. Sondern sie machen es, um die User Experience zu verbessern. Die User Experience ist sehr viel. Also, Google möchte einfach das beste Ergebnis für eine Suchanfrage liefern. Und jetzt kann man sich natürlich fragen: "Was ist das beste Ergebnis?" Klar, das beste Ergebnis beantwortet in erster Linie die Frage nach dem Problem des Users. Und zwar zufriedenstellend. Das kennt jeder, das weiß jeder. Content trallala hopsasa und so weiter.

Weitere Facetten sind, wenn man die Quality Rater Guidelines gelesen hat, eben Expertisen, Relevanz, eine schnelle Website. Dass es mobile ist. Dass es zur Interaktion führt. Der Social Spread mag wichtig sein et cetera. Das sind alles Dinge, die mit reinspielen. Und das beste Ergebnis liefert nun zukünftig auch eine gute oder noch eine bessere User Experience als sie es jetzt schon tut. Bedeutet jetzt, wenn ich einen Shop betreibe, selbst wenn ich jetzt alle bekannten SEO-Hausaufgaben gemacht habe: Mein technisches Fundament stimmt. Mein Content stimmt. Meine Internet-Verlinkung ist schick. Und ich habe auch noch ein paar tolle Backlinks. Ist es durchaus möglich, dass, wenn ich starke Wettbewerber habe, dass ich in den Umfeldrankings verlieren kann. Wenn die Core Web Vitals auf schlechte User Experience hinweisen.

Und ich muss klipp und klar dazusagen: Ich kann jetzt nicht sagen: "Meine Startseite muss eben stimmen." Sondern es geht wirklich um jede URL. Dementsprechend nun ein paar Beispiele, die ihr garantiert alle schon kennt und alle schon wisst. Das ist dieses Mal nicht die berüchtigte Amazon-Studie, die es von 2002 gab. Sondern das ist von Adobe und von Medium. Ihr wisst und wir erzählen das-, jeder E-Commerce-Hoschi erzählt das da draußen. Hoschi war jetzt nicht unnett.

Also, 36 Prozent der User brechen den Besuch einer Website ab, wenn sie unattraktiv oder zu komplex ist. 40 Prozent wechseln zu einem Wettbewerber, wenn die Seite als zu langsam empfunden wird. Wenn die Bilder nicht laden, verlassen 39 Prozent die Website. Viel zu viel Inhalt: 38 Prozent sind weg. Schlechtes User Interface: 35 Prozent verlassen die Seite. Da gibt es eine große Adobe-Studie, ein riesiges PDF, das ich da durchgewälzt habe. Das wissen wir. Es ist nichts neues. Warum wissen wir es? Weil wir selbst so sind.

Christian Paavo Spieker: Mattsi, wie war damals die Amazon-Studie? Das waren, glaube ich, 100 Millisekunden, also 0,1 Sekunden, sind gleich ein Prozent weniger Conversion, also Umsatz im Online-Shop (Matthias Hotz: Genau.) irgendwie. Das war ja das, was alle hat damals so aufhorchen lassen. Wo alle gedacht haben: "Oh Gott, Amazon! Was ein Schwachsinn." Aber wir haben das auch in Zahlen und Fakten öfter gehabt. Wir haben ja sehr viele E-Commerce-Kunden. Und es ist wirklich so. Wenn wir mal einen Fehler hatten auf dem Shop oder irgendwas verlangsamt hat einfach, dann hat es wirklich massiv Umsatz gekostet. Deswegen ist es natürlich sehr ernst zu nehmen.

Matthias Hotz: Ja, das wissen viele. Aber viele ignorieren es dann doch irgendwie. Gerade wenn sie relaunchen oder redesignen. Genau, trotzdem. Ich habe mir dann einfach mal die-, nicht die erste, na ja, doch schon ein bisschen die erste Reihe angekuckt. Und habe mit dem Chrome Plug-in von Google dann einfach hier mal Cyberport: Die failen da komplett. OTTO failt zumindest beim Largest Contentful Paint. Die Müller-Website: furchtbar. Zehn Sekunden, bis der Largest Contentful Paint war bei einer Kategorieseite. Notebooksbilliger erstaunlicherweise haut voll durch. Also, die haben es im Griff. Real: Largest Contentful Paint auf der Startseite war 11,6 Sekunden. Zalando hat es auch richtig. Also sprich, da passt es. Das war eine Kategorieseite. Wie gesagt, ich habe jetzt Einzelseiten betrachtet. Aber das ist dementsprechend trotzdem aussagekräftig. Bei Obi, da wird es knapp. Und bei Lidl, da ist auch noch ein Fail. Also, die erste Reihe des E-Commerce, zumindest, was jetzt deutsche Hersteller oder deutsche Anbieter angeht, hat da durchaus noch Optimierungsbedarf. Und dementsprechend möchte ich jetzt eigentlich schon zu dem Thema kommen, wie ich dafür optimiere.

Wie ich meinen E-Commerce-Shop nach Google Web Vitals optimiere

Analyse des Status Quo

Ich muss erst mal mir den Status Quo zu Gemüte führen. Also, wie ich ja schon gesagt habe. Das reicht jetzt nicht, zwei, drei URLs zu betrachten. Es reicht auch nicht, jeden Seitentypen einmal zu betrachten. Weil, es können halt auch Bilder und Texte sein. Also, ich verwende ja nicht in jeder Kategorie dieselben Bilder et cetera. Die können unterschiedliche Dimensionen, unterschiedliche Größen haben. Dementsprechend muss man eine sehr breite Testabdeckung schaffen. Und das schaffe ich eben nur, wenn ich möglichst viele URLs ins Monitoring packe.

Der beste Weg ist RUM, also Real User Measurement. Das erkläre ich gleich. Der zweitbeste Weg ist quasi eine API-Anbindung von Page Speed Insights. Als Beispiel von einem Lighthouse oder von WebPageTest. Man kann auch die Chrome-User-Experience-Daten nehmen. Also, das heißt jetzt im Folgenden: CRUX. Der Chrome übermittelt ja, wenn ich dem bei der Installation zustimme Metriken an Google. Und da gehört auch die User Experience dazu. Was nicht so gut ist, ist sporadisches Testen via Web Tools. Weil das eben nur ein Snapshot ist. Und die User Experience kann sich eben täglich verändern. RUM, Real User Measurement, ist das Coolste, weil ich messe an meinen echten Usern. Dafür gibt es ein JavaScript, das ich in die Website integrieren kann. Und dann werden diese Metriken aufgezeichnet. Also der Largest Contentful Paint, der Cumulative Layout Shift und das First Input Delay kann ich mit JavaScript quasi abgreifen. Und kann es dann verarbeiten. Ich kann das in Analytics reporten. Ich kann mir mein eigenes Reporting dafür bauen. Ich kann das einfach mal in eine Datenbank reinschreiben et cetera. Interessant ist einfach, dass es mit echten Usern gemessen wird. Und ich eben auch, da ich ja weitere Daten abgreifen kann, wie den User Agent oder auch das Netzwerk, dass ich weiß: "Auf Desktop habe ich überhaupt kein Problem. Aber bei Mobile muss ich was tun." Der nächste Pferdefuß: Weil diese Metriken können natürlich je nach Endgerät abweichen. Das Problem ist halt, als Beispiel, dass ein Mittelklasse-Smartphone nicht so einen starken Prozessor hat wie mein Desktop-PC, der daheim steht. Und dementsprechend länger braucht, um das JavaScript zu passen. Ja, einfach mal im Kopf behalten.

Wichtig ist, jede Seite, die besucht wird, wird dann eben per JavaScript getrackt und die Daten reportet. Und ich kann mir dann schön rauslesen, wo ich problematische Seiten oder problematische Layouts habe. Es sind keine Laborwerte. Der Beispielcode, den gibt es auf den Seiten von Google. Das integriert man mehr oder weniger wie ein Tracking Port. Und jetzt kommt es: Google bewertet auf Basis von Real User Measurement, weil sie die Chrome-Daten haben. Also, Google weiß nachher ziemlich genau, ob 80, 90 Prozent der User eine gute User Experience haben oder nicht. Die kommen nicht einmal mit dem Bot vorbei und prüfen das, der in einem fetten Rechenzentrum steht, mit unheimlich Bandbreite. Sondern die nutzen wirklich die Chrome-Daten. Und dementsprechend wissen sie sehr gut, wie die Website performt. Ihr könnt euch das angucken unter crux.run. Da hat einer ein Frontend gebaut, wo man auf die User-Experience-Daten zugreifen kann. Also, diese Chrome-User-Experience-Daten stehen in einer Google-Datenbank offen im Netz. Ist ein bisschen, wenn man jetzt nicht der Datenbank-Gott ist, ein bisschen schwierig, sich jetzt ein Query zu schreiben. Aber über crux.run könnt ihr quasi einfach mal ein bisschen rumspielen und gucken, ob eure Seite da mit dabei ist.

Christian Paavo Spieker: Matts, wie steht im Wettbewerb mit den js-360 oder mit den Google-Analytics-Zahlen? Da hat man ja auch ein Real User Measurement drin quasi. Ist es dann-? Meinst du das Gleiche, oder?

Matthias Hotz: Nein, das ist nicht das Gleiche. Weil die Google-Analytics-Daten werden über den Google Pixel, also über den Analytics Pixel ermittelt. Der muss nicht aligned sein mir den Crux-Daten. Weil der Analytics Pixel ja gegebenenfalls erst später im Quelltext geladen wird. Oder noch gar nicht zur Verfügung steht. Und der Chrome im Grunde ja von vorne bis hinten dafür zuständig ist, die Website zu rendern. Und dementsprechend die exaktesten Daten hat. Dementsprechend sind diese Zahlen sind sehr wertvoll. Und ich gehe auch davon aus, dass deshalb Google diese kostenlos zur Verfügung stellt. Der zweite Link, der auf web.dev geht, da seht ihr dieses JavaScript, dass man da einbauen kann. So, das ist natürlich aufwendig. Ein JavaScript in eine vorhandene Website reinzumachen. Eine eigene Datenbank aufzusetzen, das zu prüfen et cetera. Es gibt natürlich aber APIs dafür. Der Nachteil einer API ist, dass es erst mal eine synthetische Messung ist, die nicht immer ganz realen Environments entspricht. Also, ich habe Laborwerte. Aber es ist sehr einfach hinzubekommen.

Die Pagespeed API von Google ist kostenlos. Also, ihr müsst darauf achten, dass es die Pagespeed V5 ist. Die WebPageTest API ist bis zu einem gewissen Grad kostenlos. Und da kann man die Daten einfach abrufen. Da kommt ein JSON zurück und dann mache ich damit irgendwas. Und man kann eben über diese CRUX-Daten-. Die kann man ebenso per API abrufen. Kann damit die Daten anreichern. So hat man ein sehr breites Spektrum. Und kann vor allem vielleicht auch Seiten testen, die nicht so häufig aufgerufen werden. Die nicht in der Search Console reported werde, weil sie vielleicht gar keine Klicks abbekommen. Oder keine Impressions abbekommen. Wir haben uns dafür jetzt erst vor Kurzem quasi die komplette Lighthouse API angezapft. Wir haben eigene Chrome-Instanzen aufgesetzt, wo Lighthouse drin instanziert wird. Und wir holen uns die Daten dann ab.

In Chrome lässt sich ja wahnsinnig viel einstellen, wenn man das als Entwickler weiß. Also, ich kann das Netzwerk verlangsamen, Netzwerks shorten. Ich kann simulieren, dass ich ein iPhone benutze. Und lauter so Zeug. Kriege dann Wahllaborwerte, aber effektiv schnell viele Daten raus. Und kann einfach auch mal einen Test fahren. Diese Daten sind in der Regel ausreichend dafür, um dann mit der Optimierung zu beginnen. Wie optimiere ich denn jetzt?

Probleme deutlich machen

Also, wenn ich die Daten erfasst habe, muss ich mir erst mal einen Überblick verschaffen, wo ich Probleme habe. Die Page Performance Basics, wie ich schon oben erwähnt habe, müssen passen. Also, Time-To-First-Byte. Wenn eine Website 280 Requests hat und fünf Megabyte an Daten überträgt, dann brauche ich nicht bei den Web Vitalsanfangen. Weil dann ist die User Experience eh schon nicht so geil. Wichtig ist, dass man auf den initialen Viewport sich fokussiert. Ich habe es da ein bisschen markiert. Also, die Grafik ist etwas schlecht. Aber ich hoffe, man kann es erkennen. Der initiale Viewport ist oben eben da, wo diese Bühne-, der Mountainbiker soll das sein. Und unten wird alles irgendwie nachgeladen. Also unten ist noch gar nichts fertig, während der initiale Viewport oben schon fertig ist. Das ist gut. Das bedeutet einfach, der User kann sich da oben-. Das ist halt ein Sekundenbruchteil. Also, der User kann sich oben schon zurechtfinden. Und unten fange ich dann langsam an nachzuladen, während der User das Initiale schon sieht. Deshalb muss man zukünftig Page-Performance-Optimierung sozusagen-, an Web Vitals oder Usability-Optimierung ein bisschen anders herangehen als man das vielleicht kennt. Und vor allem muss man eben die drei Web Vitals, also Largest Contentful Paint, Cumulative Layout Shift und First Input Delay einzeln betrachten. Also, die lassen sich eigentlich nicht wirklich gemeinsam optimieren.

Optimieren des Largest Contentful Paint

Fangen wir mal mit dem Largest Contentful Paint an. Ich haben oben oder vorhin schon gesagt: Das sind hauptsächlich Blockelemente. Also, im HTML gibt es zwei Arten von Elementen: Inline, das ist so Span zum Beispiel. Oder Ahref ist ein Inline-Element. Inline bedeutet, es fließt. Also, sprich ich kann drei Span-Elemente oder drei R-Elemente hintereinander machen. Die sind in einem File. Habe ich ein HTML-Blockelement, wie zum Beispiel ein Div oder ein P, dann wird eine neue Zeile erzeugt. Genau um die geht es. Es können Background-Images oder Images sein, Videos. Alles, was den größten Platz im initialen Viewport beansprucht. Also, wie gesagt: Es muss kein Bild sein. Es muss kein Video sein. Es kann durchaus auch Text sein.

Dann herausfinden, welches Element das ist. Das kann natürlich von Seite zu Seite unterschiedlich sein. Das kann durchaus auch mal das Logo sein. Oder eben das Video, das da reinkommt. Und dann eben herausfinden, was das Laden des Elements verlangsamt. Ich habe hier rechts mal so ein Wasserfall-Diagramm gemacht. Hier oben, also, ich hoffe, man kann es erkennen: Ich lade eine Seite. Dann werden erst mal fünf Fonts geladen. Danach werden ungefähr 200.000 CSS-Dateien geladen. Und dann kommen dazu JavaScript. Die Frage ist jetzt: Wie viel davon brauche ich denn für den initialen Viewport? Wahrscheinlich nur einen Bruchteil. Font ist zwar nett, aber er kann auch später laden. Weil, ich kann vielleicht auf einen installierten Font zurückgreifen. Diese ganzen CSS- und JavaScript-Files: Da sehe ich ein Polyfill und ein TrackingJS. Ich sehe da oben ein Video-CSS, eine Colorbox-CSS. Das heißt, das wird alles für diese initialen Viewport, nicht gebraucht. Dementsprechend muss ich mich jetzt aus Usability-Sicht und aus Web-Vitals-Sicht eben fragen: "Was tut das da?"

Wichtig wäre jetzt, dass da oben natürlich, die HTML-Datei. Aber die wird sowieso als erstes geladen. Dann vielleicht das Logo des Shops. Die Bühne, das Bild, der Slider, whatsoever. Das muss als erstes geladen werden. Weil das ist das, was den Largest Contentful Paint nachher schnell macht. Third-Party-Zeugs, Skripte et cetera, ganz ans Ende packen. Ich frage mich eh, warum Leute das für eine gute Idee halten, ihren Analytics Pixel an dritter oder vierter Position zu laden. Oder ihren Google Tag Manager. Weil, ob ich eine Tracking Impression verliere, oder ob der User eine schlechte Experience hat. Also, meine Entscheidung wäre da ziemlich einfach.

Wenn man das rausbekommen hat oder wenn man jetzt hier plötzlich 25 CSS-Dateien sieht, die alle gar nichts mit der Seite zu tun haben, dann muss man die Ladereihenfolge verändern. Das ist im Grunde was ganz Einfaches. Man geht in das HTML rein und sagt dann: Ich lade zukünftig als erstes dieses CSS, dann das JavaScript. Und den Rest lade ich wann anders. Zum Beispiel am Ende. Ich höre auf, aus CDNs Sachen einzubinden. Was wir oft sehen ist, zum Beispiel, dass Google Fonts bemüht wird. Ist ein extra Request. Und der quasi das ganze Ding verlangsamt. Also, ich muss die Fonts abholen. Und dann muss der Font switchen. Und das sind alles Dinge, die ich da eigentlich nicht brauche. Und im Grunde muss man erst mal nur die Ladereihenfolge verändern. Ich muss meine Seite gar nicht so viel schmaler machen. Ich muss nicht abspecken oder sonst irgendwas. Ich muss nur die Dinge, die da oben stehen, als erstes laden.

Optimierung des First Input Delay

Beim First Input Delay ist es ein bisschen anders. Da ist immer JavaScript dafür verantwortlich. Also, wenn kein JavaScript in der Seite ist, wird es keinen First Input Delay geben. Oder sehr selten wird es einen geben. Weil der lädt durch. Und wenn es da ist, ist es da. Und dann kann ich es bedienen. Wenn aber sehr viel JavaScript geladen wird, kann es zum Blocken der User-Eingabe führen. Jetzt ist so die Frage: Wie viel JavaScript ist denn viel? Ein Megabyte JavaScript sind 500 Buchseiten, wenn ich es ausdrucke. Kein Mensch braucht so viel JavaScript. Also, nicht, wenn ich nicht eine Rich Application benutze, wie Facebook oder-, wo echt viele Dinge passieren müssen. Aber ja, die Entwickler werfen gern mit sehr viel JavaScript auf Webseiten, um irgendwie triviale Probleme zu lösen, die man selber programmieren könnte. Dementsprechend muss man erst mal gucken, wie viel JavaScript wird denn überhaupt auf die Website geladen. Einfach so die Hausnummer: Unter ein MB. Und am besten unter 200 Kilobyte, wenn es komprimiert ist, wäre gut. Alternativ, wenn ich auf das JavaScript nicht verzichten kann, muss ich mich fragen: Brauche ich im initialen Viewport oben Javascript? Wenn nein, dann lade ich es ganz am Ende. Dann lade ich es, nachdem die Bilder, die CSS, Grafiken, alles durchgeladen ist. Dann kann ich das JavaScript laden.

Sollte ich JavaScript da oben brauchen, weil da vielleicht ein Slider ist oder sonst irgendwas. Dann kann ich diesen kleinen Part rauslösen. So einen Slider kann man mit fünf bis zehn Kilobyte programmieren. Den kann ich dann da oben laden. Und fünf bis zehn Kilobyte, da braucht der Browser auch nicht sehr lange. Aber wenn er halt 500 Buchseiten jedes Mal interpretieren muss. Es geht Zeit ins Land. Dann sehen wir auch oft, dass JavaScript, das auf der Seite gar nicht so dringend gebraucht wird, geladen wird. JavaScript, das für den Checkout verantwortlich ist, das für eine Google-Maps-Integration verantwortlich ist, wo es aber gar kein Maps auf der Seite gibt. Einfach weil es für den Entwickler viel einfacher ist, einfach immer alles zu laden. Weil dann steht es zur Verfügung. Man muss sich nicht kümmern. Möchte ich dann dort Maps verwenden, ist es da. Aber dass es zu einem erhöhten Payload und zu langsameren Webseiten führt, ist nicht immer so ganz im Blick.

Im Idealfall teilt man eben, wie ich schon gesagt habe, das JavaScript in maximal zwei bis drei Files auf. Früher hat man als Page-Speed-Performance-Gesichtspunkt gesagt: Je weniger JavaScript Files, umso besser. Das ist auch nicht verkehrt. Aber wenn ich JavaScript dringend brauche, für diesen initialen Viewport da oben, dann muss ich eben aufteilen. Ich nehme dieses kleine Schnipselchen für ganz oben, lade das früh. Und den Rest lade ich am Ende. Ich kann auch, wenn es schwierig ist, mit defer laden. Es gibt mittlerweile Anweisungen, die man dem Script Tag als Attribut mitgeben kann. Da ist einer zum Beispiel: defer. Der sagt dem Browser: "Hey." Also, wir gehen davon aus, das JavaScript steht sehr weit oben, aber es hat das Attribut: defer. Dass der Browser dann dieses Tag sieht, das JavaScript auch sieht. Aber er sieht dann: defer. Und defer sagt dann quasi: "Hm, ist nicht so ganz wichtig. Lade das, wenn du Zeit hast. Interpretiere es, wenn dein Load-, also, wenn der Thread frei ist, also, wenn die CPU weniger belastet ist sozusagen. Und damit verhindere ich auch einen schlechten First Input Delay.

Optimierung des Cumulative Layout Shift

Dann kommen wir zum letzten, das ist der Cumulative Layout Shift. Ich habe es euch ja in dem Video demonstriert. Das ist quasi das Zucken der Website. Dafür kann alles mögliche verantwortlich sein. Also, Bilder, IFrames, Youtube-Videos, die integriert sind. Adds, aber auch ein Font Swap gehört dazu. Man muss rausfinden, was für das Zucken verantwortlich ist. Und dann darangehen.

Warum kommt es denn zu dem Zucken? Das ist jetzt vielleicht auch interessant. Also, der Browser kriegt eine HTML-Seite so vorgesetzt, wie ihr eine Buchseite lest. Ihr fangt oben in der ersten Zeile an zu lesen. Und lest dann bis unten durch. Und dann kommt ihr eben an eine Stelle, wo ein Bild referenziert wird, in dem Fall. Im Buch wäre dort jetzt ein Bild abgebildet. Aber der Browser sieht jetzt erst: "Hm, hier ist ein Bild. Das muss ich laden." Diesem Bild kann ich initial eine Dimension mitgeben. Per CSS zum Beispiel sagen: „Dieses Bild, das dort geladen wird, hat 400 x 600 Pixel“. Dann reserviert der Browser den Platz dafür und lädt das Bild da drin.

Gebe ich allerdings keine initiale Dimension mit, was man so machen kann, ist falsch. Dann weiß der Browser ja nicht, wie groß das ist und reserviert diesen Platz nicht. Und wenn dann das Bild geladen wird, braucht es ja den Platz. Und dann fängt es an zu zucken. Und er holt sich diesen Platz. Eine Herangehensweise, um das zu fixen, ist, Bilder, IFrames, allen embedded Elementen schon initial eine Größenangabe mitzugeben. Man weiß, wie groß das YouTube-Video ist. Man weiß, wie groß der AdSense-Integration-Banner ist. Und man kann diesem Element, dass das umschließt, dann schon sagen, per CSS Dial: Width ist gleich 768, Height ist gleich 90 Pixel. Und damit hat man das Problem im Grunde schon gelöst.

Außer es dreht sich zum Beispiel um Fonts. Bei Fonts ist es ja leider oft so, das sehen wir auch oft, dass-. Natürlich möchte man sein Custom Font verwenden. Aber dann wird der fünfmal geladen. Einmal in sehr, sehr bold, dann in kursiv, dann in normal und dann noch in einer leichten Variante. Und leider sind so Fonts halt nicht klein. Dementsprechend muss man da erst mal gucken, wie viel Fonts hat man überhaupt. Wie groß ist die Font-Datei? Ist sie ordentlich gezippt et cetera. Und wenn man jetzt nicht um seine fünf Fonts rumkommt, kann man den Font Switch optional machen. Das heißt dann, wenn einer eine schnelle Verbindung hat und die Fonts schnell geladen werden, sieht er die Fonts gleich. Der andere fällt auf die Systemschriftart zurück, die man definiert hat im CSS. Und würde sie dann ab der nächsten Seite sehen. Aber zumindest habe ich dann diesen Cumulative Layout Shift eben nicht. Sondern ich habe eine stabile User Experience.

So, ich glaube, das war es. Ha! Juhu! Gerne Fragen, gerne Diskussion et cetera. Es war jetzt sehr kompakt. Wichtig: Beobachtet das Thema. Schaut auch, wie Google das nächstes Jahr spielen wird. Verfolgt es auf ein paar SEO-Blogs und so weiter. Weil, es ist durchaus möglich, dass es einen recht großen Impact haben wird. Und dass diese Initiative eben weiter ausgebaut wird. Und schaut euch mal in der Search Console eure eigene Domain-Datei an. So, das war es.

Umfrage: Nutzung von Google Web Vitals unter den Teilnehmern

Angela Meyer: Vielen lieben Dank, Matts und Paavo, für eure Insights. Und zwar jetzt starten wir mit der Fragerunde. Ihr könnt gerne eure Fragen über das Bedienpanel beim GoToWebinar jetzt stellen. Wir haben jetzt noch Zeit. Genau. Und in der Zwischenzeit würde ich auch eine kurze Umfrage für die Teilnehmer starten, ob sie bereits ihren E-Commerce Shop nach Google Web Vitals optimieren. Ich starte hier mal die Umfrage. Gebe euch ein paar Sekunden Zeit. Und dann habt ihr auch Zeit, eure Fragen zu notieren. Also, unsere Teilnehmer-.

Christian Paavo Spieker: Dann bin ich ja mal gespannt, was rausgekommen ist.

Angela Meyer: Ja, also, wir haben bereits-. Circa 70 Prozent der Teilnehmer beschäftigen sich mit Google Web Vitals. Aber auch um die 20 Prozent fokussieren sich noch nicht darauf.

Christian Paavo Spieker: Man muss ja auch an dieser Stelle dazu sagen, Google sagt natürlich, dass es 2021 oder wann auch immer irgendwie in den Algo einfließt. Wir wissen nicht, zu welchem Bestandteil es heute schon drin ist. Das sagt Google natürlich nicht. Weil wir denken schon, dass es der Page Speed und alles, was eine Rolle spielt, jetzt die Core Web Vitals, dass es heute schon eine gewisse Relevanz hat. Weil, das ist eine logische Schlussfolgerung, wenn User Experience gut ist. Google kann ja mittlerweile die Daten alle messen, Mattsi hat es ja schon gesagt, über die Google Chrome Bar. Über die Google Browser und diverse Extensions und Erweiterungen. Und deswegen ist ganz, ganz wichtig-. Ja, also, Need for Speed nennen wir das ja immer. Also, zu schnell gibt es ja bekanntlich nicht.

Fragen

Angela Meyer: So. Also, vielen Dank an die Teilnehmer für eure Antworten. Jetzt kamen auch schon die ersten Fragen rein.

Welches Chrome Plug-in habt ihr verwendet, als ihr eben die Seiten von Cyberport, Notebooks et cetera angeschaut habt?

Matthias Hotz: Also, den Namen weiß ich nicht. Aber es gab nur eines. Es ist tatsächlich auf web.dev verlinkt. Und wenn ihr in dem App Store von Chrome guckt und sucht mal nach Web Vitals, müsste es gleich der erste Treffer sein. Ist auch ein ganz simples Plug-in. Es zeigt echt nur die drei Werte an. Und hat dann eben einen roten und einen grünen oder einen gelben Indikator oben drin.

Chrome scheint seit der Version 84 im Performance-Bericht der DevTools eine Experience-Funktion anzubieten, anhand deren man die Layout-Shift-Probleme analysieren kann. Habt ihr damit schon Erfahrung?

Matthias Hotz: Ja, das gibt es öfter. Also, ich persönlich jetzt nicht. Ich nutze den Lighthouse Report innerhalb von Chrome nicht so stark. Ich nutze den Coverage Report manchmal. Aber das sind genau die Daten, die nachher wahrscheinlich in den CRUX mit eingehen. Weil, wieso sollte der Chrome zweimal die Daten erheben et cetera. Also, ich halte diese Chrome Developer Tools und diese Tools, die was über den Health Status meiner Website sagen, für sehr gut. Und ich empfehle, die zu benutzen. Also, immer mit ein bisschen Skepsis.

Den Zahn muss ich immer ziehen. Wenn man in einer Firma sitzt und hat irgendwie eine 100-, oder eine Gigabit-Leitung oder eine 100Mbit-Leitung, ist das nicht real. Weil, die meisten Leute haben diese Leitung zuhause nicht. Da haben sie vielleicht 16 Mbit oder vielleicht mal 20 oder 30 Mbit. Oder wenn ich mit LTE oder 3G unterwegs bin, habe ich eben auch diese Leitung nicht. Deshalb empfehle ich auch immer, entweder in Chrome zu throtteln, was man einstellen kann, wenn man zum Beispiel ein anderes Device auswählt. Oder per WebPageTest dann mal den Test von einem anderen Ort zu machen als von seinem privaten Chrome auf dem starken Rechner in der Firma.

Angela Meyer: Okay. Dann würde ich jetzt mal noch die-, kam mal noch eine Frage auf zu der Adobe-Studie. Da hattet ihr ja besprochen, dass 36 Prozent der User brechen den Besuch einer Webseite ab et cetera.

Wo findet man die Adobe Studie? Habt ihr da einen Link?

Matthias Hotz: Ich müsste sie nochmal raussuchen. Also, die war auf der Adobe-Seite noch drauf, aber ansonsten würde ich mal nach Adobe-User-Experience-Studie suchen. Von 2015 war die, glaube ich. Also, es war so eine der größten, ist zwar jetzt auch schon ein paar Jahre her, aber die halt repräsentativ war. Und vor allem von einer Firma durchgeführt wurde, die sich in diesem Gebiet ein bisschen auskennt.

Christian Paavo Spieker: Das geht ja alles immer Richtung Speed-Thema. Und wir haben natürlich auch schon viele Relaunches gehabt, irgendwie auf Shop-Systemen. Jetzt muss man noch dazu sagen, die Web Vitals oder gerade so von den Ladereihenfolgen mit den JavaScript-Dateien, ist natürlich bei Standardsystemen, wie jetzt ein AEM, also Adobe Experience Manager oder ein Hybris oder gerade Magento ist da ganz schlimm.

Da lädt der erst mal eine ganze Mülldeponie vorne ab. Nicht ganz so leicht zu beeinflussen. Aber oft haben wir gemerkt, wenn wir mehr Speed drauf hatten, hat sich das schon signifikant in den Umsätzen oder der Conversion Rate auch ausgewirkt. Das muss man ganz klar sagen. Auch wenn wir immer dachten, in der Agentur: Der Shop ist ja schnell, auch von den Messwerten. Das ist ja genau der springende Punkt im Endeffekt. Wenn man dann wirklich auf der User-Basis misst, vom User aus, da gibt es ja wirklich viele, gerade im Mobile-Bereich, die dann doch relativ langsam sind. Und das kostet wirklich Conversion. Und deswegen: Es sagen ja alle Studien immer nur das Gleiche. Ja, ich sage immer: "Wenn es langsam ist, ist es doof, ja." Kostet Umsatz, ja. Und wie gesagt, ich glaube, gerade jetzt mit dem Mobile: Wenn man sich mal die Mobile-Zahlen anschaut. Ich habe ja vorhin gesagt, 96 Prozent war DAMALS unser Mobile Share im E-Commerce. Der ist natürlich heute-. Also, es ist immer Mobile höher als Desktop. Also, sprich, da spielt natürlich die Geschwindigkeit eine sehr, sehr große Rolle, ja. Also, zu schnell gibt es einfach nicht, ja. Und ob das dann Cloudflare ist mit einem CDN, oder so was man da vorgeht, wenn man ein bisschen internationaler unterwegs ist. Oder noch zur Bildoptimierung. Das kann natürlich schon sehr, sehr gut helfen.

Matthias Hotz: Ja, aber Cloudflare kann ja auch nicht helfen, wenn dein CLS oder dein FID nicht funktionieren. Also, da bringt es nichts. Das hat Google gemerkt. Das ist richtig. Cloudflare ist ein gutes System und es hat seine Daseinsberechtigung. Aber es muss nicht bedeuten, dass meine User Experience besser wird, weil das eben auch andere Faktoren hat. Und das-.

Christian Paavo Spieker: Die wird nicht schlechter.

Matthias Hotz: Nein, aber es ist trotzdem-. Das macht diese Web Vitals interessant, da es dieses Mal nicht auf die nackte Geschwindigkeit geht, sondern wirklich auf die gefühlte Geschwindigkeit.

Angela Meyer: Gerne könnt ihr jetzt noch weitere Fragen stellen. Oder auch im Nachgang an unsere Experten. Matts, du kannst bitte weiterklicken. Gerade kam nichts rein. Dann mache ich hier noch auf unsere weiteren Webinare aufmerksam, die wir wöchentlich veranstalten. Und nächste Woche geht es rund um SEA. Und zwar um das Thema: Feed-Aufbau als Grundlagen zu Creative Excellence und nutzerorientierte Anzeigenschaltungen im SEA. Mit unseren SEA-Experten Christian Rainer und Dominik Langner aus dem Team von Paavo. Da freuen wir uns auch drauf. Meldet euch gern jetzt an. Alle Informationen findet ihr im diva-e-Newsroom. Und du darfst noch einmal weiterklicken. Dann danke ich euch zwei für eure Zeit und für eure Insights. Und ein Dank an die Zuschauer, die uns heute zugehört haben. Ich wünsche euch noch einen schönen Tag. Und bis zum nächsten Mal.

Christian Paavo Spieker: Danke.

Matthias Hotz: Ciao.