Verbesserung der Core Web Vitals, eine beeindruckende Fallstudie für ein Magazin

„Warum schlagen meine Core Web Vitals fehl?“ Diese Frage haben sich in letzter Zeit viele Entwickler gestellt. Manchmal ist es einfach genug, die Antwort auf diese Frage zu finden, und die Website muss nur in Leistung investieren . Manchmal ist es jedoch etwas kniffliger und obwohl Sie denken, dass Ihre Website aus irgendeinem Grund großartig war, scheitert sie immer noch. Genau das ist unserem eigenen smashingmagazine.com passiert, und um das Problem herauszufinden und zu beheben, musste ein bisschen gegraben werden.

Ein Hilferuf

Alles begann mit einer Reihe von Tweets im vergangenen März mit einem Hilferuf:

Nun, das hat mein Interesse geweckt! Ich bin ein großer Fan des Smashing Magazine und interessiere mich sehr für Web-Performance und die Core Web Vitals. Ich habe hier schon einige Artikel über Core Web Vitals geschrieben und bin immer daran interessiert zu sehen, was in ihrer jährlichen Web-Performance-Checkliste steht. Das Smashing Magazine kennt sich also mit der Webleistung aus, und wenn sie Probleme haben, könnte dies ein interessanter Testfall sein!

Einige von uns haben in diesem Thread einige Vorschläge gemacht, was das Problem sein könnte, nachdem sie einige unserer bevorzugten Tools zur Analyse der Webleistung wie WebPageTest oder PageSpeed ​​Insights verwendet haben.

Untersuchung des LCP-Problems

Das Problem war, dass LCP auf dem Handy zu langsam war. LCP, oder Largest Contentful Paint, ist einer der drei Core Web Vitals, die Sie „bestehen“ müssen, um den vollen Suchranking-Boost von Google als Teil ihres Page Experience Update zu erhalten. Wie der Name schon sagt, zielt LCP darauf ab, zu messen, wann der größte Inhalt der Seite auf den Bildschirm gezeichnet (oder „gemalt“) wird. Oft ist dies das Heldenbild oder der Titeltext. Es soll messen, was der Website-Besucher wahrscheinlich hierher gekommen ist, um es zu sehen.

Frühere Metriken maßen Variationen der ersten zu screenenden Farbe (häufig war dies eine Kopf- oder Hintergrundfarbe); zufälliger Inhalt, der nicht wirklich das ist, was der Benutzer eigentlich aus der Seite herausholen möchte . Der größte Inhalt ist oft ein guter Indikator dafür, was am wichtigsten ist. Und der „inhaltliche“ Teil des Namens zeigt, dass diese Metrik ignoriert werden soll (z. B. Hintergrundfarben); Sie sind vielleicht der größte Inhalt, aber sie sind nicht „inhaltlich“, zählen also nicht für LCP und stattdessen versucht der Algorithmus, etwas Besseres zu finden.

LCP betrachtet nur das anfängliche Ansichtsfenster. Sobald Sie nach unten scrollen oder anderweitig mit der Seite interagieren, wird das LCP-Element behoben und wir können berechnen, wie lange es gedauert hat, dieses Element zu zeichnen, nachdem die Seite zum ersten Mal geladen wurde – und das ist Ihr LCP!

Es gibt viele Möglichkeiten, Ihre Core Web Vitals zu messen, aber der definitive Weg – auch wenn es nicht der beste Weg ist, wie wir bald sehen werden – ist die Google Search Console (GSC). Aus SEO-Sicht spielt es keine Rolle, was andere Tools Ihnen sagen, GSC ist das, was die Google-Suche sieht. Natürlich ist es wichtiger, was Ihre Benutzer erleben , als was ein Suchmaschinen-Crawler sieht, aber eines der großartigen Dinge an der Core Web Vitals-Initiative ist, dass sie die echte Benutzererfahrung misst und nicht das, was Google Bot sieht! Also, wenn GSC sagt, dass Sie schlechte Erfahrungen gemacht haben, dann haben Sie laut Ihren Benutzern schlechte Erfahrungen gemacht .

Die Search Console teilte dem Smashing Magazine mit, dass ihr LCP auf Mobilgeräten für die meisten ihrer Seiten verbessert werden müsste. Eine Standardausgabe dieses Teils von GSC und ziemlich einfach zu adressieren: Lassen Sie Ihr LCP-Element einfach schneller zeichnen! Das sollte nicht zu lange dauern. Sicherlich nicht sechs Monate (oder so dachten wir). Als erstes müssen Sie also herausfinden, was das LCP-Element ist.

Durch das Ausführen einer fehlerhaften Artikelseite über WebPageTest wurde das LCP-Element hervorgehoben:

Verbesserung des LCP-Images

