Core Web Vitals: Page Speed ist jetzt noch wichtiger für SEO

Patrick Stox
Patrick Stox ist Produktberater, technischer SEO und Markenbotschafter bei Ahrefs. Er ist Organisator des SEO-Meetups in Raleigh, der SEO-Konferenz in Raleigh, des Beer & SEO-Meetups, der Findability-Konferenz und Moderator bei /r/TechSEO.
Article stats
  • Linking websites 2
Data from Content Explorer

Shows how many different websites are linking to this piece of content. As a general rule, the more websites link to you, the higher you rank in Google.

Shows estimated monthly search traffic to this article according to Ahrefs data. The actual search traffic (as reported in Google Analytics) is usually 3-5 times bigger.

The number of times this article was shared on Twitter.

    Core Web Vitals sind die Geschwindigkeitsmetriken, die Teil von den Googles-Page-Experience-Signalen sind, und zur Messung der User Experience verwendet werden. Die Metriken messen die visuelle Belastung mit Largest Contentful Paint (LCP), die visuelle Stabilität mit Cumulative Layout Shift (CLS) und die Interaktivität mit First Input Delay (FID).

    Page Experience und die enthaltenen Core-Web-Vital-Metriken werden ab Mai 2021 offiziell für das Ranking von Seiten verwendet.

    Quelle: Google 

    Die einfachste Möglichkeit, die Metriken für deine Seite einzusehen, ist im Core-Web-Vitals-Bericht in der Google Search Console. Mit dem Bericht kannst du leicht sehen, ob deine Seiten als “schlechte URLs”, “URLs, die optimiert werden müssen” oder “gute URLs” kategorisiert werden.

    Im Bericht findest du genauere Informationen zu den einzelnen Problemen und eine Liste der betroffenen Seiten.

    Fakt 1: Die Metriken sind in Desktop und Mobile aufgeteilt, aber nur die mobilen Signale werden für das Ranking der Seiten herangezogen. Google stellt im März auf 100% Mobile-First-Indexierung um, daher macht es Sinn, die mobilen Geschwindigkeitssignale zu nutzen, da die indexierten Seiten auch auf den mobilen Versionen basieren werden.

    Fakt 2: Die Daten stammen aus dem Chrome User Experience Report (CrUX), der Daten von angemeldeten Chrome-Nutzern erfasst. Die Metriken werden am 75. Perzentil der Nutzer bewertet, wenn also 70% deiner Nutzer in der Kategorie “gut” sind und 5% in der Kategorie “verbesserungswürdig”, dann wird deine Seite trotzdem als “verbesserungswürdig” bewertet.

    Fakt 3: Die Metriken werden für jede Seite bewertet. Wenn es aber nicht genug Daten gibt, können laut John Mueller auch Signale von Teilbereichen einer Seite oder der gesamten Seite verwendet werden.

    Fakt 4: Durch das Hinzufügen dieser neuen Metriken wird AMP als Voraussetzung aus dem Top-Stories-Feature auf mobilen Geräten entfernt. Da die neuen Stories keine Daten zu den Geschwindigkeitsmetriken haben werden, ist es wahrscheinlich, dass die Metriken von einer größeren Kategorie von Seiten oder sogar der gesamten Domain dafür verwendet werden können.

    Fakt 5: Single-Page-Applications messen ein paar der Metriken, FID und LCP, nicht durch Seitenübergänge. Wir werden in einer Minute darüber sprechen, was damit gemeint ist.

    Fakt 6: Die Metriken können sich im Laufe der Zeit ändern und die Schwellenwerte ebenso. Google hat bereits die Metriken zur Messung der Geschwindigkeit in seinen Tools über die Jahre verändert, ebenso wie die Schwellenwerte dafür, was als schnell oder nicht schnell gilt. Es ist sehr wahrscheinlich, dass sich das alles in Zukunft wieder ändern wird. In der Tat haben wir im letzten Jahr etwas an der Optimierung der vorherigen Metriken gearbeitet, aber wir müssen wieder etwas tun, um die neuen Metriken zu verbessern.

    Nur um die richtige Erwartungshaltung zu setzen, bedenke, dass es über 200 Rankingfaktoren gibt. Ich würde keine allzu große Verbesserung durch die Optimierung der Core Web Vitals erwarten. Es ist zwar unklar, wie sehr sie die Rankings beeinflussen werden, aber es ist unwahrscheinlich, dass es sich um ein starkes Signal handelt, vor allem, wenn man bedenkt, dass viele der Page-Experience-Komponenten bereits von Google für die Bestimmung der Rankings verwendet wurden. 

    Schauen wir uns die einzelnen Core Web Vitals im Detail an.

    Hier sind die drei aktuellen Komponenten von Core Web Vitals:

    Largest Contentful Paint (LCP) — Laden

    LCP ist das einzelne größte sichtbare Element, das im Darstellungsbereich geladen wird.

    Das größte Element ist in der Regel ein Featured Image oder vielleicht der <h1> Tag, aber es kann auch jedes der folgenden sein:

    • <img> Element
    • <image> Element innerhalb eines <svg>-Elements
    • Das Bild innerhalb eines <video> Elements
    • Hintergrundbild, das mit der Funktion url() geladen wird
    • Textblöcke

    <svg> und <video> können gegebenfalls in Zukunft hinzugefügt werden.

    Wie man den LCP anzeigen lassen kann

    In PageSpeed Insights wird das LCP-Element im Bereich Diagnostics angegeben. Für die getestete Seite ist das LCP unser Featured Image auf dem Blogpost.

    Folge in Chrome DevTools diesen Schritten:

    1. Leistung/Performance > Check “Screenshots”
    2. Klicke auf “Profiling starten und Seite neu laden”.
    3. LCP ist auf dem Zeitdiagramm zu sehen
    4. Klicke auf den Knoten; dies ist das Element für LCP

    LCP optimieren

    Da unser LCP-Element auf dieser und vielen anderen Seiten das “Featured Image” ist, können wir dies vermutlich optimieren, indem wir dieses Bild vorladen oder möglicherweise das gesamte Bild inlinen, um das Bild zusammen mit dem HTML-Code zu laden. Im Grunde wollen wir dieses Bild schneller laden, als wir es derzeit tun.

    Info-Quellen

    Cumulative Layout Shift (CLS) — visuelle Stabilität

    CLS misst, wie sich Elemente bewegen oder wie stabil das Seitenlayout ist. Es berücksichtigt die Größe des Inhalts und die Strecke, über die er sich bewegt. Ein großes Problem bei dieser Metrik ist, dass sie auch nach dem ersten Laden der Seite weiter misst. Google nimmt Feedback zu dieser speziellen Metrik entgegen, so dass wir in Zukunft wahrscheinlich einige Änderungen daran beobachten werden.

    Es kann ärgerlich sein, wenn man versucht, etwas auf einer Seite anzuklicken, die sich verschiebt und man am Ende auf etwas klickt, was man gar nicht beabsichtigt hat. Das passiert mir andauernd. Ich klicke auf eine Sache, und plötzlich klicke ich auf eine Werbung und bin nicht einmal mehr auf der gleichen Website. Das ist für mich als Nutzer frustrierend.

    Häufige Ursachen für CLS sind:

    • Bilder ohne Abmessungen
    • Werbeanzeigen, Einbettungen und Iframes ohne Abmessungen
    • Einfügen von Inhalten mit JavaScript
    • Spätes Anwenden von Schriftarten oder Stilen während des Ladens

    Wie man CLS anzeigen kann

    In PageSpeed Insights findest du unter Diagnostics eine Liste mit den Elementen, die sich verschieben.

    Bei der Verwendung von WebPageTest: Verwende in Filmstrip View die folgenden Optionen:

    • Highlight Layout Shifts
    • Thumbnail Größe: Riesig
    • Thumbnail Intervall: 0,1 sec

    Beachte, wie sich unsere Schriftart zwischen 5,1s und 5,2s umgestaltet und das Layout verschiebt, während unsere benutzerdefinierte Schriftart angewendet wird.

    Probiere doch mal den Layout Shift GIF Generator aus.

    Die vom Smashing Magazine haben auch eine interessante Technik angewandt, bei der sie alles mit einer 3px langen roten Linie umrissen und ein Video vom Laden der Seite aufgenommen haben, um zu erkennen, wo Layoutverschiebungen stattfinden.

    CLS optimieren

    Für unsere Testseite können wir unsere benutzerdefinierte Schriftart vorab laden, die benutzerdefinierte Schriftart komplett weglassen (was wir wohl kaum tun werden) oder eine Standardschriftart für das erste Laden der Seite verwenden und unsere Schriftart nur bei nachfolgenden Seitenladungen laden. Diese Optionen gehen mit Kompromissen in Bezug auf Branding, Stil, Konsistenz usw. einher und wir müssen entscheiden, was die beste Option für die Zukunft ist.

    Info-Quellen

    First Input Delay (FID) — Interaktivität

    FID bezeichnet die Zeit zwischen der Interaktion eines Nutzers mit deiner Seite und dem Zeitpunkt, an dem die Seite reagieren kann. Man kann es auch als Reaktionszeit bezeichnen. Dies beinhaltet nicht das Scrollen oder Zoomen.

    Beispiele für Interaktionen:

    • Klicken auf einen Link oder Button
    • Eingabe von Text in ein leeres Feld
    • Auswählen eines Dropdown-Menüs
    • Anklicken eines Kontrollkästchens

    Es kann frustrierend sein, wenn du auf etwas klickst und nichts auf der Seite passiert.

    Nicht alle Nutzer interagieren mit einer Seite, daher kann es sein, dass sie keinen FID-Wert aufweisen. Das ist auch der Grund, warum Labortest-Tools den Wert nicht erfassen, weil sie nicht mit der Seite interagieren. Verwende stattdessen Total Blocking Time (TBT).

    Ursache für FID

    JavaScript konkurriert um den Haupt-Thread. Es gibt nur einen Haupt-Thread, und JavaScript konkurriert darum, Tasks auf diesem auszuführen.

    Während ein Task ausgeführt wird, kann eine Seite nicht auf Benutzereingaben reagieren. Das ist die Verzögerung, die man wahrnimmt. Je länger der Task ist, desto länger ist die Verzögerung, die der Nutzer erfährt. Die Pausen zwischen den Tasks sind die Gelegenheiten, die die Seite hat, um zum Benutzereingabe-Task zu wechseln und auf das zu reagieren, was sie tun wollte.

    FID optimieren

    Ich sehe für unsere Seite keine Schwierigkeiten bezüglich FID, aber im Allgemeinen solltest du lange Tasks aufbrechen und JavaScript, das nicht benötigt wird, auf später verschieben.

    Info-Quellen

    Der Unterschied zwischen Labor- und Felddaten ist, dass Felddaten reale Nutzer, Netzwerkbedingungen, Geräte, Caching etc. betrachten und Labordaten konsequent auf Basis der gleichen Bedingungen getestet werden, in der Hoffnung, dass die Testergebnisse wiederholbar sind.

    Felddaten

     LCPFIDCLS
    Chrome User Experience Report
    PageSpeed Insights
    Google Search Console (Core Web Vitals report)
    Web-vitals JavaScript library
    web.dev
    Web Vitals Extension

    Labordaten

     LCPFIDCLS
    Chrome DevTools✘ (use TBT)
    Lighthouse✘ (use TBT)
    WebPageTest✘ (use TBT)
    PageSpeed Insights✘ (use TBT)
    web.dev✘ (use TBT)

    Ich mag den Bericht in der GSC, weil man die Daten für viele Seiten auf einmal sehen kann. Allerdings sind die Daten sind etwas zeitversetzt und basieren auf einem gleitenden 28-Tage-Durchschnitt, so dass es einige Zeit dauern kann, bis Änderungen im Bericht angezeigt werden. In Chrome 88 fügt Google die Core Web Vitals direkt in den DevTools hinzu.

    Du kannst auch jederzeit die Scoring-Gewichtungen für Lighthouse einsehen und die historischen Veränderungen betrachten. 

    Fazit

    Mit der Optimierung der Core Web Vitals willst du deinen Nutzern ein besseres Erlebnis bieten. Es bleibt abzuwarten, welchen Einfluss sie auf die SEO haben werden. Wie ich allerdings schon in meinem Artikel über Page Speed, erwähnt habe, sollen sie dir dabei helfen, mehr Daten in deinen Analytics aufzuzeichnen, was sich wie eine Steigerung “anfühlt”.

    Arbeite mit deinen Entwicklern zusammen; sie sind hier die Experten. Page Speed kann extrem komplex sein. Wenn du auf dich allein gestellt bist, benötigst du vielleicht ein Plugin oder einen Service wie WP Rocket oder NitroPack, um dies zu erledigen.

    • Linking websites 2
    Data from Content Explorer