PageSpeed Insights - Chrome Dev Tools - Lighthouse

So, die Geschwindigkeit einer Seite ist ja wichtig, aber Google scheint die Schraube immer weiter anzuziehen. Aktuell sind sie bei bestimmten Dingen bei 20ms! Derzeit am wichtigsten ist der FCP (First Contentful Paint), wird es aber wohl nicht mehr lange sein. Es gibt wohl einen Wechsel hin zu FID (First Input Delay). Die Begründung: Dem User sei es nicht so wichtig, ob schon alles geladen ist, der fängt auch schon an zu scrollen und lesen, wenn die Seite noch lädt. Genau das ist der FID, also der Zeitpunkt, wo eine Seite normal auf Eingaben, Maus-Scroll oder Wisch-Gesten reagiert, egal ob sie fertig geladen ist oder nicht.

So, um das zu erfassen für sich als User gibt es die "PageSpeed Insights", da wird das aufgelistet. Seit einigen Wochen auch als Beta in der Google Search Console.

Gerade beim FID ist Google aber nicht in der Lage, diese Daten per seinen Google-Bot zu erkennen, denn der scrollt oder wischt nicht, der ruft nur die Webseite ab. Die Daten stammen aus dem "Chrome User Experience Report", der seinerseits nichts anderes ist, als übermittelte Telemetriedaten von Chrome Desktop und Mobile.

Warum ich das scheibe? Weil die "PageSpeed Insights" in dem Bezug schon veraltet sind. Die arbeiten noch mit Version 4, der "Chrome User Experience Report" mit dem in Chrome integrierten Lighthouse und das ist dort in Version 5. Und ich sehe deutliche Unterschiede. Anfangs dachte ich noch, mein FID von 620ms liegt am Rechner, am Browser, wegen der Auslastung, aber nein, denn das SEO-FOrum hat einen Wert von 120ms. Komisch bei mir. Selbst eine leere weiße Seite hat über 500ms.... Hm, muss da wohl mal suchen warum, habe keine Ahnung. Die Search-Consele gingegen, die Lighthouse v4 Benutzt, die sagt 20-80ms, also schon ein deutlicher Unterschied, wobei die anderen erfassten Werte quasi +-10ms bei beiden identisch sind.

Was ich bisher weiß, um den FID zu senken, mal abgesehen von Server:

CSS ausmisten und komprimieren (komprimieren alleine ist gut, aber reicht nicht)

JS ausmisten und komprimieren (komprimieren alleine ist gut, aber reicht nicht)

Im CSS auf Transition oder Transform verzichten (macht oft eh keinen Sinn. z.B. LazyLoad. Warum soll das Bild animiert geladen werden, wenn das doch eh im Hintergrund ist und keiner sieht?)

Neu ist auch die Barrierefreiheit. Bisher bezog sich die auf Element-Größen, also Schriftgröße von Links, Buttons und so, also ob man die eindeutig anklicken kann oder vielleicht aus Versehen einen falschen Link erwischt.. Neu ist die Auswertung der Farben, also Hintergrund und Vordergrund, ob die passen, gut leserlich sind. Dazu dient aktuell der Standard "WCAG 1.4.3" (WCAG = "Web Content Accessibility Guidelines" oder auch zu Deutsch "Richtlinien für barrierefreie Webinhalte"). Erstaunlich, was da so alles bemängelt wird, wo ich selbst absolut kein Problem sehe und ehrlich gesagt nach der Änderung auch keinen Unterschied ?!

Schön ist aber, dass sowohl Chrome als auch Firefox in der Console mit Inspektor oder Elements nun auch anzeigen, wie gut ein Farbwert ist. Wählt man also eine Farbe, dann kommt da ein rotes X für "schlecht", ein einfacher grüner Haken für "gut" und ein doppelter Haken für "sehr gut". Wie gesagt, ich habe meine Farbwerte nun auf einigen Seiten geändert und bin nun bei "gut". Lighthouse meldet eine bessere Barrierefreiheit, ich sehe aber nicht wirklich einen Unterschied.