OK, also ist das Foto des Artikelautors das LCP-Element. Der erste Instinkt ist zu fragen, was wir tun könnten, um das schneller zu machen? Dazu müssen Sie sich mit Wasserfällen befassen, sehen, wann das Bild angefordert wird, wie lange das Herunterladen dauert, und dann entscheiden, wie Sie dies optimieren können. Hier wurde das Bild in Größe und Format gut optimiert (meist die erste und einfachste Möglichkeit, die Performance von Bildern zu verbessern!). Das Bild wurde von einer separaten Asset-Domäne bereitgestellt (oft schlecht für die Leistung), aber es war nicht möglich, dies kurzfristig zu ändern, und das Smashing Magazine hatte bereits einen preconnect Ressourcenhinweis hinzugefügt, um dies so gut wie möglich zu beschleunigen könnten.

Wie ich bereits erwähnt habe, kennt sich Smashing Magazine mit Web-Performance aus, hatte erst kürzlich daran gearbeitet, ihre Performance zu verbessern, und hier alles richtig gemacht, aber immer noch versagt. Interessant…

Andere Vorschläge gingen ein, darunter das Reduzieren der Last, das Verzögern des Servicemitarbeiters (um Konflikte zu vermeiden) oder das Untersuchen von HTTP/2-Prioritäten, aber sie hatten nicht die erforderliche Auswirkung auf das LCP-Timing. Also mussten wir in unsere Web-Performance-Toolbag greifen, um alle Tipps und Tricks zu finden, um zu sehen, was wir hier noch tun könnten.

Wenn eine Ressource für das Laden der Seite entscheidend ist, können Sie sie einbetten, sodass sie in den HTML-Code selbst aufgenommen wird. Auf diese Weise enthält die Seite alles Notwendige, um die Erstlackierung ohne Verzögerungen durchzuführen. Das Smashing Magazine zum Beispiel hat bereits kritisches CSS eingebunden, um ein schnelles erstes Malen zu ermöglichen, hat aber das Bild des Autors nicht eingebunden. Inlining ist ein zweischneidiges Schwert und muss mit Vorsicht verwendet werden. Es peppt die Seite auf und bedeutet, dass nachfolgende Seitenaufrufe nicht davon profitieren, dass Daten bereits heruntergeladen wurden. Aus diesem Grund bin ich kein Fan von Over-Inlining und denke, dass es mit Vorsicht verwendet werden muss.

Daher wird es normalerweise nicht empfohlen, Bilder einzufügen. Hier bereitete uns das Bild jedoch echte Probleme, war ziemlich klein und direkt mit der Seite verlinkt. Ja, wenn Sie viele Artikel von diesem einen Autor lesen, ist es eine Verschwendung, dasselbe Bild mehrmals herunterzuladen, anstatt das Bild des Autors einmal herunterzuladen und wiederzuverwenden, aber aller Wahrscheinlichkeit nach sind Sie hier, um verschiedene Artikel von verschiedenen Autoren zu lesen .

In letzter Zeit gab es einige Fortschritte bei Bildformaten, aber AVIF sorgt für Aufsehen, da es bereits da ist (zumindest in Chrome und Firefox) und es beeindruckende Komprimierungsergebnisse gegenüber den alten JPEG-Formaten bietet, die traditionell für Fotos verwendet werden. Vitaly wollte die JPEG-Version der Autorenbilder nicht einbetten, untersuchte aber, ob das Einbetten der AVIF-Version funktionieren würde. Das Komprimieren des Autorenbilds mit AVIF und das anschließende Base64-ing des Bilds in den HTML-Code führte zu einer Erhöhung des HTML-Seitengewichts um 3 KB – was winzig und daher akzeptabel war.

Da AVIF zu dieser Zeit nur in Chrome unterstützt wurde (es kam nach all dem zu Firefox) und da Core Web Vitals eine Google-Initiative ist, fühlte es sich aufgrund eines Google-Erlasses etwas „eklig“ an, für einen Google-Browser zu optimieren. Chrome steht oft an vorderster Front bei der Unterstützung neuer Funktionen, und das ist zu loben, aber es fühlt sich immer ein wenig daneben an, wenn sich diese beiden Seiten seines Geschäfts gegenseitig beeinflussen. Dennoch war dies eher ein neues Standard-Bildformat als ein proprietäres Nur-Chrome-Format (auch wenn es anfangs nur in Chrome unterstützt wurde) und eine progressive Verbesserung der Leistung (Safari-Benutzer erhalten immer noch denselben Inhalt, nur nicht ganz so schnell ), also nahm Smashing mit der Hinzufügung des AVIF-Twists den Vorschlag auf und fügte das Bild ein und sah tatsächlich beeindruckende Ergebnisse in Laborwerkzeugen. Problem gelöst!

Ein alternatives LCP

