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.