Ebenfalls neu die Auszeichnung von Links und vor allem verlinkten Bilder per "aria-label". Auch das geht aus dem WCAG hervor. Es dient der Vorlesung von Links oder eben der Beschreibung von Zielen für Screenreader. Auch das hat Lighthouse 5 nun neu in der Auswertung.

So, ich muss zu meinem Ersten Absatz noch mal nachsetzen. Da fehlt was bzw. war angedacht, steht aber nicht da. Das was da nun steht ist nicht korrekt.

Der FCP (First Contentful Paint) ist extrem wichtig. Das ist der Moment, wo der Browser die ersten Pixel einer Seite anzeigt, also der Beginn der Darstellung. Jeder will es ja schnell haben und jeder kennt es wohl auch. Man ruft eine Webseite auf und wartet erst mal, sieht eine weiße Seite. Nach 5 Sek fragt man sich ob die überhaupt geht und dann Sekunden später, schwupp ist alles da. So, das ist also der FCP. Der Punkt, wann die erste Ansicht kommt. Das lässt sich verbessern durch bessere Server, bessere Scripte und z.B. auslagern von JS und CSS.

Dann gibt es da noch den FMP (First Meaningful Paint), den hatte ich oben vergessen. Das ist der Moment, ab wann die Inhalte eigentlich fast vollständig vorhanden sind. Hier fehlen dann aber eventuell noch Scripte und Bilder oder anderer Content, der per async oder defer oder wie auch immer nachgeladen werden Dieser FMP ist bei Lighthouse v6 aber bereits als "veraltet" deklariert und wird in v7 entfernt.

Der Grund ist der FID, denn das ist ein Bereich zwischen den beiden oben genannten.

Und hier stehen die Werte auch in gewisser Art in Widerspruch. Der User will so schnell wie möglich die ersten Inhalte haben. Also ein schneller FCP. Wenn der jedoch schnell ist, weil alles andere ausgelagert wurde, dann ist der User auch schneller dabei, mit der Seite zu interagieren. Und das ist das Problem. Wenn eine Seite einfach nur den FCP "verbessert", dann verschlechtert sich damit automatisch der FID, denn die Daten müssen nachgeladen werden, auch wenn die Inhalte schon teilweise angezeigt werden.

Der User sieht also schon was, will was machen, kann aber nicht, weil der Browser noch damit beschäftigt ist, andere Dinge zu erledigen. Und das ist der neue Ansatz von Google. Es geht nicht mehr darum, wann eine Seite die ersten Inhalte zeigt und dann komplett geladen ist, sondern wann man sie nutzen kann. Und diese "Erfahrungen" kommen eben nicht vom Google-Bot, sondern von jedem Nutzer von Chrome selbst - Telemetriedaten.

Als Webmaster muss man also dafür sorgen, dass der Zeitbereich FID nach dem sehr kurzen FCP (First Contentful Paint) ebenfalls möglichst kurz ist, wobei eben alle derzeit gängigen Methoden den FCP zu verbessern, den Bereich danach verlängern.

Ein paar Ansätze hatte ich oben schon. Also alles minimieren und entfernen, was nicht gebraucht wird. Erst laden, wenn man es benötigt, auch CSS-Deklarationen oder JS-Funktionen. Animationen etc. vermeiden. In CSS auch Wildcard ala "*" vermeiden. Überklassivizierte CSS-Rules entfernen. Nicht mit IDs arbeiten, sondern mit Klassen-Selektoren, wobei ID eigentlich schneller ist, aber eben nur für ein Element gilt. In JS auf setTimeout etc. verzichten. Einbinden von Elementen nur per DocumentFragment, neue native Methoden nutzen, sofern die Browser das denn zulassen. Usw.

So, das wollte ich noch anmerken, mein erster Absatz war einfach falsch, bzw. unvollständig und daher falsch.