JavaScript Part 4: So prüft ihr eure Website auf JS-Probleme und Google-Kompatibilität

Das erwartet euch in diesem Beitrag

  • Welche Tools helfen beim Überprüfen von Websites?
  • Worauf ist dabei in erster Linie zu achten?
  • Wie stellt man sicher, dass neue Features keine Probleme verursachen?

In dieser Serie führen wir euch durch die SEO-Tücken von JavaScript:

JavaScript Part 1: Vorsicht bei der Implementierung

JavaScript Part 2: Wie Suchmaschinen sich das Internet erschließen

JavaScript Part 3: Wie stellt ein Browser Websites für uns dar?

JavaScript Part 4: So prüft ihr eure Website auf JS-Probleme und Google-Kompatibilität


Screenshot: JavaScript Teil 4

Abb. 1: Kommen die Hinweise aus dem Zeitalter des Internet Explorers wieder? Möglich ist es (Screenshot Windows).

In den vorangegangenen Beiträgen haben wir umrissen, warum es wichtig ist, sich mit dem Rendering von Websites im Allgemeinen und mit JavaScript im Besonderen zu befassen. Heute schauen wir uns an, wie eine Analyse der Vorgänge „unter der Haube“ unserer Website aussehen kann.

Ich zeige euch dazu anhand von zwei wichtigen Fragestellungen, welche Werkzeuge ihr einsetzen könnt. Ihr lernt, wie ihr vorgehen könnt, um euch einen Überblick über die Performance eurer Seite zu verschaffen. Und ihr seht, wie ihr Veränderungen einfach überwachen könnt.

JS-Analyse: Mit diesen Werkzeugen könnt ihr starten

