Gaming Google — Der perfekte Leuchtturm-Score

Ich habe immer gezögert, meinen Code zu teilen. Es ist nicht so, dass ich es für unterdurchschnittlich halte, und ich werde auch nicht vom Imposter-Syndrom geplagt. Es ist nur so, dass das Teilen von Code einen Einblick in den Wahnsinn bietet, der mir in den Sinn kommt und der sich für alle anderen irgendwie grausam anfühlt. Erlauben Sie mir, Sie auf eine Reise zu begleiten, die mich fast an den Rand der geistigen Gesundheit gebracht hat. Alles begann mit dem Lighthouse-Update von Google.

Für SEO-Laien bedeutete das Lighthouse-Update von Google eine erhebliche Veränderung des Suchrankings, die von der Leistung einer Website und der Einhaltung von Best Practices abhing. Wenn Sie Ihre Website testen möchten, öffnen Sie sie einfach in Chrome auf einem Desktop, drücken Sie F12, um die Chrome-Entwicklertools zu öffnen, und klicken Sie dann auf den Tab „Lighthouse“. Wählen Sie entweder Desktop oder Mobile und klicken Sie auf „Analysieren“. Nach etwa einer Minute erhalten Sie fünf Punkte, die jeweils zwischen 0 und 100 liegen, für Leistung, Barrierefreiheit, Best Practice, SEO und Progressive Web App (PWA).

Bevor ich auf die technischen Details eingehe, möchte ich mich vorstellen. Mein Name ist Jonathan Grantham und ich bin stolzer Besitzer eines kleinen B2B-SaaS-Unternehmens, Nexoid, das sich auf ERP- und ITSM-Software spezialisiert hat. Die Website, über die ich in diesem Artikel spreche, ist www.nexoid.com. Schauen Sie doch mal rein, öffnen Sie den Quellcode. Du kannst mir auch auf LinkedIn folgen. Mein Profil ist www.linkedin.com/in/jonathongrantham/

Nach der Veröffentlichung des Google Chrome Lighthouse-Updates habe ich getan, was jeder gewissenhafte Geschäftsinhaber tun würde: Ich habe meine Website überprüft. Zu meiner großen Bestürzung waren die Ergebnisse alles andere als zufriedenstellend. Mit Punktzahlen von 21/100 für Leistung, 30/100 für Barrierefreiheit, 45/100 für Best Practice, 11/100 für SEO und einem Misserfolg für PWA war ich schockiert. Ich persönlich hatte die Website, eine ziemlich standardmäßige Single Page Architecture, mit React.js erstellt. Die Ergebnisse waren ein vernichtender Schlag.

Unbeeindruckt von dem anfänglichen Rückschlag, startete ich MS Code und begann, die Probleme nacheinander anzugehen, wobei die Leistung mein erstes Ziel war. Die im Lighthouse-Tool bereitgestellten Anleitungen erwiesen sich als sehr nützlich. Ich habe alle Bilder von JPEGs und PNGs in moderne WebP-Dateien konvertiert und sichergestellt, dass jedes IMG-Tag mit einer Breite- und Längeneigenschaft ausgestattet war, um Layoutverschiebungen zu verhindern. Allein diese Modifikationen haben meine Punktzahl von 21/100 auf 60/100 erhöht. Es war eine deutliche Verbesserung, aber alles andere als perfekt. Der einzige verbleibende Vorschlag war, „unbenutztes JavaScript zu reduzieren“, was nicht besonders hilfreich war. Das einzige vorhandene JavaScript war das React.js Framework, da alles andere entfernt worden war.

Mit Nexoid war AM Digital in der Lage, die Vorteile einer einheitlichen ITSM-Lösung auch auf ihre kundenorientierten Abläufe auszudehnen. Das in Azure integrierte Kundenportal bot ihren Kunden ein vernetzteres, dynamischeres und nahtloseres Erlebnis, was zu einer höheren Kundenzufriedenheit und Kundenbindung führte. Das Portal ermöglichte die Echtzeitsynchronisierung mit den Kundendaten und stellte so sicher, dass alle Informationen aktuell und korrekt waren, wodurch die Servicebereitstellung verbessert und die Beziehung zwischen Kunde und Unternehmen gestärkt wurde.

Trotz meiner beharrlichen Bemühungen, das Problem zu beheben, stieß ich auf ständige Hindernisse. Ich habe versucht, Teile von React.js zu entfernen, habe das „Lazy Loading“ untersucht und verschiedene Optimierer und Kompressionen getestet. Das Problem ging jedoch auf React.js selbst zurück, das ungefähr ein halbes Megabyte groß war.