Also ließen wir dieses Bett herein und warteten die üblichen 28 Tage oder so, bis die Core Web Vitals-Nummern alle grün wurden … aber das taten sie nicht. Sie schwankten zwischen Grün und Gelb, also hatten wir die Dinge sicherlich verbessert, aber das Problem nicht vollständig gelöst. Nachdem er sich lange in der bernsteinfarbenen Rubrik „Verbesserungsbedarf“ aufgehalten hatte, wandte sich Vitaly an ihn, um zu sehen, ob es noch andere Ideen gab.

Das Bild wurde schnell gezeichnet. Nicht ganz sofort (es braucht immer noch Zeit, um ein Bild zu verarbeiten), aber so nah wie möglich. Um ehrlich zu sein, gingen mir die Ideen aus, aber ich habe mit frischen Augen noch einmal nachgesehen. Und dann kam mir eine alternative Idee – optimierten wir das richtige LCP-Element? Autoren sind natürlich wichtig, aber ist der Leser wirklich hierher gekommen, um das zu sehen? So sehr unser Ego ja sagen möchte und dass unsere schönen glänzenden Tassen viel wichtiger sind als der Inhalt, den wir schreiben, denken die Leser wahrscheinlich nicht (Leser, huh — was können Sie tun!).

Der Leser kam wegen des Artikels, nicht der Autor. Das LCP-Element sollte dies also widerspiegeln, was auch das LCP-Bildzeichnungsproblem lösen könnte. Dazu haben wir einfach die Überschrift über das Autorenbild gesetzt und die Schriftgröße auf Mobilgeräten etwas erhöht. Das mag wie ein hinterhältiger Trick klingen, um die SEO-Götter von Core Web Vital auf Kosten der Benutzer zu täuschen, aber in diesem Fall hilft es beiden! Obwohl viele Websites versuchen, sich für den schnellen und einfachen Hack zu entscheiden oder für GoogleBot über echte Benutzer zu optimieren, war dies nicht der Fall, und wir waren mit der Entscheidung hier recht zufrieden. Tatsächlich entfernen weitere Optimierungen das Autorenbild vollständig in der mobilen Ansicht, wo der Platz begrenzt ist und dieser Artikel derzeit auf dem Handy so aussieht, wobei das LCP-Element hervorgehoben ist:

Hier zeigen wir den Titel, die wichtigsten Informationen zum Artikel und den Beginn der Zusammenfassung – viel nützlicher für den Benutzer, als den ganzen kostbaren Platz auf dem mobilen Bildschirm mit einem großen Foto zu belegen!

Und das ist eines der wichtigsten Dinge, die ich an den Core Web Vitals mag: Sie messen die Benutzererfahrung.

Um die Metriken zu verbessern, müssen Sie die Erfahrung verbessern.

„

Und JETZT waren wir endlich fertig. Text wird viel schneller gezeichnet als Bilder, sodass das LCP-Problem behoben sein sollte. Vielen Dank an alle und gute Nacht!

Ich hasse dieses CWV-Diagramm in der Google Search Console…

Wieder wurden wir enttäuscht. Das löste das Problem nicht und es dauerte nicht lange, bis das Diagramm der Google Search Console wieder gelb wurde:

An dieser Stelle sollten wir etwas mehr über Seitengruppierungen und Core Web Vitals sprechen. Sie haben vielleicht an der obigen Grafik bemerkt, dass so ziemlich die gesamte Grafik auf einmal schwingt. Aber es gab auch eine Kerngruppe von etwa 1.000 Seiten, die die meiste Zeit grün blieben. Warum ist das so?

Nun, die Google Search Console kategorisiert Seiten in Seitengruppierungen und misst die Core Web Vitals-Metriken dieser Seitengruppierungen. Dies ist ein Versuch, fehlende Daten für die Seiten auszufüllen, die nicht genügend Zugriffe erhalten, um aussagekräftige Daten zur Benutzererfahrung zu erhalten. Es gibt eine Reihe von Möglichkeiten, wie sie dies hätten angehen können: Sie hätten solchen Seiten einfach keinen Ranking-Boost geben oder vielleicht das Beste annehmen und Seiten ohne Daten einen vollen Boost geben können. Oder sie hätten auf zentrale Web-Vitals-Daten auf Ursprungsebene zurückgreifen können. Stattdessen versuchten sie, etwas Klügeres zu tun, was ein Versuch war, hilfreich zu sein, aber in vielerlei Hinsicht auch verwirrender: Seitengruppierungen .

Grundsätzlich ist jeder Seite eine Seitengruppierung zugeordnet. Wie sie das machen, ist nicht klar, aber URLs und Technologien, die auf der Seite verwendet werden, wurden bereits erwähnt. Sie können auch nicht sehen, welche Gruppierungen Google für jede Ihrer Seiten ausgewählt hat und ob ihr Algorithmus es richtig gemacht hat, was für Website-Eigentümer ebenfalls frustrierend ist, obwohl sie unter dem Diagramm Beispiel-URLs für jeden unterschiedlichen Core Web Vitals-Score angeben in der Google Search Console, aus der die Gruppierung manchmal impliziert werden kann.

