Felddaten, die für Rankings berücksichtigt werden, variieren je nach Leistung des Benutzergeräts in der Praxis, Bildschirmgröße und Netzwerkkonnektivität. Labordaten haben dafür Standardwerte und können (außer im Fall von Page Speed ​​Insights) von Entwicklern kalibriert werden, um alle Arten von Bedingungen zu simulieren.

Der Ranking-Faktor für mobile Seiten von Google, der ursprünglich als Teil des Core Ranking Update vom Mai gedacht war, wird in wenigen Tagen eingeführt. Sind Sie bereit? Wenn nicht, fassen Sie sich ein Herz.

Für Beobachtung und Anpassung sind mehrere Wochen reserviert: „Die Seitenerfahrung wird ihre volle Rolle in diesen Systemen erst Ende August spielen“, sagte Google. Danach wird der Ranking-Faktor für die Desktop-Seitenerfahrung als nächstes eingeführt und vor Ende des Jahres vollständig eingeführt.

Über die Core Web Vitals-Metriken

Core Web Vitals sind großartige Leistungskennzahlen in Bezug auf die Geschwindigkeit, die dazu beitragen, ein stabiles, sichtbares und nutzbares Erlebnis bei einem Geräte-Viewport und einschließlich Offscreen-Inhalten mit bis zu 9000 vertikalen Pixeln zu erzielen. Schneller ist besser, was normalerweise bedeutet, dass Bewertungen mit niedrigeren Metriken besser sind.

Felddaten, die für Rankings berücksichtigt werden, variieren je nach Leistung des Benutzergeräts in der Praxis, Bildschirmgröße und Netzwerkkonnektivität. Labordaten haben dafür Standardwerte und können (außer im Fall von Page Speed ​​Insights) von Entwicklern kalibriert werden, um alle Arten von Bedingungen zu simulieren.

Labordaten werden für Rankings nicht berücksichtigt.

Die Leistungsmetriken von Core Web Vitals sind komplex und unvollkommen, und das Beheben von Problemen mit der Seitenerfahrung kann verwirrend sein. Schon jetzt hat Google in letzter Minute Änderungen vorgenommen, um alle seine Tools zu aktualisieren, um geschärfte Formeln als Reaktion auf Fälle von Entwicklern vor Ort aufzunehmen.

Sie können sich im Allgemeinen auf verbesserte Ergebnisse freuen, wenn Sie von den Metriken betroffen waren, die einer Überarbeitung unterzogen wurden. Besonders hilfreich sind Modifikationen bei der Messung von Largest Contentful Paint (LCP) und Cumulative Layout Shift (CLS).

Änderungen an der ersten Contentful Paint

Der Schwellenwert für das Erreichen von „guten“ Werten für First Contentful Paint (FCP) , dessen Komponenten zu Core Web Vitals beitragen, ohne dass FCP tatsächlich einer ist, wurde von 1,0 auf 1,8 Sekunden erhöht. FCP berücksichtigt die Zeit bis zum ersten Byte , die mehr die Antwortzeit Ihres Servers widerspiegelt als alles, was Sie direkt mit Code manipulieren, sowie die Zeit, die benötigt wird, um Renderblocking-Ressourcen wie CSS zu verarbeiten, was Sie können.

Änderungen an der größten Contentful Paint

LCP, ein bedeutender Meilenstein im Lebenszyklus einer Seite, enthielt ursprünglich einige Offscreen-Elemente nicht. Jetzt lokalisiert LCP das größte Element, auch wenn es später aus dem Seiten-DOM entfernt wurde, sobald es entdeckt wurde, oder wenn mehrere Bilder der gleichen Größe alle in Frage kommen.

Solche Situationen treten auf, wenn Karussells Inhalte für Offscreen-Folien laden und zwischenspeichern. Eine weitere hilfreiche Modifikation ist, dass auch Hintergrundbilder von LCP ignoriert werden.

