Core Web Vitals for Enterprise Businesses: Q/A mit Kathy Brown und Karl Kleinschmidt

Veröffentlicht: 2021-03-10

Core Web Vitals for Enterprise Businesses: Q/A mit unserer eigenen Kathy Brown und Karl Kleinschmidt

Am 18. Februar veranstalteten wir unsere Core Web Vitals for Enterprise Businesses Session, um uns mit Googles neuem Page Experience-Ranking-Faktor-Update zu befassen. Die Sitzung konzentrierte sich darauf, was die Core Web Vitals waren und warum sie wichtig waren. Unsere Experten untersuchten, was jedes der neuen Ranking-Signale bedeutete und wie sie sich auf SEO auswirken würden. Obwohl wir umsetzbare Tipps und Ratschläge gegeben haben, gab es noch viele Fragen zu FID, LCP, CLS und mehr.

Nachfolgend finden Sie die Fragen, die von unserem Publikum gesammelt wurden, und unsere Experten Kathy und Karl gehen darauf ein.

Was ist der Unterschied zwischen Feld- und Labordaten?

Kathy : Labordaten sind die Leistungsdaten, die Sie in einer bestimmten Umgebung sehen. Tools wie Chrome Dev Tools sowie Tools wie webpagetest.org stellen Ihnen Lab-Daten zur Verfügung. Felddaten sind Daten, die von den vielen Benutzern gesammelt werden, die Chrome verwenden, um die Seiten Ihrer Website zu durchsuchen. Sie können Felddaten in der Google Search Console und häufig in Google Page Speed ​​Insights sehen (wobei sowohl Lab- als auch Felddaten für eine Seite gemeldet werden). Für Automatisierungsanforderungen sind Felddaten über BigQuery zugänglich. Denken Sie daran, dass Labordaten zum Testen dienen, Felddaten zum Ranking. Basierend auf den Kommentaren von John Mueller gehen wir davon aus, dass sich CWV zunächst nur auf das mobile Ranking auswirken wird und dass Sie „im grünen Bereich“ sein müssen, damit alle drei Metriken höher eingestuft werden.

Was tun, wenn keine Felddaten verfügbar sind?

Kathy : Wenn keine Felddaten verfügbar sind, bedeutet dies wahrscheinlich, dass die Seite nicht viel Verkehr erhält. Verwenden Sie Google Page Speed ​​Insights, um Ihre beliebtesten Seiten zu überprüfen, um festzustellen, ob Felddaten für diese Seiten verfügbar sind. Sie können dann die Ergebnisse für alle Ihre Seiten extrapolieren, die zu diesem Seitentyp gehören. Versuchen Sie, einen CrUX-Bericht einzurichten, um zu sehen, ob es einen für Ihren Ursprung (Ihre Domain) gibt. Sie können eine vorgefertigte Google Data Studio-Vorlage finden, die Ihnen Leistungsdaten für Ihre Website insgesamt liefert.

Wenn Sie immer noch keine Field-Daten finden können, ermitteln Sie die häufigsten Geräte und Browser, die auf Ihre Website zugreifen, und testen Sie diese Umgebungen. Denken Sie daran, die Drosselungs- und Bandbreitensteuerung so einzustellen, dass die Umgebung Ihrer Besucher so nah wie möglich simuliert wird.

Während der Entwicklung werden unsere Websites auf sekundären Servern ausgeführt, die viel langsamer sind als unsere Produktionsserver. Wie gehen Sie in dieser Situation vor, um die Seitengeschwindigkeit zu testen?

Kathy: Ein erheblicher Teil der Bewertung von Core Web Vital hängt vom Client und dem ausgeführten Code ab. Ein schlechter CLS-Score hat also nichts mit einem langsamen Server zu tun. LCP könnte jedoch von einem langsamen Server aufgrund langsamerer Verbindungs-Handshakes und der Zeit, die zum Übertragen von Ressourcen benötigt wird, beeinträchtigt werden. Ein in Betracht zu ziehender Ansatz besteht darin, einen Vergleich für Ihre Server für Metriken wie TTFB (Zeit bis zum ersten Byte) für eine Vielzahl von Seiten zu erstellen und die Zeit für die Bereitstellung von jeweils 1 KB Daten zu vergleichen. Wenn Sie über Datenbankoperationen oder serverseitiges JS verfügen, wäre es außerdem hilfreich, die Unterschiede zwischen diesen Ausführungszeiten auf jedem Server zu kennen. Vergleichen Sie die Wasserfalldiagramme zwischen den beiden und sehen Sie, wie viel zusätzliche Wartezeit in der Entwicklungsumgebung vorhanden ist. Die Kenntnis dieser Unterschiede würde helfen, die LCP-Leistung auf Ihrem Entwicklungsserver einfacher zu bewerten.