Seitengruppierungen können für Websites wie Smashing Magazine gut funktionieren. Bei anderen Websites sind die Seitengruppierungen möglicherweise weniger klar, und viele Websites haben möglicherweise nur eine Gruppierung. Die Smashing-Site hat jedoch mehrere verschiedene Arten von Seiten: Artikel, Autorenseiten, Anleitungen und so weiter. Wenn eine Artikelseite langsam ist, weil das Autorenbild das LCP-Bild langsam lädt, dann wird das wahrscheinlich für alle Artikelseiten der Fall sein. Und die Lösung wird wahrscheinlich für alle Artikelseiten gleich sein. Daher ist es sinnvoll, sie dort zusammenzufassen (vorausgesetzt, Google kann die Seitengruppierungen genau ermitteln).

Es kann jedoch verwirrend werden, wenn eine Seite genug Besucher hat, um ihre eigene Core Web Vitals-Punktzahl zu erhalten, und sie besteht, aber mit einer fehlgeschlagenen Gruppe in einen Topf geworfen wird. Sie können die CrUX-API für alle Seiten Ihrer Website aufrufen, sehen, dass die meisten von ihnen erfolgreich sind, und dann verwirrt sein, wenn dieselben Seiten in der Search Console als fehlerhaft angezeigt werden, weil sie in einer Gruppe mit fehlerhaften URLs und den meisten davon zusammengefasst wurden der Datenverkehr für diese Gruppe ist zum Scheitern verurteilt. Ich frage mich immer noch, ob Search Console Core Web Vital-Daten auf Seitenebene verwenden sollte, wenn dies der Fall ist, anstatt immer die Gruppierungsdaten zu verwenden.

Wie auch immer, das erklärt die großen Schwankungen. Grundsätzlich scheinen sich alle Artikel (von denen es ungefähr 3.000 gibt) in derselben Seitengruppierung zu befinden (nicht unangemessen!), und diese Seitengruppierung ist entweder erfolgreich oder fehlgeschlagen. Wenn es umschaltet, bewegt sich der Graph dramatisch .

Über die CrUX-API können Sie auch detailliertere Daten zu den Core Web Vitals abrufen. Dies ist auf Ursprungsebene (dh für die gesamte Website) oder für einzelne URLs (wo genügend Daten vorhanden sind) verfügbar, aber ärgerlicherweise nicht auf Seitengruppierungsebene. Ich hatte den LCP auf Ursprungsebene mit der CrUX-API verfolgt, um eine genauere Messung des LCP zu erhalten, und es zeigte auch eine deprimierende Geschichte:

Wir können sehen, dass wir das Problem nie wirklich „gelöst“ haben und die Anzahl der „guten“ Seiten (die grüne Linie oben) immer noch zu nahe an der Erfolgsquote von 75 % lag. Außerdem hat sich der p75-LCP-Score (die gepunktete Linie, die die rechte Achse verwendet) nie wirklich weit genug von der 2500-Millisekunden-Schwelle entfernt. Es war kein Wunder, dass die vorbeigehenden und versagenden Seiten hin und her blätterten. Ein etwas schlechter Tag mit ein paar langsameren Seitenladevorgängen reichte aus, um die gesamte Seitengruppierung in die Kategorie „Verbesserung erforderlich“ umzukehren. Wir brauchten etwas mehr, um uns etwas Kopffreiheit zu verschaffen, um diese „schlechten Tage“ verkraften zu können.

An diesem Punkt war es verlockend, weiter zu optimieren . Wir wissen, dass der Artikeltitel das LCP-Element war, also was könnten wir tun, um das weiter zu verbessern? Nun, es verwendet eine Schriftart, und Schriftarten waren schon immer ein Fluch der Webleistung, also könnten wir uns das ansehen.

Aber warte eine Minute. Smashing Magazine WAR eine schnelle Seite. Die Ausführung mit Webleistungstools wie Lighthouse und WebPageTest zeigte dies – selbst bei langsameren Netzwerkgeschwindigkeiten. Und es hat alles richtig gemacht! Es wurde als statischer Site-Generator erstellt, sodass keine serverseitige Generierung erforderlich war. Es hat alles für die anfängliche Farbe eingebettet, sodass es außer dem HTML selbst keine Einschränkungen beim Laden von Ressourcen gab. Es wurde also von Netlify auf einem CDN gehostet sollte in der Nähe seiner Benutzer sein.

Sicher, wir könnten uns überlegen, die Schriftart zu entfernen, aber wenn das Smashing Magazine angesichts all dessen kein schnelles Erlebnis bieten konnte, wie könnte es dann jemand anderes tun? Das Bestehen von Core Web Vitals sollte weder unmöglich sein noch erfordern, dass Sie sich nur auf einer einfachen Website ohne Schriftarten oder Bilder befinden. Etwas anderes war hier oben und es war an der Zeit, ein bisschen mehr darüber herauszufinden, was vor sich ging, anstatt einfach blind eine weitere Optimierungsrunde zu versuchen.

