Ab Mai 2021 wird Google bei der Bewertung von Webseiten drei Faktoren in erheblicher Weise berücksichtigen:
- Cumulative Layout Shift (CLS)
- Largest Contentful Paint (LCP)
- First Input Delay (FID)
EntwicklerInnen und AutorenInnen, die sich mit diesen Werten nicht beschäftigen, laufen Gefahr, dass ihre Seiten an Ranking verlieren. In dieser Präsentation am WordPress Meetup Berlin Ende Januar 2021 gibt WordPress Developer und Podcaster Phil Marx einen Einstieg in die Bedeutung dieser Begriffe, wie man seine eigene Seite prüfen kann und einige grundsätzliche Verbesserungsvorschläge.
Die Fragen und Antworten am Ende der Präsentation sind nicht in diesem Podcast enthalten, sind aber in den Show Notes verlinkt. Ebenso die Slides.
Zielgruppe: SEO, Entwickler, Fortgeschrittene
Links
- Slides der Präsentation
- Video Präsentation auf WordPress.TV (inkl. Fragen & Antworten)
- Nerdtalk Podcast und Webfalken von Phil Marx
Credits
- Musik von Northern Dusk
- Bilder von Phil Marx und Rajeshwar Bachu
Transkript
Vielen lieben Dank, dass ihr alle so zahlreich da seid. Ich hätte echt nicht mit so vielen Besuchern gerechnet und vor allem nicht mit so vielen InteressentInnen. Freut mich total, dass ihr jetzt hier so in dieser grossen Masse teilnehmt. Maja hat es gerade eben schon gesagt: Das ist ein etwas kerniger Vortrag. Jedoch gar nicht mal von der Komplexität, also ich glaube nicht, dass das jetzt total kompliziert wird und nur Programmierer oder SEO Experten das hier verstehen werden. Aber bei bestimmten Dingen brauche ich einfach eure Konzentration, weil die Bewertungskriterien von Google sind in Zukunft, zumindest die, die jetzt im Mai 2021 kommen werden, gar nicht mal so leicht verständlich sondern es ist ein bisschen technischer und schon fast ein bisschen mathematisch. Schauen wir einfach mal gemeinsam darauf. Erst mal ein paar Worte zu mir. Ich bin Phil Marx. Ich bin gelernter Fachinformatiker, arbeite schon seit 2009 mit WordPress, habe dort meinen eigens selbst geschriebenen Blog mal irgendwann auf WordPress überführt und seit 2018 betreue ich nun Kundenwebseiten und unterstütze sie in allem, was sie dort so benötigen.
Was haben wir heute vor? Damit einfach alle ein bisschen abgeholt sind – Ich kenne ja euren Level nicht oder wie weit ihr jetzt schon in Sachen SEO up to date oder mit der Technik seid. Deshalb gibt es einen ganz kurzen Überblick über die Geschichte von Google. Keine Sorge, wir fangen nicht in der Garage von Larry Page an. Aber ein paar wichtige Infos, warum wir überhaupt hier so gemeinsam sitzen. Zudem gibt es noch ein paar wichtige Grundlagen und dann steigen wir auch gleich in das Thema dieses Vortrages ein, nämlich die sogenannten Core Web Vitals, bestehend aus Cumulative Layout Schift, Largest Contentful Paint und First Input Delay. Das war dann so ein bisschen die Theorie und dann bekommt ihr auch noch was an die Hand, wie ihr diese Core Web Vitals selber identifizieren und ermitteln könnt.
Und am Ende nochmal so ein paar generelle Tipps, wie man im Grunde dort zum Beispiel die Werte verbessern kann. Also nochmal so eine kleine Geschichte über Google und Google verfolgt ja im Grunde schon seit vielen Jahren den Fokus auf User Experience. Ich meine, wir sind mal gestartet, da hat Google einfach nur Keywords aufgenommen, hat diese indiziert und hat dann auf Basis diesen Keywords irgendwie versucht, ein möglichst gutes Suchergebnis zu liefern. Aber bereits um 2011 begann Google damit, die User Experience mehr in den Vordergrund zu stellen.
Also dem Benutzer immer mehr, immer bessere Suchergebnisse für den Suchbegriff zu liefern und nicht nur einfach mechanisch Seiten zu indizieren und dann irgendwie nach Keyworddichte Inhalte auszuspielen. Sondern tatsächlich verstehen, was möchte der Besucher bzw. der Suchende gerade und den qualitativ höchsten verbunden mit der höchsten Zufriedenheit des Ergebnisses. Das ist ja das, was Google immer wieder verfolgt. 2011 begann Google auch Contentfarben rauszusortieren. 2013 ging es dann tatsächlich schon mit dem Verständnis von einzelnen Worten los – mit einem Hummingbird Update – damit Google schon ein bisschen in Kontext setzen konnte: «Okay, was hat der Suchende eigentlich in die Suchzeile eingegeben und was sucht er vermutlich?»
Und 2015? Da ging es auch schon los, dass Google die mobile Nutzerfreundlichkeit in den Vordergrund gestellt hat. Bei der Recherche war ich selber ein bisschen überrascht. Tatsächlich ist das jetzt schon sechs Jahre her, dass Google gesagt hat: «Okay, wir stellen jetzt die Darstellung und Usability auf Mobilgeräten in den Vordergrund anstatt der Desktop-Webseite. Und 2015 kam noch so ein bisschen KI hinzu, sodass die Suchbegriffe noch besser verstanden werden konnten. In den letzten Jahren hat das dann richtig an Dynamik gewonnen.
Gerade 2018 war es dann so, dass Google mit dem Mobile-First Indexing Update gesagt hat: «Okay, mobile Webseiten werden jetzt auch primär zum Indizieren herangezogen.» Das heisst, Google hat einen deutlich grösseren Fokus auf Mobilgeräte aber betrachtet natürlich die Desktopgeräte auch immer wieder. Aber wir kommen nachher noch zum ??Pass. Leider?? da sieht man das ganz gut an Zahlen, dass Mobilgeräte die Geräte sind, womit heutzutage gesucht wird. Und deswegen legt Google natürlich einen grossen Wert darauf, dass die Suchergebnisse bzw. die Seiten hinter den Suchergebnissen auf Mobilgeräten möglichst optimal funktionieren. Und darauf zielt auch das sogenannte Core Web Vital Update an, welches jetzt im Mai 2021 veröffentlicht werden soll. Wir hatten es gerade eben schon imm Ausblick mal ganz grob gesehen, was diese Core Web Vitals sind. Die sperrigen Begriffe Cumulative Layout Schift, Largest Contentful Paint und First Input Delay hat Google eigentlich ganz schön zusammengefasst. Eben in den Schwerpunktthemen wie loading, Interactivity und Visual Stability.
Also der Benutzer soll ein gesteigertes, positives Benutzererlebnis erfahren, wenn er ein Suchergebnis besucht in den Bereichen: Ladezeit, Interaktivität oder auch Interaktion mit der Webseite und visuelle Stabilität. Dazu kommen noch ein paar weitere Aspekte, die sind in der Grafik auch nochmal aufgezeigt, aber tatsächlich sind die Core Web Vitals das, worauf jetzt in Zukunft besonders geachtet wird. Warum das eigentlich alles? Warum sind mobile Webseiten auf einmal total angesagt?
Ich habe hier eine kleine Grafik von Statista herausgesucht: Bereits Mitte 2015 war schon ein Drittel des Webverkehrs von mobilen Geräten und jetzt bis ins dritte Quartal 2020 hinein sind wir bei 50%. Spontan würde man sagen, ist das ein sehr moderater Wert. Aber selbst wenn man diesen Wert nimmt, die Hälfte der dort erfassten Webseitenbesuche sind per Mobilgeräte passiert und Google selbst bringt Statistiken raus, die darstellen, dass allein 80 Prozent ein Smartphone benutzen und knapp 60 Prozent davon nutzen sogar zwei Geräte.
Das Spannende an der ganzen Sache ist, dass diese Grafik von 2015 ist.
Das heisst die ist schon extrem alt und die Zahl wird sich ganz bestimmt in der Folgezeit noch erhöht haben. Bevor wir das Thema mit den Core Web Vitals verstehen können, müssen wir noch zwei, drei Dinge klären, damit die Auswirkungen und Zusammenhänge der Werte verständlicher sind. Da möchte ich mit euch ganz kurz einmal in einen HTML-Quellcode hineinschauen. Das ist jetzt der etwas zusammengefasste Quellcode von der Google Webseite und die Web Entwickler und bestimmt auch die, die das schon mal ab und zu gemacht haben, wissen, dass so ein HTML-Konstrukt in drei Bereiche unterteilt werden kann. Es gibt einerseits den Header, da stehen ein paar Metadaten drinnen.
Der Titel der Webseite, aber auch Informationen zum Design und zur Interaktion der Seite. Dann gibt es den Body. Da ist in der Regel der Inhalt drinnen. Alles was wir sehen an Text und Bildern und ähnliches ist grösstenteils im Body angesiedelt. Und dann gibt es den Footer. Ich habe gerade eben schon gesagt, im Header sind z.B. Referenzen drinnen. Wir haben jetzt hier hervorgehoben, zum Beispiel eine JavaScript Datei. Hier wird also von einer externen Adresse eine JavaScript Datei eingebunden. JavaScript ist ja eine Skriptsprache, womit man Interaktionen oder auch Dynamik auf eine Website bringen kann. Das bedeutet ja, dass Dinge sich automatisch verschieben oder auf Mausklick irgendwas aufklappt oder Slider, die sind ja auch so ein typischer Fall im JavaScript Bereich. Hier im Header sind auch noch ein paar Style Angaben, also CSS Angaben. CSS Dateien sind ja dafür da, dass das Design einer Webseite sehr vereinfacht auszudrücken. Farben, Strukturen, Ausrichtungen von Überschriften, Texten, Bildern, aber auch Containern, wo man dann wiederum Inhalte reinpacken kann.
Die Definition der Grösse dieser Container, die Anordnung dieser Container all das macht man mit CSS Dateien und wir sehen im Footer entsprechend auch noch ein paar JavaScript Dateien. Warum tut man so etwas? Warum packt man JavaScript Dateien und CSS Dateien in den Kopf, aber kann sie offensichtlich auch in den Footer packen. Wenn nämlich ein Web-Browser diesen HTML Quellcode interpretieren möchte, um dann am Ende eine Webseite anzuzeigen, muss er das in der Regel von oben nach unten tätigen.
Das heisst, er liest diesen gesamten Quelltext ein und fängt dann an, auch eingebundene Script Dateien und auch die CSS Dateien abzuarbeiten und zu interpretieren und dann den Code – der da drinnen festgehalten ist – auszuführen oder in irgendeiner Form mit der Webseite zu interagieren. Die Skripte, die im Header eingebunden sind, die werden natürlich sehr schnell und sehr früh gelesen, ausgeführt und interpretiert. Und alles was im Footer unten ist, wird erst sehr verspätet ausgeführt, währenddessen schon der gesamte Body und damit der gesamte Inhalt eigentlich angezeigt ist und auch die wichtigsten CSS Dateien bereits aus dem Header gelesen und auch interpretiert wurden.
Das heisst, es besteht durchaus eine Abfolge. Die Daten im Header werden zuerst mit einer gewissen Priorität abgehandelt, währenddessen im Footer die Dateien, die dort eingebunden sind, verspätet ausgeführt werden, nämlich wenn schon andere Aktionen vorher erfolgt sind. Das ist alles technisch jetzt sehr vereinfacht ausgedrückt, aber es ist ganz wichtig zu verstehen: Es gibt zwei verschiedene Ausführungsbereiche, denn das wird nachher nochmal bei der Bewertung der Core Web Vitals ganz wichtig. Dann möchte ich ganz kurz den Begriff «Viewport» mitgeben.
Wir werden jetzt hier in diesem Vortrag zwei oder dreimal über den sogenannten Viewport sprechen, mit einem Viewport ist einfach der sichtbare Bereich in einem Mobilgerät gemeint. Das heißt eigentlich, dass wenn ihr eine Webseite aufruft und den Inhalt seht, der den gesamten Screen in Anspurch nimmt, das ist der Viewport. Einfach im Hinterkopf behalten, wird aber gleich nochmal interessant werden. Und wir sollten auch im Hinterkopf behalten: «Wie bewertet Google eigentlich mobile Webseiten, wie kriegt der Google Bot eigentlich heraus, wie eine Webseite auf einem mobilen Gerät performt?» Da schweigt natürlich Google mit welcher Engine sie da herangehen bzw. mit welcher Logik sie da herangehen.
Es häufen sich die Vermutungen, dass es aktuell die Engine eines Motorola Moto G4 ist, mit langsamer Netzanbindung. Bis vor kurzem war es noch ein Nexus 5, das war ja ein Gerät von Google. Und jetzt kam vor kurzem auch in den Entwicklertools von Google die Engine des Moto G4 mit hinein und deswegen gibt es sehr gute Vermutungen, dass dieses G4 involviert ist. Selbst wenn es das nicht ist, ist es gar nicht mal so schlecht, dass als Orientierung zu nehmen. Denn es ist ein Mobiltelefon mit einem beachtlichen Alter.
Es ist knapp fünf Jahre alt und hat eine recht geringe Displaygrösse. Das heisst, wenn wir das im Hinterkopf behalten, unsere Seiten auf eine gute Ansicht und auf gute Core Web Vitals für ein Motorola Moto G4 optimieren, dann haben wir die Seite wahrscheinlich schon generell ganz gut optimiert. Je besser das Display, je schneller die CPU, umso besser natürlich auch die Anzeige. Aber wenn wir schon auf geringerer Hardware bzw. geringerem Gerät gut emulieren können und die Seite gut aussieht, dann wird das bei besserer Hardware natürlich umso besser funktionieren.
Soviel also zur Theorie. Kommen wir zum ersten Core Web Vital, nämlich der Cumulative Layout Shift. Ich hab es mal versucht, es zu übersetzen, nämlich zusammengerechnete Layout Verschiebung. Das ist etwas krudes Deutsch, aber trifft es eigentlich ganz gut. Der Cumulative Layout Schift schreibt nämlich die Verschiebung von Inhalten nach dem initialen Design. Das heisst, wenn die Webseite einmal geladen ist und dann sich auf einmal Inhalte doch nochmal verschieben. Warum eigentlich?
Zum Beispiel weil Inhalte dynamisch nachgeladen werden, wie durch JavaScript oder ähnliches. Oder vielleicht irgendwie Widgets nochmal resizen, weil sie irgendwie in der falschen Größe definiert wurden und dann irgendwie festgestellt wird: «Ach Gott, ich werde ja auf ein Mobildisplay angezeigt und dann restrukturiert sich die gesamte Seite nochmal neu.
Oder was natürlich auch sein kann, dass grössere Bilder wie Headerbilder noch nachgeladen werden. Zum Beispiel habe ich hier eine etwas grössere Dateigrösse und Sie haben vielleicht in ihrer Deklaration in der HTML Definition keine Größenangaben mitbekommen und somit lädt auf einmal dieses Headerbild nach und drückt den Inhalt nach unten. Das sind typische Cumulative Layout Shifts. Ich habe eine kleine Demo mitgebracht. Ich bin ganz gespannt, da Videos ja immer so eine Sache in Powerpoint sind aber ich glaube es funktioniert hervorragend. Nehmen wir ein Beispiel:
Hier ist eine Order Conformation und da habt ihr es schon gesehen. Wir können gleich nochmal zurückloopen und das nochmal machen. Es ist also eine Bestellbestätigung gewesen und auf einmal ist ein Inhalt aufgetaucht. Der Benutzer klickt eigentlich auf «No go back», er will das also gar nicht bestellen, aber auf einmal hier oben, was nachgerückt ist, hat sich alles nach unten verschoben und er klickt versehentlich auf Submit-Order und generiert so eine versehentliche Bestellung. Das ist natürlich jetzt das Extrembeispiel an der Stelle, aber es zeigt halt sehr gut auf, was dieser Cumulative Layout Shift ist, nämlich, dass sich Inhalte verschieben und sich dadurch die User Experience verändern kann.
Ich hatte gerade eben schon gesagt, es ist eine Summe von Layout Shift und von gewissen Metriken und Cumulative suggeriert es ja auch schon -eine kumulative-, also etwas zusammengefasst und somit gibt es hier tatsächlich ein bisschen Mathematik. Ja, keine Sorge, es ist nicht so vertiefend und letztlich, ich habe ja diese Metriken nicht erfunden, sondern Google hat die erfunden, also müssen wir alle hier gemeinsam durch. Wird aber nicht so schlimm. Die Berechnungsgrundlage für so ein Cumulative Layout Shift und überhaupt für ein Layout Shift ist:»Um wieviel Prozent nimmt dieses bewegte Element im Viewport ein?» Wir werden das nochmal sehen und dann wird das ein kleines Stück praktischer.
Das ist dann die sogenannte Impact Fraction und dann stellt sich natürlich auch die Frage um wieviel Prozent verschiebt sich denn dieses Element? Wenn das z.B. irgendwie ein kleiner Satz ist, dann ist womöglich die Impact Fraction relativ klein, da es nur sehr schmal auf dem Screen ist. Es besteht einen Unterschied, wenn es ein grosser Absatz ist. Und natürlich ist es auch ein Unterschied, ob dieser Inhalt irgendwie ein paar Pixel verrutscht oder sogar um die Hälfte des Viewports. Diese Werte werden dann pro Element -was sich irgendwie verschiebt, springt oder was auch immer- multipliziert und dann einfach für jedes einzelne Element aufaddiert. Auch hier hab ich ein kleines Beispiel mitgebracht bzw. Google hat auch ein schönes vorbereitet.
Wir sehen hier zwei Demo-Viewports und wir sehen auf der linken Seite einen Demo-Text der 50% des Viewports einnimmt und der wird nach unten verschoben. Nach dem Verschieben von Ursprungslage bis zur Endlage haben sich 75% des Screens auf einmal verändert. Irgendwas hat sich da eben in der Ansicht verändert. Das ergibt also eine Impact Fraction von 0.75. Dieser Inhalt, der wurde um 25 Prozent verschoben und das gibt dann eine Distance Fraction von 0.25. Ich hatte ja erwähnt, dass es multipliziert wird und dadurch bekommt man ein Layout Shift für dieses einzelne Element. Das heisst, wenn wir hier ein bisschen Mathematik anwenden, kommen wir auf 0.18. Das ist jetzt der Layout Shift sozusagen für dieses Element. Merkt euch die 0.18, das wird jetzt gleich in der nächsten Folie nochmal ganz interessant. Wir haben hier also einen Inhalt, 50% wird nach unten verschoben und das ergibt Layout Shift von 018 fast 0.19. Layout Schifts werden aufgrund von User Interaktionen nicht berücksichtigt. Das heisst, wenn jemand auf den Button klickt und dann verschiebt sich was oder so, dann ist das ja was legitimes, dann ist das etwas, was auch gewollt ist. Die werden dann nicht in der Summe berücksichtigt.
Ein kleiner Unterschied an der Stelle: Natürlich kann man nicht unendlich Verzögerung annehmen. Google nimmt als Basiswert 500 Millisekunden, d.h. man klickt auf einen Button und wenn innerhalb von 500 Millisekunden irgendetwas passiert, z.B. das Layout sich verändert oder Elemente neu angeordnet werden, dann zählt das nicht in den Layout Shift mit hinein. Wie bewertet Google das denn jetzt eigentlich? Google kommt hin, bewertet alle Elemente, berechnet dort wie gesagt mit diesen Fractions die Anteile und summiert am Ende auf. Google sagt ein Cumulative Layout Shift – also der summierte Layout Shift von allen sich bewegenden Elementen – kleiner gleich 0.1 ist eine gute Experience, alles kleiner als 0.25 benötigt improvement und über 0.25 ist eine poor Experience.
Das bedeutet – alleine jetzt gerade dieses Beispiel, was ich gerade gezeigt hatte mit 0.19- ist nicht gut, das rankt Google schon runter. Wie kann ich so einen Cumulative Layout Shift vermeiden? Da gibt es diverse Varianten. Auslöser sind immer in der Regel dafür in irgendeiner Form CSS Dateien oder JavaScript Dateien, die in das Layout eingreifen und in irgendeiner Form Elemente neu anordnen. Daher ladet diese möglichst früh im Header und auch da möglichst früh oder bindet womöglich den Quelltext direkt ein, damit das möglichst schnell verarbeitet werden kann. Wenn ihr Bilder einsetzt oder auch generell Content Boxen habt, also div. Container oder ähnliches in eurem HTML Quellcode, dann definiert dafür fixe Größenangaben, damit da auf jeden Fall der Platz schon reserviert ist und das nicht dynamisch erst angepasst werden muss.
Generell vermeidet dynamische Layout Anpassung mit JavaScript, das ist sowieso nichts schönes. Stattdessen bietet da CSS echt viele Möglichkeiten, Einfluss auf das Layout zu nehmen und dynamisch auch auf verschiedene Bildschirmauflösungen zu reagieren und so ganz ohne JavaScript und irgendwelche Bibliotheken für ein tolles Design und für eine neue tolle Anordnung von Elementen zu sorgen. Und sofern ihr Animationen nutzt auch da schaut mal, ob ihr anstatt JavaScript lieber CSS nutzt. CSS hat sich in den letzten Jahren sehr weiterentwickelt und ihr könnt mit CSS unfassbar viel machen und auch so Elemente anordnen, skalieren, bewegen und ähnliches. Und ihr seid da nicht auf JavaScript angewiesen.
Das bringt auch Vorteile in der Bewertung von Cumulative Layout Shift, da Google Animationen tatsächlich weniger stark wertet, wenn es zu Verschiebungen kommt. Ihr seht unten rechts auch immer wieder Links dazu. Da könnt ihr dann draufklicken bzw. diese abtippen. Diese Sites werden auch veröffentlicht, es gibt natürlich jeweils in einzelnen Kapiteln noch deutlich mehr Informationen dazu. Kommen wir zu dem zweiten Core Web Vital. Das ist der Largest Contentful Paint. Auch hier habe ich es mit einer schlechten Übersetzung probiert: Grösstes Inhaltsergebnis darstellen. Ja das triffts am Ende auch auf den Punkt, es bezeichnet nämlich die Zeit, bis das grösste Element der Seite im initialen Viewport geladen ist. Auch hier gibt es ein sehr schönes Beispiel von der CNN Webseite. Da sieht man den Ladeprozess von links nach rechts und grün hervorgehoben sieht man immer das, was als das grösste Element sozusagen auf der Website identifiziert wurde. Auf dem ersten Blick ist es eine Breadcrumb Navigation und dann sieht man in der Mitte, dass die Überschrift das grösste Element der Website ist und dann quasi ganz zum Schluss wird ein Teaserbild geladen und das ist dann das grösste Element auf der Website.
Und Google möchte natürlich für den User, für denjenigen, der irgendwo sich auf einer Webseite dann bewegt, dass das zentrale Element möglichst früh zur Verfügung steht. Deswegen wird ein solches Ladeverhalten eher schlecht bewertet, weil eben das zentrale Element sehr spät dargestellt und geladen wird. Natürlich hat Google auch positive Beispiele z.B. bei sich selber. Und auch hier sieht man den Suchbegriff dann als erstes und bei den Ergebnisseiten ist es so, dass dann die Beschreibung des Suchergebnisses sehr schnell und sehr früh geladen wird, nämlich an der richtigen Stelle, im richtigen Moment. Es werden zwar dann noch einzelne Bilder, Bildinhalte nachgeladen und ähnliches, aber das zentrale Element, das grösste Element der jeweiligen Seite ist sehr früh da und dementsprechend bekommt man in diesem direkten Vergleich sehr gut mit, was denn da als Largest Contentfull Paint gemeint ist, welchen Zweck Google damit verfolgt und warum es wichtig ist, dass hier dieser Inhalt möglichst früh erscheint. Wie bewertet Google das?
Nämlich nach Zeiträumen. Wenn das grösste Element in weniger als zweieinhalb Sekunden geladen ist, bewertet Google das als gut. In weniger als vier Sekunden needs improvement und mehr als vier Sekunden poor. Jetzt könntet ihr euch zurücklehnen und sagen «Ach vier Sekunden, das ist ja gar nichts. Also ich meine, Webseiten sollen ja möglichst in anderthalb Sekunden oder zwei Sekunden laden und mit VDSL 50 es ist ja alles ganz easy.» Ja, aber bedenkt, wir sind hier im mobilen Bereich unterwegs mit schlechter Netzwerkabdeckung. Die Emulation funktioniert voraussichtlich mit 3G, nicht mit LTE oder ähnlichem.
Das heisst zwei Sekunden für eine grössere Headergrafik sind da schon kernig. Aber das muss man schaffen. Also unterschätzt diese Werte nicht. Wie kann man den Largest Contentful Paint verbessern? Ordnet eure Elemente, wenn ihr die Webseiten baut, möglichst fix im Viewport an, anstatt dass sie die wieder durh Java Scripte oder ähnliches dynamisch nachjustieren lässt. Layoutdesigns von CSS wie Flex Box und CSS Grid helfen hier auf jeden Fall. Da kann man sehr schön für verschiedene Auflösungen, verschiedene Anordnung von Objekten auch gut steuern. Wir hatten es gerade mit dem schlechten Largest Contentful Paint. Sorgt dafür, dass eure Headerbilder und eure Teaserbilder und überhaupt alle Bilder, die den grössten Teil des Viewports einnehmen, dass die möglichst schnell geladen werden. Sorgt für geringe Parteigrössen. Bei Bildern könnt ihr im HTML-Quellcode auch das Source Set benutzen.
WordPress setzt das zu grossen Teilen -wenn ihr Bilder aus der Mediathek einfügt- automatisch ein. Das Source Set ist dann dafür da, dass verschiedene Bildergrössen zur Verfügung stehen und dann in Abhängigkeit der Displaygrösse geladen werden, sodass dann z.B. auf ein Display was gerade mal 600 oder 300 Pixel breit ist, nicht das Bild mit 1200 Pixel Breite geladen wird, sondern eher ein kleineres, was dann natürlich auch eine kleinere Dateigrösse mit sich bringt. Wichtig: Nutzt Caching, wenn Inhalte nicht schnell genug abgerufen werden können, weil z.B. die Datenbank zu langsam oder der Zusammenbau der Website mit den ganzen PHP Dateien etwas zu lange dauert, dann hat das natürlich auch Auswirkungen, wann welcher Inhalt angezeigt wird. Bei ganz grossen Seiten ist Content Delivery Network auch sehr hilfreich.
Aber das bringt dann auch wieder eigene Herausforderungen mit sich. Es besteht natürlich auch die Möglichkeit, dass ihr kritische Elemente vorladet, das bietet ja der Browser an und man hat auch Möglichkeiten, Ressourcen vorzuladen und so im Grunde im Hintergrund schon Bilder herunterladen zu lassen, weil man zu fast 100 Prozent bereits weiss, der Besucher wird jetzt diese Webseite als nächstes aufrufen. Wenn ihr also in irgendeiner Form eine Customer Journey aufzieht und ihr eure Besucher so steuern wollt, dass der Besucher sicher auf die nächste Seite navigieren wird, dann könnt ihr ja bereits schon das grosse Bild herunterladen, somit ist es schon im Zwischenspeicher.
Dann kann es natürlich sofort angezeigt werden, als dass es dann erst runtergeladen werden muss oder auch heruntergeladen wird, wenn es gebraucht wird. Auch der Link-preload bringt auch Herausforderungen mit sich. Seid vorsichtig im Umgang damit und seid vorsichtig mit dem Datenvolumen eurer Besucher. Und was natürlich auch eine Sache ist, ladet nicht kritische CSS Dateien und JavaScript Dateien im Footer. Ist irgendwie auch ganz klar, da die die Webseiteninhalte zumindest im initialen Viewport ganz schnell geladen werden. Wenn ihr dann in irgendeiner Form noch JavaScript Dateien habt, die womöglich am Ende irgendeine Interaktion mit einer Webseite oder einem Element auf der Webseite machen oder so etwas, dann muss das nicht am Anfang zwingend geladen werden. Dann schreibt das in den Footer hinein, denn es geht beim Largest Contentful Paint darum – wie es gerade schon gesehen habt – dass die Webseite und die zentralen Inhalte möglichst schnell zur Verfügung stehen. Und je weniger der Browser selber vorher noch lesen, interpretieren und anordnen muss, desto besser.
Kommen wir zum dritten Core Web Vital, nämlich der First Input Delay oder auch «Mano, mein Browser hakt». Der First Input Delay lässt sich noch am besten übersetzen: die Verzögerung bis zur ersten Eingabe.
Und zwar beschreibt der First Input Delay die Verzögerung eines Browsers zwischen Interaktion und Reaktion. Vielleicht kennt ihr das selber: Ihr klickt einen Link auf eurem Tablet oder auf einem Mobiltelefon und dann passiert erst mal kurz nichts. Und irgendwie so nach einer Sekunde lädt dann die Seite. Das ist der First Input Delay. Warum hackt das überhaupt? Nun, auch hier technisch sehr vereinfacht ausgedrückt muss man sagen der Browser -wir hatten es gerade bei dem Quellcode- muss JavaScript Dateien und CSS Dateien verarbeiten und es gibt einen sogenannten «main thread» in Browsern. Das heisst, es gibt einen eigenen Prozess auf eurem Handy oder auf dem Tablet, der eben dafür da ist, eben diesen gesamten Quellcode zu interpretieren, JavaScript Dateien einzulesen, auszuführen und was weiss ich nicht alles.
Der «main thread» kann aber nur eine Sache gleichzeitig machen. Das heisst, wenn der gerade damit beschäftigt ist, umfangreiche JavaScript Dateien auszuwerten, umfangreiche CSS Dateien zu lesen und irgendwie das Design zurecht zu basteln, dann kann der in dem Moment den Klick auf den Link nicht verarbeiten. Der «main thread» kriegt zwar mit, dass da jemand geklickt hat, aber kann ihn gerade nicht verarbeiten, weil er gerade dabei ist, die 500 Kilobyte Datei JavaScript zu rendern. Behaltet immer noch im Hintergrund, dass wir noch immer auf einem Mobiltelefon von vor fünf Jahren unterwegs sind. Das hat eben nicht High Performance. Das ist der Auslöser für den First Input Delay. Ich hab das nochmal grafisch mitgebracht. Da müssen wir jetzt nicht im Detail reinblicken.
Ich sehe gerade, dass da die Quellenangabe fehlt, auch das ist übrigens von der Webseite, die hier unten rechts verlinkt ist «Web.dev/fid» Also kurz für First Input Delay. Hier sieht man in grau die Network Requests, also die Anfragen. Der lädt den Quellcode der Webseite, findet da eine externe JavaScript Datei, lädt die, dann findet man vielleicht noch eine CSS-Datei die muss er laden und interpretieren und das sind diese grauen Balken und in gelb unten sieht man den sogenannten main thread. Da ist er dann nämlich dabei, diese Daten zu lesen und zu interpretieren. Wir sehen zum Beispiel in den letzten grauen Balken, da scheint eine sehr grosse Datei zu sein, die er herunterlädt erstmal. Dann fängt er natürlich auch an, die relativ schnell zu interpretieren.
Danach sehen wir hier Browser received first user input. Das heisst, mitten in der Verarbeitung des «main threads» klickt der User auf den Link. Der Browser ist aber gerade damit beschäftigt, diese Datei zu laden, kann keine Aktion lostreten und kann das erst machen, wenn dieser «main thread» erst mal die Abarbeitung der JavaScript Datei z.B. fertig hat. Und das ist in grafischer Form noch einmal dargestellt warum manchmal der Browser hackt. Das ist keine schöne User Experience und genau deswegen möchte Google natürlich diese Verzögerung möglichst gering halten. Wie bewertet Google das? Die Zeit zwischen Klick und Reaktion kleiner oder gleich 100 Millisekunden bewertet Google als gut, bis zu 300 Millisekunden als needs Improvement und alles was darüber ist als poor.
Also schon auch sportlich, wenn man bedenkt, dass das auch alles auf einer schwachen Systemplattform ausgeführt werden soll, nämlich auf einem 5 Jahre altem Smartphone. Wie kann man darauf Einfluss haben? Haltet eure Seitenstruktur einfach! Je einfacher so eine Webseite strukturiert ist, je schlanker so ein Quellcode ist, desto schneller lässt sich das durch den Browser interpretieren. Vermeidet komplexe JavaScript und CSS Dateien, weil je komplexer so eine JavaScript Datei, je komplexer eine CSS-Datei, desto mehr und länger braucht der Browser auf seinem «main thread» diese zu lesen, zu interpretieren, auszuführen und desto weniger schnell kann er auf Interaktion agieren.
Wenn ihr übergrosse Zeilen habt und die Möglichkeit habt, dann teilt grosse Dateien z.B. irgendwelche exorbitant grossen JavaScript Dateien oder CSS Dateien oder sowas auf kleinere Dateien auf. Auch hier werden diese in einzelnen Schritten heruntergeladen und dann atmet der Browser jedesmal mal kurz durch und hat dann natürlich die Möglichkeit den Link-Klick z.B. zu verarbeiten oder einen Klick auf dem Formular, Feld oder was auch immer, als dass er da noch weiter geblockt wird, um eine grosse Datei zu verarbeiten.
Generell vermeidet externe Inhalte wie Like Buttons oder ähnliches. Auch die haben Einfluss auf die Ladezeit, da diese häufiggroße Scripts mitbringen. Ihr fügt vielleicht nur eine kleine Codezeilen ein, aber dahinter werden unzählige Kilobytes an Daten nachgeladen. Auch das hat dann natürlich Einfluss auf den «main thread», der das alles am Ende dann doch nochmal verarbeiten muss. Ladet unkritische Inhalte erst im Footer, denn es geht darum, die Webseite erst einmal Interaktionsfähig zu machen. Und wenn im Nachhinein etwas nachgeladen werden muss, dann ist das nicht schlimm, macht aber die Seite schnell interaktionsfähig.
Jetzt haben wir diese drei Bereiche kennengelernt. Darauf wird sich Google ab Mai 2021 konzentrieren und das auch mit in die Bewertung der Suchergebnisse mit aufnehmen. Jetzt stellt sich die Frage wie könnt ihr eure eigenen Core Web Vitals ermitteln? Da gibt es zwei zentrale Anlaufstellen: einerseits Lighthouse, vielleicht kennt das der ein oder andere von euch, das ist in den Entwicklertools drinnen von Chromium basierten Browsern, also z.B. Google Chrome oder Microsoft Edge oder Opera. Die setzen alle auf Chromium und darin sind die Entwicklertools inkludiert.
Ich hab da auch nochmal die Shortcuts mit aufgeführt, dann könnt ihr diese dort öffnen. Ich habe einen Screenshot gemacht, wo man die Entwicklertools findet. Es ist unter weitere Tools, die haben nämlich die Entwicklerstool schon ganz gut versteckt, klickt aber da gerne mal in eurem Browser auf das Zahnrad bzw. drei Punkte und klickt euch durch zu die Entwicklertools. Da könnt ihr dann nämlich eine Auswertung generieren. Ihr könnt da Quelltexte einsehen und Netzwerkleistung einsehen. Es ist eine unfassbar gute Anlaufstelle, um einfach die eigene Webseite besser zu verstehen. Aber ganz am Ende gibt es da auch das Lighthouse und dort könnt ihr dann -ganz kostenlos- aus dem Entwicklertools heraus einen Bericht erstellen. Dieses analysiert dann die Seite. Ihr werdet dann auch feststellen, dass der Browser die Webseite auf Handyformat resized und, dass die Netzwerkgeschwindigkeit testweise simuliert runtersetzt, um dann tatsächlich diese Engine laden zu können, um das mit einer alten Mobil-Hardware simulieren zu können.
Am Ende gibt es dann eine Auswertung, neben vielen anderen Auswertungen, die einem auch gute Tipps geben, worauf man so achten kann, um die eigene Webseite noch besser zu machen. In Sachen Excess Ability, Suchmaschinenoptimierung, Progressive Web Apps ist dort eben auch der First Contentful Paint und der Largest Contenful Paint mit drinnen und der First Input Delay wird dort bezeichnet als Time to Interactive. Ihr könnt das aber auch selber im Browser simulieren. Also für sich selber mal ein Gefühl bekommen, wie performt meine Seite eigentlich auf diesem simulierten Mobilgerät. Dafür geht ihr erneut in die Entwicklertools, aber anstatt auf Lighthouse zu klicken, sucht nach einem kleinen unscheinbaren Button, hier ist er jetzt gelb umrandet.
Damit könnt ihr eine mobile Ansicht aktivieren und dann simuliert euer Browser eine mobile Ansicht. Ich hab dann auch die Möglichkeit oben in der Ansicht eine Engine auszuwählen. In unserem Fall ist jetzt Moto G4 ausgewählt und ihr habt dann neben dem Zoom Faktor, der jetzt hier auf 100 prozent steht, auch die Möglichkeit die Performance eines Gerätes auszuwählen. Hier steht jetzt z.B. einfaches Mobilgerät. Das heisst, hier wird Rechenstärke des Handys ein bisschen runtergeregelt um einfach zu simulieren: Wie könnte das dann tatsächlich am Ende auf dem Moto G4 mit schwacher CPU und mit schwacher Auswertung aussehen?
Die Alternative falls ihr keinen Browser habt oder es nicht nutzen möchtet, gibt es auch von Google selber, die sogenannten Page Speed Insides. Die Adresse steht hier und da könnt ihr dann auch eine Webadresse eingeben und da arbeitet sich das durch und liefert dann auch hier die entsprechenden Daten.
Hier sehen sie deutlich schlechter aus, da muss man dann tatsächlich ran. Sowohl Lighthouse als auch die Page Insides liefern da auch Impulse, wie man alles verbessern kann, was die Auslöser sind, dass es zu schlechten Werten kommt. Ich habe jetzt viel über Optimierungen und ähnliches gesprochen und wie kann man die einzelnen Bereiche verbessern. Erstens möchte ich kurz mitgeben: Verlauft euch bitte nicht. Also klammert euch bitte jetzt nicht krampfhaft daran fest alle eure Werte auf grün zu bekommen.
Wenn ihr es hinbekommt, umso besser, es gibt aber gerade in der WordPress Welt viele Herausforderungen, dass das echt eine Herausforderung werden kann. Es geht jetzt tatsächlich eher darum, ein Bewusstsein dafür zu schaffen, wie Google mobile Inhalte zukünftig bewerten wird und was die Denkweisen dahinter sind. Und womöglich könnt ihr dann zukünftig das zumindest in der Auswahl von Themes, Plug-Ins oder ähnliches einfliessen lassen oder sofern es hier dann doch Coder unter uns gibt, das dann auch in die Entwicklung mit einfliessen lassen. Es gibt aber auch ein paar Faktoren, die einfach auch generell sehr wichtig sind, um auf alle diese Bereiche natürlich einzuzahlen und wirklich ein gutes Ergebnis abzuliefern, was gar nicht an den einzelnen Komponenten hängt.
Letztlich lässt sich alles zusammenfassen unter: «Habe einen guten Unterbau». Also wenn euer Webserver oder eure Datenbank nicht schnell ist, dann könnt ihr noch so viel optimieren, es wird nichts bringen. Dann muss der Host möglicherweise gewechselt werden. Setzt nur notwendige CSS oder JavaScript Dateien ein. Also häufig lassen sich auch Dinge nativ erledigen. Wie erwähnt, CSS bietet ganz tolle Möglichkeiten Animationen zu machen oder JavaScript bietet an sich schon Möglichkeiten Dinge einzublenden, auszublenden und ähnliches. Da brauch es nicht nochmal externe Bibliotheken wie jQuery oder andere. Generell vermeidet externe Bibliotheken, weil das macht die Seite natürlich immer grösser und hat immer mehr Einfluss auf Ladezeiten, hat Einfluss auf Dateigrösse, hat Einfluss womöglich auf das Layout und das Design. Damit zerreisst ihr euch alles, wenn ihr da nicht den Blick darauf habt. Vermeidet natürlich unnötige Plugins oder Multi Purpose Themes, da ladet ihr euch die Seite unnötig voll. Multi Purpose Themes sind für viele Zwecke einsetzbar.
Ihr ladet eines herunter und es lässt sich quasi alles daraus basteln. Von Agentur Seite über Blog, über Fotoblog, über WooCommerce Shop aber diese Themes müssen auch die Kompatibilität, die Möglichkeiten und auch die Design Definition für alles mitbringen. Das heisst, sie sind in der Regel auch recht überladen. Optimiert die Bilder für das Web, mit Source Sets und natürlich auch Dateigrössenoptimierung und haltet generell den Code der Webseite schlank. Da erzähle ich glaub ich allen nichts Neues. Es ist aber nicht falsch, immer wieder mal darauf hinzuweisen. Wenn es jetzt einige Plug-In Nutzer gibt. Diese Plugins werden die Probleme nicht lösen, aber sie sind zumindest ein Ansatz. Es gibt Caching Plugins wie z.B. WP Rocket oder Auto optimize, die Einfluss haben wie das Ladeverhalten von CSS Dateien und JavaScript Dateien ist.
Man kann da auch Einfluss nehmen, dass bestimmte Dateien im Footer geladen werden oder verzögert geladen werden. Wenn man weiss, was man tut, kann man damit ein bisschen Einfluss nehmen. Genauso kann man mit dem Plugin Asset CleanUp Einfluss nehmen, welche JavaScript Dateien auf welcher Unterseite in WordPress geladen werden. Wenn ihr also einen Slider oder so etwas nur auf einer Seite benötigt, ist es ja durchaus zielführend diese JavaScript Datei nur auf einer Seite einzufügen. Dann könnt ihr das mit z.B. Asset CleanUp machen.
Aber auch hier nochmal der Disclaimer: Kein Plugin, kann einen schlechten oder umfangreichen Code jetzt massiv verbessern. Die Basis muss richtig sein, die Basis muss ordentlich sein und erst wenn die Basis stabil, schlank und belastbar ist, erst dann kann man natürlich anfangen darauf Optimierungen zu setzen. So, das war ja fast eine Punktlandung mit meinen geplanten 45 Minuten. Aber natürlich auch inhaltlich glaub ich ganz schön kernig. Ja und viel Input. Ich hoffe, es gab bei euch keinen Input Delay. Okay, das war ein spontan erfundener Wortwitz und manchmal ein guter. Vielen Dank erst mal, dass ihr so intensiv dabei gewesen seid und wenn ihr Fragen habt, stehe ich gerne zur Verfügung und versuche die jetzt alle zu beantworten.