Ich kann fast hören, wie erfahrene Webentwickler schreien: „Benutze React nicht für eine Website! Es ist für die Erstellung von Webanwendungen gedacht!“ Dessen bin ich mir jetzt durchaus bewusst.

Was als scheinbar einfache Aufgabe der Konvertierung einiger Bilder begann, hat sich nun mithilfe eines neuen Frameworks zu einer kompletten Überarbeitung der Website entwickelt. Frustriert und mit ein paar ausgesuchten Worten machte ich mich auf die Suche nach einem geeigneten Ersatz. Ich habe zuerst Vue und später Angular in Betracht gezogen, die wohl größten Konkurrenten von React.js. Beide stellten jedoch dasselbe Problem auf.

Um die Dinge zu vereinfachen, beschloss ich, mich mit älteren Technologien zu befassen, und probierte jQuery aus. Dennoch stieß ich auf dasselbe Problem. Es wurde deutlich, dass es kein handelsübliches Single Page Architecture-Framework gab, das die Google-Gottheiten besänftigen könnte.

Es schien, als ob meine einzige verbleibende Option darin bestand, auf Vanilla-JavaScript zurückzugreifen.

Meine Versuchsreihe begann mit einer einfachen HTML-Seite ohne JavaScript. Dann habe ich eine HTML-Seite mit einem Div ausprobiert, dessen Inhalt ersetzt werden konnte. Mir wurde schnell klar, dass mehrere gleichzeitige Änderungen an der Seite über JavaScript zu Strafen von Lighthouse geführt haben. Die Lösung bestand darin, den Inhalt des Body-Tags als Zeichenfolge zu manipulieren und ihn dann wieder zu integrieren, wodurch nur eine einzige sichtbare DOM-Änderung erstellt wurde.

Ich hatte jetzt eine minimalistische HTML-Seite mit einem leeren Body-Tag, ergänzt durch eine kleine Onload-Funktion im Head-Tag. Diese Funktion überprüfte die URL und führte eine HTML-GET-Anfrage aus, um die entsprechende Textdatei abzurufen, die den Body-HTML der Seite enthält. Man könnte meinen, dass dies eine geeignete Lösung ist. Leider war es nicht ausreichend, als ich versuchte, die JavaScript-Funktionalität dynamisch zu laden.

Im Gegensatz zu anderen Tags wird es nicht ausgeführt, wenn Sie ein Skript-Tag mit einer einfachen Warnung („yes this fired“) zur Zeichenfolge für den Hauptinhalt hinzufügen. Obwohl dies nicht ideal war, bestand eine Problemumgehung darin, die Textzeichenfolge zu analysieren, den gesamten Inhalt des Skript-Tags zu identifizieren und sie in eine JavaScript-Evaluierungsfunktion einzufügen. Der Ansatz war einigermaßen effektiv, geriet aber beim Umgang mit Namespaces ins Stocken, und die Entwicklerkonsole wurde mit unschönen Warnungen überflutet. Die Lösung bestand darin, die Skript-Tags aus dem HTML-Code zu extrahieren und sie nach dem Rendern des DOM als Skriptelement hinzuzufügen. Google hat diese Aktion aus irgendeinem Grund nicht bestraft.

Es wurden Fortschritte erzielt, und ich hatte eine grundlegende Single Page Architecture-Lösung. Aber nicht so schnell. Google ist zwar bei der Indexierung von Single Page Architecture-Seiten effizient (sie öffnen sie in einem Browser, lassen das gesamte JavaScript laufen und scannen dann das DOM), aber Bing, Yahoo und andere große Suchmaschinen verwenden eine ähnliche, einfachere Methode. Die meisten anderen Plattformen wie Facebook, Reddit, LinkedIn und WhatsApp rufen jedoch nur die HTML-Datei ab und rufen eine kleine HTML-Datei mit einem leeren Text ab. Meine Lösung war nicht praktikabel. Ich musste dieses Konzept nun für jede Seite der Website replizieren und das JavaScript einbeziehen, um in den Single Page Architecture-Modus zu wechseln, wenn ein Benutzer auf einen Link klickte.