Etwas tiefer in die Metriken eintauchen

Smashing Magazine hatte keine RUM-Lösung, also haben wir uns stattdessen mit den Daten des Chrome User Experience Report (CrUX) befasst, die Google für die etwa 8 Millionen Top-Websites sammelt, und stellen diese Daten dann für Abfragen in verschiedenen Formen zur Verfügung. Es sind diese CrUX-Daten, die die Daten der Google Search Console und letztendlich den Einfluss auf das Ranking beeinflussen. Wir haben die CrUX-API bereits oben verwendet, uns aber entschieden, uns mit anderen CrUX-Ressourcen zu befassen.

Wir haben die Sitemap und ein Google Sheets-Skript verwendet, um alle CrUX-Daten für die gesamte Website zu untersuchen, wo sie verfügbar waren (Fabian Krumbholz hat inzwischen ein viel umfassenderes Tool erstellt, um dies einfacher zu machen!) und es zeigte gemischte Ergebnisse für Seiten . Einige Seiten wurden bestanden, während andere, insbesondere ältere Seiten, fehlschlugen.

Das CrUX-Dashboard sagte uns nicht wirklich viel, was wir in diesem Fall nicht schon wussten: Das LCP war grenzwertig und tendierte leider nicht nach unten:

Das Graben in den anderen Statistiken (TTFB, First Paint, Online, DOMContentLoaded) hat uns keine Hinweise gegeben. Es gab jedoch einen spürbaren Anstieg der mobilen Nutzung:

War dies Teil eines allgemeinen Trends bei der Einführung mobiler Geräte? Könnte es das sein, was das mobile LCP trotz der Verbesserungen, die wir vorgenommen hatten, beeinträchtigte? Wir hatten Fragen, aber keine Antworten oder Lösungen.

Eine Sache, die ich mir ansehen wollte, war die globale Verteilung des Datenverkehrs. Wir haben in Google Analytics viel Verkehr aus Indien zu alten Artikeln festgestellt – könnte das ein Problem sein?

Die Indien-Verbindung

CrUX-Daten auf Länderebene sind nicht im CrUX-Dashboard verfügbar, aber im BigQuery-CrUX-Datensatz, und das Ausführen einer Abfrage dort auf der Ursprungsebene www.smashingmagazine.com zeigt eine große Diskrepanz bei den LCP-Werten (die SQL ist in enthalten die zweite Registerkarte dieses Links übrigens, falls Sie dasselbe auf Ihrer eigenen Domain ausprobieren möchten). Basierend auf den Top 10 Ländern in Google Analytics haben wir die folgenden Daten:

Indien-Traffic macht einen großen Teil des Smashing Magazine aus (16 %) und erfüllt nicht das Ziel für LCP auf Ursprungsebene. Das könnte das Problem sein und es war sicher eine weitere Untersuchung wert . Es gab auch Daten zu den Philippinen und Pakistan mit sehr schlechten Ergebnissen, aber das war eine relativ geringe Menge an Verkehr.

An diesem Punkt hatte ich eine Ahnung, was hier vor sich gehen könnte, und eine mögliche Lösung, also brachte Smashing Magazine dazu, die web-vitals Bibliothek zu installieren, um RUM-Daten zu sammeln und sie zur Analyse an Google Analytics zurückzusenden. Nach ein paar Tagen des Sammelns haben wir den Web Vitals-Bericht verwendet, um uns viele Daten auf eine Weise zu geben, die wir vorher nicht sehen konnten, insbesondere die Aufschlüsselung auf Länderebene:

Und da war es. Alle führenden Länder in der Analyse hatten sehr gute LCP-Werte, mit einer Ausnahme: Indien. Smashing Magazine verwendet Netlify, ein globales CDN, das eine Präsenz in Mumbai hat, also sollte es so leistungsfähig sein wie andere Länder, aber einige Länder sind einfach langsamer als andere (dazu später mehr).

Der mobile Datenverkehr für Indien lag jedoch nur knapp außerhalb der 2500-Grenze und es war nur das am zweithäufigsten besuchte Land. Die guten Ergebnisse in den USA hätten doch eigentlich ausreichen müssen, um das auszugleichen? Nun, die beiden obigen Grafiken zeigen die Reihenfolge der Länder nach Verkehr. Aber CrUX zählt Mobil- und Desktop-Traffic separat (und übrigens auch Tablets, aber das scheint niemanden zu interessieren!). Was passiert, wenn wir den Datenverkehr nur auf mobilen Datenverkehr filtern ? Und noch einen Schritt weiter – nur mobiler Chrome-Traffic (da nur Chrome CrUX speist und daher nur Chrome für CWV zählt)? Nun, dann erhalten wir ein viel interessanteres Bild:

Indien ist in gewisser Weise tatsächlich der größte mobile Chrome-Besucher – fast das Dreifache des zweithöchsten Besuchers (USA)! Auch die Philippinen mit ihrem schlechten Score sind dort auf den dritten Platz geschossen, und Nigeria und Pakistan sind mit ihren schlechten Scores ebenfalls in den Top 10 zu finden. Jetzt machten die schlechten LCP-Gesamtergebnisse auf Mobilgeräten allmählich Sinn.

Während das Handy den Desktop als beliebteste Art des Internetzugangs in der sogenannten westlichen Welt überholt hat, gibt es hier immer noch eine faire Mischung aus Handy und Desktop – oft verbunden mit unseren Arbeitszeiten, in denen viele von uns sitzen vor einem Schreibtisch. Die nächste Milliarde Nutzer sind möglicherweise nicht dieselben, und Mobilgeräte spielen in diesen Ländern eine viel größere Rolle . Die obigen Statistiken zeigen, dass dies sogar für Websites wie das Smashing Magazine gilt, von denen Sie vielleicht denken, dass sie mehr Verkehr von Designern und Entwicklern erhalten würden, die beim Entwerfen und Entwickeln vor Desktops sitzen!

Da CrUX nur von Chrome-Benutzern misst , bedeutet dies außerdem, dass Länder mit mehr iPhones (wie die USA) einen viel kleineren Anteil ihrer mobilen Benutzer in CrUX und damit in Core Web Vitals vertreten haben, was den Effekt dieser Länder zusätzlich verstärkt.

Core Web Vitals sind global

Core Web Vitals hat keinen unterschiedlichen Schwellenwert pro Land, und es spielt keine Rolle, ob Ihre Website von verschiedenen Ländern besucht wird – es registriert einfach alle Chrome-Benutzer gleich. Google hat dies zuvor bestätigt, daher wird das Smashing Magazine den Ranking-Boost nicht für die guten USA-Ergebnisse erhalten, und nicht für die indischen Benutzer. Stattdessen gehen alle Benutzer in den Schmelztiegel , und wenn die Punktzahl für diese Seitengruppierungen den Schwellenwert nicht erreicht, wird das Ranking-Signal für alle Benutzer beeinflusst.

Leider ist die Welt kein ebener Ort. Und die Webleistung ist von Land zu Land sehr unterschiedlich und zeigt eine klare Kluft zwischen reicheren und ärmeren Ländern. Technologie kostet Geld, und viele Länder konzentrieren sich mehr darauf, ihre Bevölkerung überhaupt online zu bringen, als die Infrastruktur kontinuierlich auf die neueste und beste Technologie aufzurüsten.

Das Fehlen anderer Browser (wie Firefox oder iPhones) in CrUX war schon immer bekannt, aber wir haben es immer eher als blinden Fleck zum Messen der Leistung von Firefox oder iPhone angesehen. Dieses Beispiel zeigt, dass die Auswirkungen viel größer sind , und bei Websites mit globalem Datenverkehr verzerrt es die Ergebnisse erheblich zugunsten von Chrome-Nutzern, was oft arme Länder bedeutet, was oft eine schlechtere Konnektivität bedeutet.

Sollten Core Web Vitals nach Ländern aufgeteilt werden?

Einerseits scheint es unfair, Websites auf dem gleichen Standard zu halten, wenn die Infrastruktur so unterschiedlich ist. Warum sollte das Smashing Magazine bestraft oder auf einen höheren Standard gestellt werden als eine ähnliche Website, die nur von Designern und Entwicklern aus der westlichen Welt gelesen wird? Sollte das Smashing Magazine indische Benutzer blockieren, um die Core Web Vitals bei Laune zu halten (ich möchte hier ganz klar sagen, dass dies nie zur Sprache kam, also nehmen Sie dies bitte als Autor, der den Punkt macht, und nicht als Taschenspielertrick auf Smashing!).

Auf der anderen Seite riskiert das „Aufgeben“ einiger Länder durch Akzeptieren ihrer Langsamkeit, dass sie dauerhaft auf die niedrigere Stufe verbannt werden, in der viele von ihnen sind. Es ist kaum die Schuld des durchschnittlichen indischen Lesers des Smashing Magazine, dass ihre Infrastruktur langsamer ist, und in vielerlei Hinsicht, Dies sind die Menschen, die mehr Hervorhebung und Mühe verdienen, anstatt weniger!

Und es ist nicht nur eine Debatte zwischen reichen Ländern und armen Ländern. Nehmen wir das Beispiel einer französischen Website, die sich an Leser in Frankreich richtet, durch Werbung oder Verkäufe aus Frankreich finanziert wird und in diesem Land eine schnelle Website hat. Wenn die Website jedoch von vielen französischen Kanadiern gelesen wird, aber leidet, weil das Unternehmen kein globales CDN verwendet, sollte dieses Unternehmen dann in der französischen Google-Suche leiden, weil es für diese kanadischen Benutzer nicht so schnell ist? Sollte das Unternehmen durch die Bedrohung durch Core Web Vitals „als Lösegeld gehalten“ werden und in das globale CDN investieren müssen, um diese kanadischen Leser und damit Google bei Laune zu halten?