Glauben Sie, dass sich das Vorladen von Links (für nachfolgende Seiten) auf LCP auswirkt ODER glauben Sie, dass LCP nur von der ersten Seite abhängt, die der Benutzer lädt?

Kathy: Wenn es um Felddaten geht, spielt die Leistung aller Seiten eine Rolle. Das Zwischenspeichern statischer Assets (was bei späteren Besuchen und Seiten hilft) hilft Ihren Field-Scores. Das Vorladen von CSS-Stilen über den Link wird wahrscheinlich auch die Leistung aller Seiten verbessern.

Könnte ein CDN mit guter Cache-Optimierung den LCP-Score deutlich verringern?

Kathy: Es ist sicherlich möglich, dass sich Ihr LCP-Score verbessert, wenn das LCP für alle Benutzer (sowohl neue als auch wiederkehrende) schneller erscheint.

Wie verwenden Sie Popups, ohne dass sie sich auf Core Web Vitals auswirken?

Karl: Stellen Sie bei LCP-Problemen sicher, dass Popups keinen zu großen Prozentsatz des Darstellungsbereichs einnehmen, insbesondere auf Mobilgeräten.

Stellen Sie bei CLS-Problemen sicher, dass Popups nicht den Rest Ihrer Elemente bewegen, sondern sich vor ihnen befinden.

Wie sollten wir über CWV im Zusammenhang mit der Mobile-First-Indexierung nachdenken?

Karl: CWV wird zunächst auf Mobilgeräten eingeführt und für Desktops verzögert (wir wissen nicht, um wie viel). Bei CWV geht es nicht wirklich darum, wie Google Ihre Website crawlt, sondern darum, wie Besucher mit Ihrer Website interagieren, sodass die Mobile-First-Indexierung keinen Unterschied machen sollte.

Was ist der Unterschied zwischen Total Blocking Time (TBT) und FID?

Karl: Die Gesamtblockierzeit ist die Gesamtzeit in Millisekunden, die der Hauptthread blockiert, um die Interaktion zu blockieren (pro Task werden 100 ms abgezogen). FID ist der Durchschnitt, wie lange es dauert, bis Ihre Website auf die Interaktionen der Besucher reagiert. Die Gesamtsperrzeit ist daher die Gesamtzeit in Millisekunden beim Laden der Seite, bei der Sie einen FID über 0 haben könnten, während FID erfasst, wie Benutzer tatsächlich mit Ihrer Website interagieren.

Wir sehen Punktzahländerungen in der Google Search Console, ohne dass wir Änderungen/Verbesserungen auf unserer Seite vornehmen.

Was wäre der Grund für diese Schwankungen innerhalb der Suchkonsole?

Karl: Für die Search Console sind es Felddaten, es hängt davon ab, wie Benutzer mit Ihrer Website interagieren. Änderungen im Benutzerverhalten können unterschiedliche CLS-Werte bedeuten, weil Besucher anders scrollen, oder unterschiedliche LCP-Werte, weil ein höherer Prozentsatz der Besucher wiederkehrende Kunden sind, sodass sie bestimmte Bilder zwischengespeichert haben. Es gibt viele mögliche Ursachen für die Schwankungen in den Metriken und denken Sie daran, dass die Daten um etwa 28 Tage verzögert sind. Sie haben also möglicherweise etwas vor 28 Tagen veröffentlicht und sehen jetzt die Änderungen in den Daten.

Wenn jemand unterschiedliche Ergebnisse von Search Console und PageSpeedTest erhält, sollten wir uns dann nur Gedanken darüber machen, was in Search Console gemeldet wird?

Karl: Abgesehen von Field- vs. Lab-Daten gibt es zwei Hauptursachen für unterschiedliche Daten zwischen Search Console- und Pagespeed-Insights. Wenn eine Ihrer Seiten nicht genügend Zugriffe erhalten hat, verwendet Google ähnliche Seitendaten in Seitengeschwindigkeitsstatistiken, während in der Suchkonsole ähnliche Seiten gruppiert werden, die möglicherweise genügend Daten enthalten. Es ist daher auch möglich, dass eine Ihrer Seiten genügend Traffic hat, aber keine der ähnlichen Seiten genügend Traffic hat, was ebenfalls zu unterschiedlichen Scores führen kann. Es gab auch ein Update für die Berichterstellung der Suchkonsole, das Auswirkungen haben könnte.

Benötigen Sie zusätzliche Ressourcen?

Wir haben viele tolle Inhalte zu diesem Thema. Sehen Sie sich unsere Core Web Vitals-Seite an, auf der wir eine Bibliothek mit Expertenressourcen wie Podcasts, Webinare und Blogs zusammengestellt haben. Hier finden Sie alles, was Sie brauchen, um sich auf die Aktualisierung des Page Experience-Rankingfaktors von Google vorzubereiten.