Ach, gäbe es doch alles so zahlreich wie Analyse-Tools und Softwares … Ich habe nicht vor, einen umfassenden Überblick über den gesamten Werkzeugkasten zu geben, den ihr einsetzen könnt. Stattdessen konzentriere ich mich auf die wenigen wichtigen Tools, die die grundlegende Ausrüstung darstellen. Mit dieser Ausrüstung könnt ihr starten. Ergänzungen und Erweiterungen sind so zahlreich wie Pakete im Node Package Manager (NPM) (#badnerdjoke).

Chrome

Zuallererst und am wichtigsten im Toolset ist: Chrome respektive Chromium für alle Nicht-Windows-User oder Nicht-Mac-User. Alles, was ihr für die Analyse-Arbeit benötigt, bringt der Browser von Haus aus mit. Ich empfehle euch, die aktuellste Version einzusetzen – oder besser gleich Chrome Canary. Denn Chrome Canary bietet oft schon Funktionalitäten, die der aktuelle Chrome noch nicht hat, und diesen Vorsprung wollen wir gerne nutzen.

Zudem benötigt ihr einen älteren Chrome, den wir parallel zur aktuellsten Version installieren. Google verwendet derzeit noch Chrome41 als Basis des Web Rendering Service (WRS). Daher gehört eine 41er-Version immer in euren Werkzeugkasten – so lange bis Google den WRS aktualisiert und eine neuere Version seines Browsers einsetzt. Wir halten Augen und Ohren offen und geben Bescheid, sobald sich an dieser Baustelle etwas tut.

Add-ons/Plugins

Ich empfehle euch, ein Add-on zum Vergleichen von ungerendertem und gerendertem Quelltext zu installieren. Das ist zwar nicht zwingend erforderlich, da ihr beide Quelltext-Varianten auch direkt in Chrome untersuchen könnt (STRG + U öffnet den ungerenderten Ursprungsquelltext; F12 bzw. STRG + SHIFT + I zeigt euch den gerenderten Quelltext.). Ein Add-on kann es aber deutlich leichter machen, Unterschiede aufzudecken.

Add-on: View Rendered Source

Der Webdienst DiffChecker kann die gleiche Arbeit für euch übernehmen. Er ist in seiner Basisversion kostenfrei und kann Vergleiche auch speichern. Dies macht es besonders leicht, auch nach Anpassungen an der Website noch nachvollziehen zu können, welche Veränderungen wir im Blick haben wollten. Das tröstet auch über den zusätzlich notwendigen Arbeitsschritt, die Quelltext-Versionen von Hand in das Tool kopieren zu müssen.

Hinweis: Wenn ihr die Performance eurer Seite untersuchen wollt, rate ich euch, einen „nackten“ Chrome zu nutzen! Einige Plugins wirken sich direkt auf die Performance aus und verfälschen damit die Ergebnisse.

Lighthouse

Lighthouse ist aktuell das Tool zur Messung von Ladezeiten und wichtigen Performance-KPI sowie zur Ermittlung von Optimierungspotenzialen. Es gibt unterschiedliche Wege, Lighthouse einzusetzen.

Der einfachste ist, Google Chrome zu nutzen. Dieser bringt eine aktuelle Version von Lighthouse mit und ermöglicht so die direkte Analyse aller Seiten, die man mit dem Browser ansteuern kann. Das ist ideal, wenn man Seiten analysieren möchte, die nicht ohne Weiteres von externen Tools erreichbar sind. Das können zum Beispiel Entwicklungsumgebungen sein oder lokale Testanwendungen. Setzt ihr auf dieses Pferd, so gilt auch hier: Nutzt den „nackten“ Chrome. Außerdem ist es ratsam, Hintergrundtasks zu beenden. Wenn im Hintergrund der Frog seine Arbeit verrichtet oder euer letzter YouTube-Clip rendert, ist das Lighthouse Audit ein Fall für die Rundablage. 😉

Die Pagespeed Insights von Google sind eine weitere Möglichkeit: Der Webdienst erfordert eine funktionierende Internet-Verbindung und kann nur Seiten analysieren, auf die er zugreifen kann. Für Entwicklungsumgebungen oder lokale Anwendungen ist er also nicht zu gebrauchen. Dafür aber für den konfigurationsfreien und ressourcenschonenden Einsatz.

Die Pagespeed Insights bieten auch eine API, über die automatisiert Daten zu Websites abgefragt werden können. Dazu im späteren Verlauf des Beitrags mehr.

Die Chrome DevTools sind die dritte Variante. Sie bieten einen leicht abgewandelten Report und die Möglichkeit, Veränderungen der Performance darzustellen. Dies ist möglich, wenn man sich mit seinem Google-Konto in dem Tool anmeldet. Da das Tool im Hintergrund lediglich das „normale“ Lighthouse ausführt, könnt ihr euch hier den Report im gewohnten Format anzeigen lassen.

Lighthouse ist auch als NPM-Paket verfügbar und bietet somit die Möglichkeit, auf einem eigenen Server in eigene Test-Tools eingebunden zu werden. Für die Bastelfreunde unter euch: Ich stelle am Ende des Beitrags eine einfache Möglichkeit zur Automatisierung vor.

Mobile-Friendly Testing Tool

Ein kleines aber feines Tool zur JavaScript-Analyse bietet das Mobile-Friendly Testing Tool zur Prüfung auf Mobiltauglichkeit. Google hat dieses Werkzeug vor Kurzem in die Google Search Console integriert. Testet ihr eine Seite mit diesem Tool, habt ihr die Möglichkeit, einen Blick auf den gerenderten Quelltext der Website zu werfen. Außerdem könnt ihr euch Fehler und Warnungen der Konsole anzeigen lassen, die beim Rendern der Seite ausgegeben wurden.

Warum ist das erwähnenswert? Weil das Tool den gleichen Browser nutzt wie der WRS. Ihr könnt hier also direkt sehen, ob und womit der WRS eventuell Probleme haben könnte.

Für die Masse: JS-fähiger Crawler

Hier gibt es mittlerweile eine Reihe von Produkten am Markt, und die Möglichkeiten, sich ein eigenes Tool zu stricken, sind zahlreich.

Wenn es schnell gehen soll und der Testumfang überschaubar ist, ist der Screaming Frog SEO Spider das Tool der Wahl. Mit wenig Aufwand kann binnen kürzester Zeit ein Testcrawl angelegt und ausgewertet werden. Bitte beachtet in diesem Zusammenhang auch unseren Beitrag „Screaming Frog SEO Spider: Fünf wichtige Analysen (nicht nur) für Shop-Betreiber“ von Gastautor Markus Hövener.

Wichtig: Im Screaming Frog SEO Spider werkelt ein Chrome 60! Bedenkt das und testet unbedingt immer manuell mit der 41er-Version!

Die gängigen SEO- und SAAS-Lösungen bieten einen JavaScript Crawler. Allerdings solltet ihr hier vorher nachfragen, mit welchem Browser das Rendering erfolgt. Ideal wäre eine Chrome41-Version oder eine Eigenlösung mit der V8-Version 4.1.0, die im 41er-Chrome ihre Arbeit verrichtet.

Ein Vergleich der Quelltextvarianten ist mit dem Screaming Frog SEO Spider denkbar einfach.

Screenshot: JavaScript Teil 4

Abb. 2: Hier aktiviert ihr das JS Rendering im Screaming Frog (Quelle: Screenshot Screaming Frog SEO Spider).

Abb. 3: Lasst den Quelltext vor und nach dem Rendern speichern, um ihn später vergleichen zu können (Quelle: Screenshot Screaming Frog SEO Spider).

Ihr könnt dann im Tool die Screenshots ansehen und die Quelltextvarianten vergleichen:

Screenshot: JavaScript Teil 4

Abb. 4: Hier seht ihr den Screenshot der gerenderten Seite (Quelle: Screenshot Screaming Frog SEO Spider).

Screenshot: JavaScript Teil 4

Abb. 5: Die Quelltext-Varianten lassen sich durchsuchen. Hier seht ihr ein Skript und daneben das gerenderte Ergebnis des Skriptes (Quelle: Screenshot Screaming Frog SEO Spider).

User Agent Strings

Mit dem User Agent String gibt sich der Client (z. B. euer Browser oder ein Crawler) gegenüber dem Server zu erkennen, von dem er ein Dokument anfordert. Diese Information wird oft genutzt, um Inhalte dynamisch auszuspielen.

Einer dieser UA-Strings, den ihr immer wieder brauchen werdet, ist dieser: Googlebot Mobile User Agent String.

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1;
+http://www.google.com/bot.html)

Kopieren und Ablegen ist wärmstens empfohlen!

Die vollständige Liste der Bots hat Google hier bekanntgegeben: Search Console Hilfe: Google-Crawler (User-Agents).

Anwendungsfälle und Fragestellungen

Nun, da wir unseren Werkzeugkasten gepackt haben, können wir uns die Fragen ansehen, die wir damit bearbeiten können.

Legt vor den Untersuchungen fest, welche Inhalte auf welcher Seite wirklich wichtig sind und vorhanden sein müssen. Macht euch am besten eine Liste, die ihr abarbeiten könnt.

Zu den Inhalten, die unbedingt vorhanden sein und funktionieren müssen, gehören zum Beispiel:

  • Title & Description
  • Canonicals
  • Strukturierte Daten
  • Überschriften
  • SEO-relevanter Text (z. B. die Produktbeschreibung), aber auch eventuell ergänzende Inhalte, die sich in Tabs oder Overlays wiederfinden
  • Navigationslinks (Links! Nicht zwingend das animierte Flyout.)
  • Content-Links
  • Bilder, sofern sie für eure SEO-Strategie relevant sind (alt- und src-Attribut nicht übersehen!)

Die erste und einfachste Frage lautet:

„Hat Google Probleme beim Rendern meiner Seite?“

Ist die Seite bereits live, könnt ihr das Mobile-Friendly Testing Tool nutzen.

Die folgenden drei Punkte sind besonders wichtig:

  1. Entspricht der Screenshot euren Erwartungen oder fehlt etwas Wichtiges?
  2. Sind im Quelltext alle Inhalte, die indexiert werden sollen, zu finden? (Am besten kopiert ihr den Quelltext aus dem Tool und untersucht diesen in einem separaten Editor.)
  3. Schaut unbedingt in die Hinweise zu den Ressourcen und in die JavaScript-Fehlerkonsole!

Der Screenshot gibt euch einen ersten Eindruck, wie Google die Seite „sieht“. Er dient jedoch nur als Hinweisgeber, zumal er nicht scrollbar ist und wichtige Inhalte „below the fold“ versteckt sein können.

Screenshot: JavaScript Teil 4

Abb. 6: Der Screenshot der gerenderten Seite ermöglicht einen ersten Überblick (Quelle: Screenshot Mobile-Friendly Testing Tool).

Der Quelltext ist die Referenz zum Testen. Kopiert ihn und vergleicht ihn mit dem Quelltext der gerenderten Seite aus eine aktuellen Browser. Hier können erste Unterschiede auftreten, denen ihr nachgehen müsst.

Abb. 7: Das Tool zeigt auch den gerenderten Quelltext (Quelle: Screenshot Mobile-Friendly Testing Tool).

Fehlen auf dem Screenshot oder im Quelltext wichtige Inhalte, müsst ihr mit euren Entwicklern klären, auf welchem Weg diese auf die Seite gelangen und woran es liegen könnte, dass sie in Chrome41 nicht auftauchen. So könnte es zum Beispiel sein, dass die Komponente, die den fehlenden Seiteninhalt darstellen soll, eine Funktion verwendet, die von Chrome41 nicht unterstützt wird, oder dass das JavaScript bereits vor dem Laden der entsprechenden Komponente mit einem Fehler abbricht.

Prüft in der Ressourcen-Meldung, ob alle wichtigen Ressourcen geladen werden können. Dazu gehören CSS-Dateien und JS-Dateien, die für die initiale Darstellung der Seite notwendig sind.

Screenshot: JavaScript Teil 4

Abb. 8: Quelle: Screenshot Mobile-Friendly Testing Tool.

Screenshot: JavaScript Teil 4

Abb. 9: Quelle: Screenshot Mobile-Friendly Testing Tool.

Zuletzt schaut etwas weiter unten in der JavaScript-Konsole unter den Ressourcen. Fehler, die hier auftauchen, klärt ihr am besten mit eurem Entwicklungsteam ab. Nicht jede Warnung und jeder Fehler ist kritisch. Je nachdem, wie tief ihr in der Technik eures Projekts steckt, könnt ihr das auch selbst beurteilen. Das Zwei-Augen-Prinzip hat sich für mich jedoch stets bewährt.

Screenshot: JavaScript Teil 4

Abb. 10: Das Tool zeigt Ressourcen, die nicht geladen werden konnten. Nicht alle davon sind zwingend notwendig (Quelle: Screenshot Mobile-Friendly Testing Tool).

Ist eure Seite nicht von außen erreichbar, könnt ihr den Chrome41 nutzen. Stellt als Device „Nexus 5“ und als Network „3G“ ein. Dies kommt den Testkriterien von Google am nächsten. Durch die Simulation von 3G erhaltet ihr gleich ein Gefühl für die Seiten-Performance.

Screenshot: JavaScript Teil 4

Abb. 11: Die Device Emulation in den Chrome Dev-Tools (Quelle: Screenshot Chrome Dev-Tools).

Ihr seht auch: Unterhalb der Netzwerk-Einstellungen könnt ihr den UA-String verändern, mit dem sich der Browser beim Testen beim Server meldet.

Mit diesen Einstellungen ruft ihr die betreffende Seite auf und prüft zuerst, ob alles so aussieht und funktioniert, wie es soll:

  • Werden alle Inhalte dargestellt?
  • Ist die Seite komplett?
  • Funktionieren wichtige SEO-Features?

Ihr habt hier einen entscheidenden Vorteil: Ihr könnt die gesamte Seite sehen.

Prüft zuerst, ob alle Inhalte sichtbar sind, die ihr erwartet. Werft dann einen Blick in den gerenderten Quelltext (F12). Hier könnt ihr auch die Auszeichnungen mit strukturierten Daten oder die Metadaten überprüfen. Danach könnt ihr schauen, ob all diese Dinge auch im initial ausgelieferten Quelltext stimmen (STRG+U).

Hier ist es besonders wichtig, dass Auszeichnungen oder Canonicals enthalten sind.

Dann konsultiert ihr die Konsole des Browsers:

Screenshot: JavaScript Teil 4

Abb. 12: Fehler und Warnungen liefern dann wieder Anlass zur Klärung mit dem Dev-Team.

Änderungen oder Neuentwicklungen an der Website testen

Oft werden neue Features, Module und Seitenelemente für aktuelle Browser entwickelt. Daran ist nichts Falsches – solange die Abwärtskompatibilität gewährleistet ist. So stellt ihr sicher, dass eure Website mit dem Google WRS kompatibel ist:

Das Wichtigste ohne JS liefern

Generell gilt die Faustregel: Wenn ein Inhalt ranken soll, ist es am sichersten, ihn als Plain-HTML auszuliefern. Punkt. Die Diskussion, ob Google JS ausführen kann und dabei auch schon sehr erfolgreich ist, blendet einen wichtigen Faktor aus: den Aufwand, den wir Google mit JS-lastigen Inhalten aufhalsen (vgl. Teil 3 unserer Serie zum Thema Rendering).

Daher legt Wert darauf, die wichtigsten Inhalte ganz klassisch auszuliefern. Das ist vielleicht nicht das Aufregendste, aber dafür geht ihr somit auf Nummer sicher.

Der erste Test gilt daher der Seite ohne aktiviertes JavaScript: Dazu öffnet ihr die Dev-Tools mit F12 und dann die Einstellungen mit F1. Ihr deaktiviert den Browser-Cache (das simuliert den ersten Besuch auf der Seite) und JavaScript (das zeigt euch die Seite, wie sie dem Googlebot geliefert wird).

Screenshot: JavaScript Teil 4

Abb. 13: Hier deaktiviert ihr JavaScript und den lokalen Cache in Chrome41 (Quelle: Screenshot Chrome Dev-Tools).

Screenshot: JavaScript Teil 4

Abb. 14: In aktuellen Chrome-Versionen sind die Einstellungen etwas anders sortiert (Quelle: Screenshot Chrome Dev-Tools).

Jetzt wird es spannend: Sind alle SEO-relevanten Inhalte da? Ist das neue Feature sichtbar? Es ist überhaupt nicht schlimm, wenn die Seite etwas seltsam aussieht oder sich nicht haargenau so verhält wie unter echten Bedingungen. Ohne JavaScript funktionieren oft die Menüs nicht, oder statt der Grafiken werden nur kleine Lade-Symbole gezeigt.

Screenshot: JavaScript Teil 4

Abb. 15: Die Inhalte dieser Seite sind komplett von JavaScript abhängig – das kann zum Problem werden (Quelle: Screenshot Chrome Dev-Tools).

Wichtig ist aber, dass ihr die oben definierten Inhalte finden könnt. Alles, was die Suchmaschine bei der Bewertung dieser Einzelseite berücksichtigen soll, sollte jetzt vorhanden sein.

Auch ein Blick in den Quelltext darf nicht fehlen, denn ihr prüft auch die Meta-Daten.

Tipp: Macht einen Screenshot der Seite und kopiert den Quelltext für den Abgleich mit der Darstellung mit aktiviertem JavaScript.

Nach der Bestandsaufnahme ohne JS macht ihr den gleichen Test mit JS. Inspiziert die Darstellung. Schaut in den Quellcode. Und ganz wichtig: Schaut auch in die Konsole!

Screenshot: JavaScript Teil 4

Abb: 16: Beispiel eines Extremfalls: Hier kann Chrome41 das JavaScript nicht sinnvoll nutzen (Quelle: Screenshot Chrome Dev-Tools).

Wenn euch die Fehlermeldungen ratlos zurücklassen – kein Problem: Eure Entwickler können euch helfen! Steckt ihr tiefer in der Materie, könnt ihr mit einem Klick auf die Referenz neben der Fehlermeldung direkt an die Stelle im Quellcode des Skriptes springen, an der der Fehler aufgetreten ist. Analysiert dabei am besten immer von unten nach oben. Also von der letzten bis zur ersten Fehlermeldung.

Wird die Seite korrekt dargestellt, vergleicht den gerenderten Quelltext mit dem Quelltext aus dem letzten Test und prüft, ob sich SEO-relevante Inhalte verändert haben. Ist etwa ein <title> hinzugekommen oder der Canonical verschwunden, dann wird es Zeit zu handeln.

Nicht auf JavaScript angewiesene Inhalte

Zugegeben, oft geht es schon gar nicht mehr ohne JavaScript. Und das ist auch in Ordnung. Moderne Frameworks und Libraries bieten Möglichkeiten, die „konventionelle“ Entwicklung nicht hat. Ihr solltet jedoch immer auf weitestgehende Abwärtskompatibilität achten!

Sprecht mit dem Dev-Team, welche Technologien eingesetzt werden, und prüft, ob sie vom WRS unterstützt werden. Sucht Alternativen oder Anpassungen, wo es nötig ist. Es muss nicht jedes Feature oder Detail angepasst werden. Die SEO-relevanten Inhalte müssen aber immer auf optimales Rendering ausgerichtet sein.

Eine Übersicht über die Features, die Browser unterstützen, bietet CANIUSE Chrome41.

Es gibt immer eine Möglichkeit, Abwärtskompatibilität herzustellen. Setzt eure Entwicklung auf modernste ES6-Syntax, können sie mit Babel dafür sorgen, dass der Code in „ältere“ Formen übersetzt und so für ältere Browser verständlich wird. Sogenannte Polyfills sorgen dafür, Features, die moderne Browser bieten, für ältere Versionen „nachzubilden“. Alleine schon hierzu könnten wir einen gesonderten Artikel schreiben. Eure Entwickler werden sich damit aber in der Regel schon auskennen.

Sonderfall Prerenderer und Dynamic Serving

Wenn ihr euch mit Googles-Anleitungen und Empfehlungen zum Thema JS-SEO befasst, kommt ihr am Thema Dynamic Serving nicht vorbei.

Im Großen und Ganzen bedeutet Dynamic Serving, dass ihr eure Seite in einem anderen Zustand an den Googlebot ausliefert als an eure menschlichen User. Ruft ein User eure Seite auf, erhält er die JavaScript-lastige Seite mit vielen dynamischen Inhalten ausgeliefert. Ruft der Googlebot eure Seite auf, liefert der Server diesem jedoch anstelle der JavaScript-lastigen Seite eine (weitestgehend) statische Seite aus. Diese statische Seite wird von einem Prerenderer erstellt und in der Regel nach der Erstellung in einem Cache zwischengespeichert, um zu häufiges Vorrendern zu vermeiden. Hier liegt auch ein großer Knackpunkt der Lösung: die Vorhaltezeit der statischen Seiten. Weitere Informationen dazu findet ihr bei Google.

Damit das Konzept funktioniert, ist wichtig, dass der Server den Bot auch richtig erkennt. Testet die Erkennung, indem ihr den User Agent in den Dev-Tools ändert. Probiert auch mal Abwandlungen der UA-Strings aus, um zu sehen, ob die Erkennung nicht eventuell über einen abgeänderten UA-String stolpert.

Ist die Seite bereits live, könnt ihr wie oben beschrieben mit dem Mobile-Friendly Test von Google einsteigen. Zeigt das Tool die Seite und den Quelltext wie erwartet, ist das System korrekt eingerichtet. Stimmt irgendwas nicht, geht‘s mit den Browsertests weiter. Auch Entwicklungsumgebungen testet ihr wie oben beschrieben in Chrome41 mit und ohne JavaScript, einmal mit einem generischen User Agent und einmal mit dem Googlebot-User-Agent. Ihr prüft wieder auf die SEO-relevanten Elemente.

Hinzu kommt diesmal ein zusätzlicher Test: Sind zeitabhängige Inhalte auch aktuell? Durch das Caching der vorgerenderten Inhalte kann es nämlich dazu kommen, dass es zu empfindlichen Unterschieden in den Varianten kommt.

Ein Beispiel hierfür sind Aktionsbanner oder Aktionspreise.

Screenshot: JavaScript Teil 4

Abb. 17: Dieses Beispiel ist nicht unbedingt kritisch, zeigt aber zu welchen Abweichungen es kommen kann.

Bedenkt: Dynamic Serving ist ein Workaround und eine Lösung für hochdynamische und komplexe Inhalte, wie Social Media Streams oder Seiten, die mit Echtzeit-Daten arbeiten. Es ist nicht der goldene Weg für die Auslieferung einer Produktübersichtsseite, deren Inhalt sich einmal in der Woche ändern kann.

Ladezeiten und blockierende Skripte

Pagespeed ist ein Thema für sich. Oft ist jedoch JavaScript mitverantwortlich für zu lange Ladezeiten. Das Tool für Ladezeiten-Tests ist Lighthouse. Lighthouse ist mittlerweile die Basis der Pagespeed Insights, sowie als eigenständiges Tool online verfügbar. Für Tests auf Staging-Systemen ist das Tool seit längerer Zeit auch Teil der Chrome DevTools. Die Ergebnisseiten der Tools sehen leicht unterschiedlich aus, weisen aber alle die gleichen Erkenntnisse und Empfehlungen aus.

Öffnet in Chrome (diesmal bitte die aktuellste Version, da ältere Versionen nicht die aktuellsten Lighthouse-Versionen mit sich bringen) die DevTools mit F12. Unter „Audits“ findet ihr die Konfigurationsseite von Lighthouse.

Dort stellt ihr auf „Mobile Device“ (Mobile first!), wählt die Audits („Performance” ist für uns jetzt am interessantesten) und „Applied Fast 3G“ (Netzwerkgeschwindigkeit drosseln). Danach einfach auf „Run Audits“ klicken, und nach ein paar Sekunden steht der Report zur Verfügung. Während des Tests versorgt euch das Tool mit nützlichen Tipps rund um Pagespeed Mobile Friendliness.

Der Report schlüsselt diverse Erkenntnisse auf:

Screenshot: JavaScript Teil 4

Abb. 18: Der Lighthouse Report in den DevTools (Quelle: Screenshot DevTools).

Ihr bekommt:

  1. Performance Scores zu Vergleichbarkeit von Tests
  2. Detailliertere Metriken inkl. einer optisch erkennbaren Dringlichkeitseinschätzung
  3. Screenshots, die den Rendering-Prozess verdeutlichen

Etwas weiter unten seht ihr dann die Opportunities:

Screenshot: JavaScript Teil 4

Abb. 19: Lighthouse zeigt wichtige Maßnahmen, die die Performance verbessern (Quelle: Screenshot DevTools).

In den meisten Fällen steckt JavaScript hinter folgenden Punkten:

  1. Rendering-blockierende Ressourcen minimieren (JavaScript kann das Rendering blockieren)
  2. Main Thread Work reduzieren (zu umfangreiches JavaScript kostet viel Rechenpower)
  3. JavaScript-Ausführungszeit reduzieren (bei komplexen Skripten kümmert sich der Browser oftmals länger um das JS als notwendig)
  4. Kritische Request-Ketten minimieren (oft rufen einzelne Skripte wieder andere Skripte auf und laden Inhalte nach, wodurch viele Anfrage-Ketten entstehen)

Ursachen und Lösungen hierfür kennen Eure Devs. Wenn ihr die Ergebnisse teilen möchtet, bietet das Tool auch den Export der Testergebnisse an.

Lighthouse ist mittlerweile sehr beliebt, um Tests zu automatisieren und über viele Seiten hinweg Fehler einzugrenzen oder die Performance von Websites zu überwachen.

Wenn ihr wissen möchtet, ob auf allen URLs eurer Website die gleichen Probleme bestehen, könnt ihr Lighthouse auch im Autopilot betreiben. Eine Anleitung dazu gibt es beim Technical SEO Strategist Mike Osolinski, eine Ergänzung für die PowerShell habe ich mal nachgeliefert.

Twitter

By loading the tweet, you agree to Twitter’s privacy policy.
Learn more

Load tweet

Lighthouse im Autopilot ist übrigens auf einem Server besser aufgehoben als auf einem Desktop/Laptop. Daher: Zum Probieren und schnellen Nachgucken ist die Lösung gangbar. Für Monitoring eher nicht.

Natürlich kann man auch mit SEOs Lieblingstool Excel arbeiten. Die SEO-Tools for Excel haben einen Connector zu den Pagespeed Insights. Dieser zapft die Web API der Pagespeed Insights an und liefert auch ohne Node.js und Shellskript schnell Daten zum Auswerten und Weiterschicken. So wird es zum Beispiel zum Kinderspiel, einen flotten Audit seiner Sitemap zu erstellen.

Da wir gerade beim Performance-Messung sind: Beim nächsten Mal schauen wir uns an, wie wir die Performance genauer untersuchen können. Denn die Darstellung alleine ist nicht alles: Schnell sollte es natürlich auch gehen.

Fazit

Macht euch klar, welche Inhalte ihr für gutes SEO auf eurer Seite benötigt, und fertigt eine Checkliste für die Tests an. Testet immer sowohl mit einer alten als auch mit einer aktuellen Chrome-Version – immer mit und ohne JavaScript-Ausführung. Damit stellt ihr sicher, dass der Google Web Rendering Service mit eurer Seite umgehen kann. Arbeitet darauf hin, wichtige SEO-Inhalte ohne JavaScript auszuliefern und schließt euch mit euren Dev-Teams kurz, um Fehler und Auffälligkeiten in der Darstellung zu klären.

Über den Autor

Sebastian Adler

Redakteur
Den Einstieg in die Online-Marketing-Welt fand ich 2011 bei Barketing, war dann bei Searchmetrics und LEAP/ als SEO-Consultant tätig und habe dort sehr viele breit gestreute Erfahrungen sammeln dürfen. Zurzeit bin ich SEO-Manager beim Sparkassen-Finanzportal und kümmere mich dort um die Optimierung der Portale und Webseiten der Sparkassen-Finanzgruppe.