Ich benötigte ein Tool, das auf der Grundlage meiner Lösung HTML für jede Seite generieren kann. Mir kam der Gedanke, dass mir die perfekte Ressource zur Verfügung stand: mein eigenes ERP-System, Nexoid. Ich habe ein Nexoid-Modell erstellt, das eine Website und Webseitendatenobjekte umfasst. Der Website-Datensatz erleichterte die Erstellung einer generischen Vorlagen-Webseite, während die Webseitendatensätze den Inhalt für jede einzelne Seite enthielten. Das letzte Puzzleteil war eine Workflow-Funktion oder ein Skript, das den Webseitendatensatz und alle zugehörigen Webseitendatensätze lesen konnte, um die HTML-Dateien zu generieren. Nach ein paar Tagen war es betriebsbereit. Ich hatte ein grundlegendes Content Management System (CMS) erstellt. Die Entwicklung eines CMS bis zu diesem Punkt ist nicht allzu komplex. Die eigentliche Herausforderung besteht darin, andere CMS-Workflows, Genehmigungen, Lokalisierungen, Vorschauen usw. zu integrieren.

Eine wichtige Anforderung an die neue Website war die Lokalisierung. Unser Ziel war es, sie in 11 Sprachen zu veröffentlichen. Als IT-Unternehmen habe ich mich natürlich für technologische Lösungen interessiert. Anstatt für jede Seite einen Übersetzer einzustellen, habe ich mich für AWS Translate entschieden. KI-Übersetzer sind zwar anständig, aber nicht perfekt, und die Fehler sind auffällig genug, um einen nicht-menschlichen Ursprung aufzudecken. Ein französischsprachiger Mitarbeiter bewertete die KI-Übersetzung und gab ihr eine Bewertung von 6/10. Er beschrieb sie als „verständliches, aber nicht richtiges Französisch“.

Wir sind jedoch auf einen wertvollen Trick gestoßen. Wir haben festgestellt, dass der englische Text zuerst über ChatGPT eingespeist und dann „aufgeräumt“ werden muss, und dann wieder eingefügt wird der Text so umformuliert, dass er immer noch Englisch ist, aber viel besser mit den Sprachmodellen kompatibel ist. Die Verwendung des ChatGPT-umformulierten Englischen als Grundlage für die Übersetzung verbessert die Übersetzungsqualität erheblich und erhöht sie auf 9 oder sogar perfekte 10 von 10 Punkten.

Nachdem ich eine solide technologische Grundlage für die Erstellung der Website entwickelt hatte, machte ich Fortschritte. Als wir anfingen, komplexere Seiten zu erstellen, ergab sich jedoch eine neue Herausforderung. Gemäß den neuen Lighthouse-Richtlinien wurde es notwendig, alles JavaScript, CSS und HTML in einer einzigen Datei zu konsolidieren. Dies galt auch für die Single Page Architecture-Versionen.

Wir haben darauf zurückgegriffen, alle JavaScript- und CSS-Dateien als Inline-Tags einzufügen. Eine ähnliche Strategie war für die Single Page Architecture-Version erforderlich. Wir haben eine JSON-Datei erstellt, die alle Skripte, Stile und HTML enthält.

Lighthouse identifizierte das nächste Problem in der Größe der Assets; die HTML- und JSON-Seitendateien waren übermäßig groß. Ich habe dieses Problem mit 'minify' gelöst, einer Bibliothek von Node.js, die speziell zum Komprimieren von HTML-, CSS- und JavaScript-Dateien entwickelt wurde. Diese Lösung führte zu einer Reduzierung der Textdateigröße um über 40%. Darüber hinaus bot Minify den zusätzlichen Vorteil der Verschleierung, wodurch der Rohcode schwieriger zu lesen war, was die Sicherheit erhöhte.

Lassen Sie uns auf das Thema Hosting eingehen. Traditionell arbeitet ein Content Management System (CMS) über einen Anwendungsserver, der die HTML-Anfrage des Benutzers bearbeitet. Es interpretiert die Seitenanforderung von der URL, findet die entsprechenden Assets in einer Datenbank, ruft den Datenbankeintrag ab (möglicherweise zusammen mit anderen), verarbeitet die Informationen, um die Seite zusammenzustellen, und übermittelt sie schließlich als flaches HTML-Dokument an den Endbenutzer. Diese Beschreibung bezieht sich hauptsächlich auf die erste HTML-Anfrage, wenn ein Benutzer eine neue Website besucht, obwohl mir AJAX und andere ähnliche Technologien bekannt sind.