Nun, wenn ein ausreichend großer Teil Ihrer Zuschauer darunter leidet, dann ist es genau das, was die Initiative von Core Web Vital zum Vorschein bringen soll. Dennoch ist es ein interessantes moralisches Dilemma, das ein Nebeneffekt der Core Web Vitals-Initiative ist, die mit der Verbesserung des SEO-Rankings verbunden ist: Geld verändert immer die Dinge!

Eine Idee könnte sein, die Grenzwerte gleich zu halten, sie aber pro Land zu messen . Die französische Google-Suchseite könnte diesen Nutzern auf Französisch einen Ranking-Boost geben (weil diese Nutzer CWV für diese Seite bestehen), während Google Search Canada dies möglicherweise nicht tut (weil sie scheitern). Das würde gleiche Wettbewerbsbedingungen schaffen und Standorte für jedes Land messen, selbst wenn die Ziele dieselben sind.

In ähnlicher Weise könnte das Smashing Magazine in den USA und anderen Ländern, in denen sie bestehen, einen guten Rang einnehmen, aber im Vergleich zu anderen indischen Websites (wo die Tatsache, dass sie sich im Segment „Verbesserungsbedarf“ befinden, tatsächlich immer noch besser sein könnte als viele Websites dort, vorausgesetzt sie alle leiden unter den gleichen Leistungseinschränkungen).

Leider denke ich, dass sich das negativ auswirken würde, da einige Länder wieder ignoriert werden, während Websites nur Investitionen in die Webleistung für lukrativere Länder rechtfertigen. Außerdem sind die Core Web Vitals, wie dieses Beispiel bereits zeigt, bereits kompliziert genug, ohne dass fast 200 zusätzliche Dimensionen ins Spiel kommen, indem man eine für jedes Land der Welt hat!

Wie kann man es also beheben?

Wir wussten jetzt also endlich, warum das Smashing Magazine Schwierigkeiten hatte, Core Web Vitals zu bestehen, aber was, wenn überhaupt, könnte dagegen getan werden? Der Hosting-Anbieter (Netlify) hat bereits das Mumbai CDN, das daher einen schnellen Zugriff für indische Benutzer bieten sollte. War dies also ein Netlify-Problem, um das zu verbessern? Wir hatten die Seite so weit wie möglich optimiert, also mussten sie damit leben? Nun nein, wir kehren jetzt zu unserer Idee von vorhin zurück: die Webfonts noch ein bisschen optimieren .

Wir könnten die drastische Option wählen, überhaupt keine Schriften auszuliefern. Oder vielleicht Schriftarten nicht an bestimmte Orte zu liefern (obwohl das angesichts der SSG-Natur der Website des Smashing Magazine komplizierter wäre). Alternativ könnten wir auf der Grundlage bestimmter Kriterien warten und Schriftarten im Frontend laden, aber das riskierte, die Schriftarten für andere zu verlangsamen, während wir diese Kriterien bewerteten. Wenn es nur ein benutzerfreundliches Browsersignal gäbe, wann wir diese drastische Maßnahme ergreifen sollten. So etwas wie der SaveData-Header, der genau dafür gedacht ist!

SaveData Und prefers-reduced-data

SaveData ist eine Einstellung, die Benutzer in ihrem Browser aktivieren können, wenn sie wirklich Daten speichern möchten. Dies kann für Personen mit eingeschränkten Datenplänen nützlich sein, für diejenigen, die mit teuren Roaming-Gebühren reisen, oder für diejenigen in Ländern, in denen die Infrastruktur nicht ganz so schnell ist, wie wir es uns wünschen.

Benutzer können diese Einstellung in Browsern aktivieren, die sie unterstützen, und dann können Websites diese Informationen verwenden, um ihre Websites noch mehr als gewöhnlich zu optimieren. Möglicherweise werden Bilder mit geringerer Qualität zurückgegeben (oder Bilder vollständig deaktiviert!) oder keine Schriftarten verwendet. Und das Beste an dieser Einstellung ist, dass Sie auf die Anfrage des Benutzers reagieren und nicht willkürlich eine Entscheidung für ihn treffen (viele indische Benutzer haben möglicherweise einen schnellen Zugriff und möchten keine eingeschränkte Version der Website!).

Die Speicherdaten-Informationen sind auf zwei (bald drei!) Arten verfügbar:

1. Bei jeder HTTP-Anforderung wird ein SaveData Header gesendet. Dadurch können dynamische Backends den zurückgegebenen HTML-Code ändern.
2. Die NetworkInformation.saveData JavaScript-API. Dies ermöglicht Front-End-Skripten, dies zu überprüfen und entsprechend zu handeln.
3. Die kommende prefers-reduced-data Abfrage, die es CSS ermöglicht, abhängig von dieser Einstellung unterschiedliche Optionen festzulegen. Dies ist hinter einem Flag in Chrome verfügbar, aber noch nicht standardmäßig aktiviert, während die Standardisierung abgeschlossen ist.

Die Frage ist also, nutzen viele der Smashing Magazine-Leser (und insbesondere diejenigen in den Ländern, die mit Core Web Vitals zu kämpfen haben) diese Option, und können wir ihnen daher eine schnellere Website bieten? Nun, als wir das oben erwähnte web-vitals Skript hinzugefügt haben, haben wir uns auch entschieden, dies sowie den effektiven Verbindungstyp zu messen. Das vollständige Skript können Sie hier einsehen. Nach einiger Zeit der Sammlung konnten wir die Ergebnisse in einem einfachen /Google Analytics-Dashboard zusammen mit der Chrome-Browserversion anzeigen:

Die gute Nachricht war also, dass ein großer Teil der mobilen indischen Benutzer (etwa zwei Drittel) diese Einstellung eingestellt hatte. Die ECT war weniger nützlich, da die meisten als 4 g angezeigt wurden. Ich habe zuvor argumentiert, dass diese API immer weniger nützlich geworden ist, da die meisten Benutzer unter dieser 4g-Einstellung klassifiziert werden. Außerdem ist die effektive Verwendung dieses Werts für anfängliche Ladevorgänge mit Problemen behaftet.

Weitere gute Nachrichten, da die meisten Benutzer auf einem aktuellen Chrome zu sein scheinen und daher von neueren Funktionen wie der prefers-reduced-data profitieren würden, wenn sie vollständig verfügbar ist.

Ilya from the Smashing team applied the JavaScript API version to their font-loader script so additional fonts are not loaded for these users. The Smashing folks also applied the prefers-reduce-data media query to their CSS so fallback fonts are used rather than custom web fonts for the initial render, but this will not be taking effect for most users until that setting moves out of the experimental stage.

I Love That Graph In Google Search Console

And did it work? Well, we'll let Google Search Console tell that store as it showed us the good news a couple of weeks later:

Additionally, since this was introduced in mid-November, the original level LCP score has steadily ticked downwards:

There's still not nearly enough headroom to make me comfortable, but I'm hopeful that this will be enough for now, and will only improve when the prefers-reduced-data media query comes into play — hopefully soon.

Of course, a surge in traffic from mobile users with bad connectivity could easily be enough to flip the site back into the amber category, which is why you want that headroom, so I'm sure the Smashing team will be keeping a close eye on their Google Search Console graph for a bit longer, but I feel we've made the best efforts basis to improve the experience of users so I am hopeful it will be enough.

Impact Of The User Experience Ranking Factor

The User Experience ranking factor is supposed to be a small differentiator at the moment, and maybe we worried too much about a small issue that is, in many ways outside of our control? If Smashing Magazine is borderline, and the impact is small, then maybe the team should worry about other issues instead of obsessing over this one? But I can understand that and, as I said, Smashing Magazine are knowledgeable in performance and so understand why they wanted to solve — or at the very least understand! — this issue.

So, was there any impact? Interestingly we did see a large uptick in search impression in the last week at the same time as it flipped to green:

It's since reverted back to normal, so this may have been an unrelated blip but interesting nonetheless!

Schlussfolgerungen

So, an interesting case study with a few important points to take away:

• When RUM (including CrUX or Google Search Console) tells you there's a problem, there probably is! It's all too easy to try to compare your experiences and then blame the metric.
• Implementing your own RUM solution gives you access to much more valuable data than the high-level data CrUX is intended to provide, which can help you drill down into issues, plus also give you potentially more information about the devices your site visitors are using to visit your site.
• Core Web Vitals are global, and that causes some interesting challenges for global sites like Smashing Magazine. This can make it difficult to understand CrUX numbers unless you have a RUM solution and perhaps Google Search Console or CrUX could help surface this information more?
• Chrome usage also varies throughout the world, and on mobile is biased towards poorer countries where more expensive iPhones are less prevalent.
• Core Web Vitals are getting much better at measuring User Experience. But that doesn't mean every user has to get the same user experience — especially if they are telling you (through things like the Save Data option) that they would actually prefer a different experience.

I hope that this case study helps others in a similar situation, who are struggling to understand their Core Web Vitals. And I hope you can use the information here to make the experience better for your website visitors.

Viel Spaß beim Optimieren!

Note: It should be noted that Vitaly, Ilya and others at the Smashing team did all the work here, and a lot more performance improvements were not covered in the above article. I just answered a few queries for them on this specific problem over the last 6 months and then suggested this article might make an interesting case study for other readers to learn from.