Änderungen an der kumulativen Layoutverschiebung

Um zu verhindern, dass Situationen wie extrem lange Browsersitzungen die CLS-Werte untergraben, werden kleinere „Fenster“-Sitzungen auf 5 Sekunden begrenzt und als beendet durch eine 1-Sekunden-Lücke als Grenze markiert, um die schlimmsten 5 Sekunden der Layoutverschiebung der Seite zu finden.

Das ist eine viel bessere Darstellung der Verschiebung als das Auszählen von vollständig unbegrenzten Sitzungen, die 20 Minuten oder länger dauern können, wenn die Punktzahlen weit überproportioniert sind.

Was alt ist, ist neu

Google wird die alte Berechnung nicht als Teil des Rankingfaktors für die Seitenerfahrung verwenden. Für Ausreißer-Anwendungsfälle können jedoch ganze Sitzungsbewertungen immer noch nützlich sein. Die Art und Weise, wie diese Daten per API abrufbar sind, bedeutet, dass die alte Score-Berechnung für diejenigen, die sie wollen, ein zweites Leben führen kann. 

Sie können es unabhängig oder durch Zugriff auf das offene Repository von Google über CrUX Report (SQL) abrufen: uncapped_cumulative_layout_shift.

SELECT
  uncapped_cls
FROM
  `chrome-ux-report.all.202105`,
  UNNEST(
    experimental.uncapped_cumulative_layout_shift.histogram.bin
  )
AS uncapped_cls
WHERE
  origin = 'https://luileo.apollo.wpspace.me'

Wenn Page Speed ​​Insights (PSI)-Daten nützlich sind

Der Trick besteht darin, mehr als eine offizielle Methode zum Abrufen Ihrer Ergebnisse zu erlernen, was noch komplizierter wird, je nachdem, wie Sie über die angezeigten Daten nachdenken. Page Speed ​​Insights (PSI), die oft von SEO-Praktikern hervorgehoben werden, bieten allein nicht genügend Informationen, um die ganze Geschichte zu erzählen.

PSI wurde entwickelt, um Entwicklern eine umfassende Momentaufnahme zur Behebung von Leistungsproblemen zu geben. Wenn von CrUX verfügbar, sind Felddaten, die über einen vorherigen 4-Wochen-Zeitraum aggregiert wurden, für Vergleiche nützlich. Das Erscheinen von Labor- und Felddaten zeigt zweifellos einen Unterschied zwischen den beiden.

Abweichungen sind ein natürliches Auftreten zwischen Testsitzungen und beim Vergleichen von Tests von verschiedenen Geräten und/oder Netzwerken. Felddaten variieren daher so stark wie das Publikum einer bestimmten Website. PSI-Felddaten stellen daher eine Reihe von Daten dar, die über die letzten 28 Tage aggregiert wurden, bis hin zu den Daten des zuletzt abgeschlossenen Ganztages.

Labordaten bieten umfassenderes Feedback

Die Lighthouse-Laborwerte in PSI sind „ so kalibriert, dass sie für Ihre oberen Perzentile repräsentativ sind “ für Worst-Case-Szenarien, wie die von leistungsschwachen Browsern in trägen Netzwerken. Google kalibriert es absichtlich, damit Entwickler umfassenderes Feedback erhalten, um Problembereiche, die auftreten können, aber in der realen Welt weniger verbreitet sind, leichter zu beheben.

Wenn die Laborwerte auf durchschnittlichere Bedingungen hindeuten, würden sie nicht die Leistungsengpässe aufdecken, die Entwickler sehen müssen, um Änderungen vorzunehmen, um die Seitenerfahrung unter Stressbedingungen zu verbessern. Lighthouse außerhalb von PSI, in Dev Tools oder von NPM als offenes Node-Projekt verpackt, kann kalibriert werden, um verschiedene Szenarien zu simulieren.