Dieses konventionelle Modell weist jedoch im Zusammenhang mit der neuen Lighthouse-Welt einige Nachteile auf. Erstens führen die Hin- und Herkommunikation zwischen dem Anwendungsserver und dem Datenbankserver sowie die Seitenzusammenstellung zu Verzögerungen. Zweitens sind ein Anwendungsserver und ein Datenbankserver in seiner einfachsten Form nur physisch an einem einzigen Standort verfügbar. Diese Konfiguration ist hervorragend, wenn Sie sich im selben Gebäude oder in derselben Stadt befinden, aber deutlich weniger effizient, wenn Sie versuchen, vom anderen Ende der Welt auf die Website zuzugreifen. Beispielsweise beträgt die durchschnittliche Ping-Latenz zwischen Australien und Großbritannien ungefähr 250 Millisekunden.

Unsere Lösung für diese Herausforderungen beinhaltet die Verwendung von AWS S3 für das Hosten der statischen Dateien, die durch das zuvor erwähnte Veröffentlichungsskript generiert wurden, und AWS CloudFront für die globale Inhaltsverteilung. Zum Zeitpunkt der Erstellung dieses Artikels verteilte AWS CloudFront Inhalte in über 90 Städten in 47 Ländern. Für eine Person in Melbourne, Australien, die auf eine britische Website zugreift, reduzierte AWS CloudFront die Ping-Latenz von 250 Millisekunden auf nur 13 Millisekunden (dies ist der Zeitunterschied zwischen Melbourne und AWS-Edge-Servern in Sydney).

Wir kommen nun zur Progressive Web Application (PWA) -Komponente des Lighthouse-Tests, über die ich bisher nicht viel nachgedacht hatte. Für Unbekannte: Eine PWA beinhaltet einen JavaScript-Servicemitarbeiter, der die Website als Webanwendung verwaltet. Wenn das ein bisschen komplex ist, betrachte es so: Es handelt sich im Wesentlichen um ein automatisches Tool zum Herunterladen und Zwischenspeichern. Wenn ein Benutzer Ihre Website besucht, besteht das Ziel darin, seine nachfolgenden Anfragen so schnell und reibungslos wie möglich zu stellen. Mit dem PWA Service Worker können Sie bereits die nächsten Assets auf den lokalen Computer des Benutzers herunterladen, sodass keine weitere Internet-GET-Anfrage erforderlich ist.

Zum Zeitpunkt der Erstellung dieses Artikels ist die Nexoid-Website mit nur 19 Seiten relativ klein. Diese 19 Seiten sind jedoch in 11 verschiedene Sprachen übersetzt, was insgesamt 209 Seiten ergibt. Anfangs habe ich versucht, jedes Asset in den Service Worker herunterzuladen, was ungefähr 5 MB betrug. Diese Größe war zu groß für eine erste Ladung, und Lighthouse hat mich dafür bestraft. Ich entschied mich dafür, nur die JSON-Dateien der englischen Seite herunterzuladen, die alle notwendigen CSS-, HTML- und JavaScript-Elemente für die Anzeige der einzelnen Seiten enthalten.

Die endgültige Struktur sieht wie folgt aus: Ein S3-Bucket enthält die kompilierten HTML-Dateien, die ohne die Erweiterung .html benannt sind. Zum Beispiel steht www.nexoid.com/en für das englische Homepage-HTML, www.nexoid.com/de für das deutsche Homepage-HTML und www.nexoid.com/en/platform bezieht sich auf das englische Plattform-HTML und so weiter. Darüber hinaus gibt es JSON-Dateien, die die Teile des Körpers und des Kopfes enthalten, die sich beim Navigieren zwischen Seiten ändern, z. B. https://www.nexoid.com/en.json, https://www.nexoid.com/de.json und https://www.nexoid.com/en/platform.json.

Zusammenfassend lässt sich sagen, dass das Verständnis von Lighthouse eine große Herausforderung darstellte. Ich bin skeptisch, dass traditionelle, sofort einsatzbereite CMS-Produkte diese Aufgabe effektiv bewältigen können. Wenn ich über meine Erfahrung mit Plattformen wie WordPress und Drupal nachdenke, fällt es mir schwer zu glauben, dass sie optimiert werden könnten, um einen perfekten Lighthouse-Score zu erzielen. Insgesamt denke ich, dass sich der Aufwand lohnt, und Google ist berechtigt, mehr Wert auf Leistung zu legen. Dieser Wandel ist und bleibt jedoch ein erhebliches Problem für Webdesigner und Agenturen.

Wenn Sie mehr über Lighthouse erfahren möchten oder die Produkte und Dienstleistungen von Nexoid besprechen möchten, zögern Sie bitte nicht, uns zu kontaktieren. Sie können uns über LinkedIn oder über die Seite „Kontakt“ auf unserer Website erreichen.