Core Web Vitals nicht wirklich dein Problem?
Google setzt auf die NUTZER von Software wie WordPress und nicht die Entwickler, um die Seiten für Core Web Vitals zu optimieren. Ist das fair?
Du bist nicht allein, wenn du darum kämpfst, die Core Web Vitals zu verbessern und nicht weiterkommst. Anekdotische Beweise legen nahe, dass es schwierig ist, eine hohe Core Web Vitals Performance zu erreichen. Der Grund dafür ist, dass Publisher und SEO versuchen, etwas zu reparieren, was technisch nicht kaputt ist.
Paradigmenwechsel in der Art, wie Websites entwickelt werden
Wir befinden uns in der Anfangsphase eines großen Paradigmenwechsels in der Art und Weise, wie Webseiten erstellt werden. Ein schnellerer Webhoster ist hilfreich, aber er wird die Probleme mit den Core Web Vitals nicht beheben.
Die Core Web Vitals werden nach dem mobilen Gerät berechnet, das deine Webseiten auf einem Mobiltelefon mit 3G oder 4G Geschwindigkeit runterschlürft. Dort kommen die Core Web Vitals Daten her und ein schneller Webserver nützt an dieser Stelle wenig, wenn der Download durch eine schlechte Internetverbindung am Telefon gedrosselt wird.
Bei der Verbesserung von Core Web Vitals geht es weniger um das Webhosting und mehr um die Korrektur des Codes.
Reparieren was nicht kaputt ist
WP Rocket hat kürzlich seine Website mit Gutenberg neu gestaltet. Das war ein mutiger und fast schon waghalsiger Schritt, wenn man bedenkt, dass Gutenberg zu diesem Zeitpunkt noch keine vollständigen Funktionen zur Website-Bearbeitung hatte.
Sie mussten anpassen, wie WordPress mit CSS und JavaScript umgeht, um die Google Page Experience Scores zu verbessern.
Mit anderen Worten, WP Rocket musste WordPress selbst anpassen, um seine Website so umzugestalten, dass sie in den Core Web Vitals gut abschneidet, und es zu etwas zu machen, wofür es nicht konzipiert wurde.
Core Web Vitals-Unfreundlichkeit
Die Core Web Vitals Standards sind nicht etwas, was die WordPress-Entwickler im Kopf haben, wenn sie WordPress erstellen. Das ist der Grund, warum das Einbetten von Tweets in einen Beitrag eine kumulative Layout-Verschiebung auslösen wird.
WordPress und Themes programmieren nicht für Google. Sie programmieren für die Bedürfnisse von Publishern, was bis Mai 2020 kein Bedürfnis der Publisher war.
Es ist auch nicht nur WordPress. Die meisten anderen Content Management Systeme haben die Best Practices von Core Web Vitals nicht in sich integriert.
Das bedeutet nicht, dass mit WordPress etwas nicht stimmt. Es ist nichts falsch mit WordPress, weil Google sagt, dass da etwas falsch ist.
Core Web Vitals sind kein WordPress-Problem
Core Web Vitals sind eine Reihe von Metriken, die unabhängig von Google entwickelt und der Publisher- und SEO-Community zur Verfügung gestellt wurden.
WordPress hat nichts damit zu tun. Core Web Vitals erschien im Mai 2020, offenbar ohne jegliche Koordination oder Rücksprache mit dem Entwickler-Ökosystem.
Auf der WordPress Seite geht die Entwicklung weiter, als ob Core Web Vitals nicht existieren würde. Während auf der Publisher- und SEO-Seite es die Nutzer von WordPress sind, die mit der Aufgabe belastet werden, WordPress, Drupal, phpBB etc. zu „reparieren“.
In einer perfekten Welt liegt die Aufgabe, ein System zu schaffen, das die Bedürfnisse der Nutzer anspricht, auf der Seite der Entwickler. Aber das ist nicht der Fall.
WordPress sieht Core Web Vitals nicht einmal als ein WordPress-Problem.
Als jemand einen Support-Thread in den WordPress-Foren darüber startete, wurde ihm gesagt, er solle in Googles Support-Forum fragen.
"Du solltest in einem Google-Forum fragen, da WordPress nichts damit zu tun hat."Publisher und SEO-Community mit Compliance belastet
WordPress-Publisher sitzen in der Klemme, wenn sie versuchen, ihre Websites an einen Standard anzupassen, für den diese Websites nie entwickelt wurden.
Das ist der Grund, warum so viele mit Core Web Vitals zu kämpfen haben. Publisher und SEOs sind mit dem Versuch belastet, etwas zu reparieren, was idealerweise auf Code-Ebene behoben werden sollte.
Die Verbesserung der Core Web Vitals Scores kann sich anfühlen wie der Versuch, die Leistung eines Honda Civic auf den Standard einer Chevy Corvette zu bringen.
Die Entwickler haben keine Corvette gebaut. Sie haben einen Honda Civic gebaut.
Aber Google verlangt von den Fahrern (nicht von den Herstellern), dass sie die Leistung auf das Niveau einer Corvette verbessern. Erscheint dir das fair?
Ist es vernünftig, die Nutzer einer Software zu bitten, sie zu verbessern, anstatt die Entwickler der Software?
Das Problem der Softwarekonformität mit Core Web Vitals besteht auf der Code-Ebene, nicht auf der Benutzerebene.
Warum also werden Publisher und die SEO-Community damit belastet, etwas zu reparieren, von dem sie nur Nutzer sind?
Hilft Google dabei?
Google stellt eine Menge Tools zur Verfügung, um die Probleme zu diagnostizieren und bietet ausführliche Artikel, die erklären, wie man diese Code-Probleme beheben kann.
Aber das sind Coding-Probleme und keine User-Probleme.
Ein Beispiel für die Diskrepanz zwischen der Entwicklergemeinde und Google ist das Problem der kumulativen Layoutverschiebung, bei der sich die Webseite verschiebt und neu anordnet, während die Seitenelemente heruntergeladen werden.
Ein häufiger Grund für Cumulative Layout Shift ist, dass Bilder keine Höhen- und Breitenangaben haben. Google empfiehlt exotische Workarounds wie die Verwendung von CSS, um die Bilder mit Hilfe von Seitenverhältnissen zu stylen.
Der durchschnittliche Publisher und SEO wird wahrscheinlich nicht verstehen, was Aspect Ratio Boxen sind und wie man die Verhältnisse sitewide so berechnet, dass die Website nicht kaputt geht.
Wirf einen Blick auf die Beschreibung der Aspect Ratio Boxen, die Google verlinkt, und schau, ob es für dich Sinn macht:
Perfekte Quadrate und 16:9-Zeug ist toll, aber die Werte, die dafür verwendet werden, sind nur einfache Mathematik. Ein Seitenverhältnis kann alles sein, und sie sind in der Regel völlig willkürlich. Ein Video oder Bild kann auf jede beliebige Größe beschnitten werden.
Wie finden wir also das padding-top für unser 1127,34 × 591,44 SVG oben heraus?
Eine Möglichkeit ist die Verwendung von calc(), wie hier:
padding-top: calc(591.44 / 1127.34 * 100%);"Ach du meine Güte!
Hier ist ein weiteres Beispiel. Viele Web-Templates setzen die Bildbreiten per CSS automatisch (width: auto;), ohne die Höhe und Breite der Bilder festzulegen, um Bilder wie ein Logo so zu skalieren, dass sie in das Template passen, egal ob es auf einem mobilen oder einem Desktop-Gerät betrachtet wird. Das ist eine gängige Programmierpraxis, die Cumulative Layout Shift verursacht.
Dies sind die Gründe, warum WP Rocket die CSS- und JavaScript-Änderungen für die gesamte Website vornehmen musste.
Zum Beispiel lädt WordPress Gutenberg alle CSS, die es gibt, unabhängig davon, ob sie benötigt werden oder nicht. Also mussten die Entwickler von WP Rocket von Hand eine Lösung dafür programmieren.
Dies ist, wie WP Rocket erklärt, was sie als Teil ihres Redesigns getan haben:
"...wir haben mehrere Blöcke, die nicht verwendet wurden, veraltet. Wir haben ein benutzerdefiniertes Enqueue-System erstellt, um CSS- und JS-Blöcke nur dann zu laden, wenn sie benötigt werden. Es hat uns nur ein paar Minuten gekostet, dieses System zu entwickeln.
Wir haben uns auch entschieden, die Gutenberg-CSS-Datei nicht zu verwenden. Stattdessen "migrierten" wir das CSS, das wir tatsächlich benötigten, in unser eigenes Stylesheet, in eine eigene CSS-Datei. That did the trick."Ein Überdenken der Art und Weise, wie Seiten erstellt werden
Es ist wichtig, das Problem der Core Web Vitals zu verstehen. Google verlangt von Publishern und SEOs, dass sie an Lösungen schrauben, an denen die CMS-Entwickler-Community kein Interesse zeigt, sie anzugehen.
Hier ist ein Beispiel für die Art von Kompromissen, mit denen wir konfrontiert werden und wie Google die Art und Weise, wie wir Websites entwickeln, verändert.
Lass uns über Schriftarten sprechen.
Das Blockieren von Rendering-Ressourcen von Drittanbietern kann sich negativ auf das größte inhaltsreiche Bild auswirken. Ein häufiger Engpass ist das Herunterladen von Schriftarten von einer Drittanbieterseite wie Google Fonts.
Es gibt eine Reihe von Tricks, die eine Kombination aus der Verwendung des Preload-Link-Attributs und vielleicht etwas JavaScript usw. sind, die den Prozess des Herunterladens von Drittanbieter-Schriften Core Web Vitals-freundlich machen.
Aber würde es deine Seite wirklich schlechter machen, wenn du auf diese schicke Schriftart verzichtest?
Eine einfache Lösung, die helfen wird, besser zu punkten, ist die Umstellung der Website-Schriftart auf eine serifenlose Schriftart, die Apple, Windows und Android-Geräte bereits in ihrem System geladen haben.
Der Wechsel zu einer attraktiven Schriftart, die im Gerät eingebaut ist, bedeutet, dass die Seite nicht mehr darauf warten muss, eine ausgefallene Schriftart herunterzuladen.
Ein Ansatz kann etwa so aussehen:
font-family: Helvetica, Tahoma, sans-serif;
Wenn Android nicht bereits Helvetica oder Tahoma im Browser geladen hat, wird das Gerät die Seite mit der Roboto-Schriftart anzeigen.
Screenshot eines Beispiels für die Roboto-Schriftart
Für Menschen, die es gewohnt sind, ausgefallene Schriftarten zu verwenden, mag die Verwendung von Systemschriften extrem erscheinen. Aber es ist ein Beispiel für die Art von Kompromissen, die ein Web-Publisher machen muss, besonders wenn er sich in einer hart umkämpften Nische befindet.
Diese Art von Entscheidung ist ein No-Brainer für eine Affiliate-Seite, die sich auf Seitengeschwindigkeit und Konversionen konzentriert.
Ein Moment des Übergangs
Was heute passiert ist, dass wir in einem Moment des Übergangs leben. Die Dinge ändern sich von der Art und Weise, wie wir die Dinge in der Vergangenheit gemacht haben, zu der Art und Weise, wie die Entwickler die Dinge in der Zukunft machen werden (out of the box).
Die Entwickler haben auf die Nachfrage nach mobilfreundlichen Seiten reagiert. Mit der Zeit werden sie vielleicht auch auf die Nachfrage nach Seiten reagieren, die bei Core Web Vitals gut abschneiden.
Die Art und Weise, wie CMS-Systeme, Templates und Plugins gestaltet sind, haben nicht die Bedürfnisse der Publisher eingeholt, die eine Berücksichtigung der Core Web Vitals verlangen.
Bis auf Weiteres müssen SEOs und die Entwickler-Community „reparieren“, was nicht kaputt ist, um es mit Googles Vorstellung davon, wie das Web aussehen sollte, in Einklang zu bringen.
Natürlich ist eine Seite, die schnell lädt und sich nicht verschiebt, eine gute Sache. Aber von den Nutzern einer Software zu verlangen, die Software selbst zu verbessern, ist eine Belastung.
Zu diesem Zeitpunkt fällt die Last, den Code zu reparieren, auf die Nutzer der veröffentlichenden Software und nicht auf die Entwickler dieser Software. Fühlt sich das richtig an?
Was passieren kann, ist, dass einige es nützlich finden, so viel wie möglich zu reparieren und den Rest zu lassen, wenn WordPress und andere CMS Software aufholen.