Felddaten bieten Anwendungsbeispiele aus der Praxis

Es ist unglaublich wichtig, Scores zu lesen und zu verstehen, welche Datenerfassungsmethode verwendet wurde, um die verfügbaren Scores zu unterstützen. Im Fall von PSI können Sie sowohl Labor- als auch Felddaten sehen und sie sollten nicht als dasselbe verwechselt werden. Felddaten werden für CrUX-Berichte gesammelt und Sie können sie auch selbst sammeln. Felddaten geben Aufschluss über das Publikum, wie es von Browsern mit realer Nutzung Ihrer Website aufgezeichnet wird.

Felddaten sind wichtig, da Google sie für den Rankingfaktor der Seitenerfahrung verwendet. Die Ergebnisse der Felddaten sind fast immer besser als die Ergebnisse der Labordaten für dieselbe Seite. Felddaten über die Zeit stabil, einmal aufbereitet für die Langzeitspeicherleistung (die Sie nach mehreren Kriterien verfeinern können), wobei die neuesten Daten monatlich neu erstellt werden, während Labordaten bei jedem neuen Test abweichen können.

Wenn Browser die erforderlichen Berechtigungen zum Übertragen von Ergebnissen haben, werden Felddaten gesendet und zur Verwendung durch PSI, ein beliebiges Core Web Vitals-Tool, das die offene CrUX-API verwendet, oder für diejenigen, die Core Web Vitals-JavaScript in Webseiten schreiben, gesammelt und gesammelt . Die einzige Möglichkeit, Felddaten in Echtzeit zu untersuchen, besteht darin, das JavaScript zu schreiben und es für den eigenen Gebrauch in einer Browserkonsole oder einem Repository zu sammeln oder an Google Analytics senden zu lassen.

Labordaten zur Optimierung verwenden

Das Open-Source-Projekt Lighthouse ist die Grundlage für Labordaten und wurde in Dev Tools implementiert und kann auch in einem Paket installiert werden, das mit einem eigenen Command Line Interpreter (CLI) geliefert wird. Lighthouse in Dev Tools kann so konfiguriert werden, dass die verringerte oder erhöhte Leistung und Geschwindigkeit vom Standard „oberes Perzentil“ angepasst wird.

Sie können beispielsweise unterschiedliche Leistung und Geschwindigkeit simulieren, wenn Sie über die nötigen Mittel verfügen, um bei bestimmten simulierten Schwellenwerten komplexere Erfahrungen zu liefern, die eine progressive Verbesserungsstrategie implementieren.

CLI-Nutzung

Labordaten, sofern verfügbar, die von einem lokalen Computer aus arbeiten, möglicherweise im Rahmen von Vorproduktionstests und einem kontinuierlichen Integrationsprozess in einen Workflow integriert. Für diese Art der Einrichtung müssen der Chrome-Webbrowser und Node installiert sein.

Die CLI erzeugt einen Chrome-Browserprozess für den Zugriff auf die Rendering-Engine und die Lighthouse-Bibliothek. Es werden die von diesem Chrome-Prozess zurückgegebenen Daten tabellarisch angezeigt und anschließend beendet. Optionen zum Öffnen des resultierenden Berichts und zum Kalibrieren auf Geräte- und Netzwerkeinstellungen sind als Teil der Befehlsoptionen verfügbar

$ lighthouse <url> [OPTIONS]

Die gebräuchlichsten Optionen sind --view, die den Bericht automatisch im Standard-Webbrowser Ihres Systems öffnen, --throttle Anweisungen zum Simulieren verschiedener Geräteumgebungen und --only-categories zum Beschränken von Tests auf diejenigen, die die Leistung beeinträchtigen und nachfolgende bestimmende Faktoren für Core Web Vitals haben. Obwohl es nützlich ist, SEO-Tests durchzuführen, bewegen zu viele SEO-Verbesserungen nicht die Nadel für Core Web Vitals.