Automatisierte Website-Tests: Nützliches Signal oder falsche Sicherheit?
Tools wie Google Lighthouse können eine Website in Sekunden prüfen und einen mit einem Score bewerten. Das ist nützlich – kann aber auch irreführend sein. Ein hoher Wert weist nicht unbedingt eine gute Website hin. Hier geht es darum, was diese Tools können und was nicht – und wie man echten Nutzen daraus zieht.
Was automatisierte Test-Tools eigentlich tun
Tools wie Google Lighthouse, WebPageTest, WAVE oder die Audits auf webaudits.org führen automatisierte Tests einer URL durch. Sie testen zum Beispiel:
- Wie schnell die Seite lädt (oder zu laden scheint)
- Ob Bilder einen Alt-Text haben
- Ob die Seite HTTPS verwendet
- Ob bestimmte Standards zur Barrierefreiheit eingehalten werden
- Wie viele Daten die Seite überträgt
- Grundlegende SEO-Signale wie Meta-Tags und Überschriftenstruktur
Das Ergebnis ist meistens ein Score – oft zwischen 0 und 100 – aufgeteilt nach Kategorie. Das wirkt verlässlich. Das Problem: Es kann irreführend sein.
Der Score ist ein Annahme
Es gibt ein Prinzip, das manchmal als Goodhart'sches Gesetz bezeichnet wird: Wenn ein Messwert zum Ziel wird, hört er auf, ein gutes Mass zu sein. Anders gesagt: Für einen Score zu optimieren ist nicht dasselbe wie das zu verbessern, was der Score eigentlich messen soll.
Bei Website-Audits passiert das ständig.
Ein Entwickler kann auf einer Seite einen nahezu perfekten Lighthouse-Performance-Score erzielen, die sich für echte Nutzer trotzdem langsam anfühlt. Tools messen unter kontrollierten Laborbedingungen, nicht in realen Netzwerkumgebungen. Beispielsweise kann eine Seite bei Barrierefreiheit 100 Punkte erreichen und trotzdem für jemanden, der einen Screenreader benutzt, kaum nutzbar sein. Um gewisse Barrierefreiheitsprobleme zu erkennen, braucht es nach wie vor menschliches Urteil. Untersuchungen von Deque zufolge erkennen automatisierte Tools nur etwa 57 % der Barrierefreiheitsprobleme – der Rest erfordert manuelle Prüfung.
Ein hoher Score ist ein gutes Zeichen. Er ist keine Garantie.
Was diese Tools grundsätzlich nicht prüfen können
Automatisierte Tools funktionieren durch das Ausführen von Programmen. Sie können prüfen, was vorhanden und was messbar ist. Sie können nicht beurteilen, was für Nutzer tatsächlich wichtig ist.
Hier sind konkrete Dinge, die sie übersehen:
Usability. Ein Button kann gross genug sein, ausreichend Kontrast haben und trotzdem verwirrend sein. Tools wissen nicht, ob Nutzer die Oberfläche verstehen.
Inhaltsqualität. Ob ein Text nützlich, ehrlich oder verständlich ist, liegt ausserhalb jeder automatisierten Prüfung.
Reale Performance. Labortests laufen unter festen Bedingungen. Echte Nutzer haben unterschiedliche Geräte, Verbindungen, Standorte und Browser-Zustände. Ein Tool kann eine schnelle Seite anzeigen, die für die meisten tatsächlichen Besucher langsam lädt.
Tiefgehende Barrierefreiheit. Ein Formularfeld kann ein Label haben (was das Tool prüft) und trotzdem so beschrieben sein, dass es für Screenreader-Nutzer keinen Sinn ergibt.
Nachhaltigkeit im vollständigen Kontext. Tools können den CO2-Fussabdruck eines Seitenaufrufs schätzen, aber nicht berücksichtigen, wie oft die Seite aufgerufen wird, ob sie etwas Energieintensiveres ersetzt oder was auf der Serverseite passiert.
Wofür sie wirklich gut sind
Das gesagt: Automatisierte Tools sind wertvoll – besonders wenn man sie mit den richtigen Erwartungen einsetzt.
Schnelles Feedback. Ein kurzer Scan kann offensichtliche Probleme in Sekunden aufdecken. Das ist nützlich, egal ob man die eigene Seite prüft oder die Arbeit eines Dienstleisters bewertet.
Konsistenz. Tools wenden dieselben Regeln jedes Mal an. Das ist bei manueller Prüfung schwerer zu erreichen.
Regressionen erkennen. Läuft man denselben Test regelmässig, fällt auf, wenn sich nach einem Deployment etwas verschlechtert hat.
Gesprächsgrundlage. Für Kunden, die nicht technisch sind, kann ein Tool-Bericht mit konkreten Zahlen eine Diskussion über Prioritäten und Kompromisse leichter anstoßen als abstrakte Beschreibungen.
Leicht erreichbare Verbesserungen. Fehlende Alt-Texte. Nicht komprimierte Bilder. Seiten ohne Meta-Description. Kein HTTPS. Render-blockierende Skripte. Das sind echte Probleme – und Tools finden sie schnell.
Aus Kundensicht
Wer jemanden dafür bezahlt, eine Website zu coden oder zu pflegen, kann Audit-Ergebnisse als nützliche Referenz nutzen. Das Audit sollte aber als Ausgangspunkt einer Beurteilung betrachtet werden, nicht als alleinstehendes Kriterium.
Ein paar wissenswerte Dinge:
- Ein Score kann künstlich erhöht werden, indem man sich nur auf das konzentriert, was das Tool misst. Entscheidend ist, was tatsächlich verbessert wurde – nicht nur, was der Score ist.
- Verschiedene Tools liefern verschiedene Ergebnisse. Ein Score von 90 bei Lighthouse und 60 bei einem anderen Tool für dieselbe Seite ist kein Widerspruch, denn sie können unterschiedliche Dinge messen.
- Scores können ein Hinweis auf die geleistete Arbeit sein. Hat sich die Performance nach der bezahlten Arbeit verbessert?
Wenn jemand eine perfekte 100 verspricht, sollte man neugierig werden, wie das erreicht wird. Manche Optimierungen, die Scores verbessern, haben keinen echten Nutzen – oder tauschen ein Problem gegen ein anderes aus.
Aus Entwicklersicht
Tools sind schnell, günstig und automatisierbar. Sie sollten als Teil eines regelmässigen Workflows eingesetzt werden, nicht nur vor einem Launch. So können Bottlenecks frühzeitig erkannt und behoben werden.
Ein paar praktische Gewohnheiten:
- Tests in einer konsistenten Umgebung ausführen. Lighthouse-Ergebnisse variieren je nach Ort und Art der Ausführung. Dieselbe Einrichtung jedes Mal verwenden (zum Beispiel Lighthouse CI in der Deployment-Pipeline), damit Ergebnisse vergleichbar bleiben.
- Probleme nicht isoliert beheben. Verstehen, was ein gemeldetes Problem wirklich bedeutet, bevor man handelt. Manche Empfehlungen widersprechen sich oder haben kaum reale Auswirkungen.
- Mehrere Tools verwenden. Verschiedene Tools erkennen verschiedene Dinge. Eine Kombination aus Lighthouse, WAVE und einer manuellen Prüfung kommt der Wahrheit viel näher als ein einzelnes Tool.
- Nach Möglichkeit mit echten Nutzern testen. Selbst eine kleine Runde Usability-Tests deckt Dinge auf, die kein automatisiertes Tool findet.
Mit begrenztem Budget arbeiten
Nicht jede Website hat die Ressourcen für ein vollständiges Audit. Das ist in Ordnung. Die Frage ist, wie man priorisiert.
Ein nützlicher Rahmen: Welche Probleme verursachen echten Schaden – und welche sind leicht zu beheben?
| Priorität | Problemtyp | Beispiel |
|---|---|---|
| Zuerst beheben | Grosse Wirkung, geringer Aufwand | Fehlende Alt-Texte, kein HTTPS, kaputte Links |
| Einplanen | Grosse Wirkung, höherer Aufwand | Schlechter Farbkontrast durchgehend, langsamer Server |
| Nachrangig behandeln | Geringe Wirkung, hoher Aufwand | Kleinere Score-Verbesserungen ohne Nutzereffekt |
| Vorerst überspringen | Geringe Wirkung, geringer Aufwand | Anpassungen, die den Score bewegen, aber nichts anderes |
Mit dem beginnen, was für echte Nutzer am meisten zählt. Bei Barrierefreiheit bedeutet das oft, sicherzustellen, dass Kernfunktionen (Navigation, Formulare, wichtige Inhalte) ohne Maus und mit einem Screenreader funktionieren – bevor man sich um Randfälle kümmert. Bei Performance ist die Behebung eines 4-MB-Bildes nützlicher als das Feintuning von Cache-Headern.
Wenn das Budget knapp ist, kann ein strukturiertes Audit helfen, festzustellen, was zuerst angegangen werden sollte. Tools wie die auf webaudits.org geben einen Überblick über mehrere Kategorien – Nachhaltigkeit, Performance, Sicherheit, SEO und Barrierefreiheit – sodass man die grössten Lücken erkennen kann, bevor man entscheidet, wo man Aufwand investiert.
Was man mit Audit-Ergebnissen tun sollte
Ein Audit-Bericht ist nur nützlich, wenn jemand darauf reagiert. Ein einfacher Ansatz:
- Triage. Die Ergebnisse durchgehen und sortieren: kritisch, wichtig und gering.
- Verstehen, bevor man behebt. Für jeden Befund sicherstellen, dass man versteht, was er in der Praxis bedeutet. Manche Punkte sind echte Probleme. Manche sind falsch-positive Ergebnisse. Manche sind echte Abwägungen.
- Aufwand einschätzen. Ein kleines Team mit begrenzter Zeit muss wissen, welche Korrekturen schnell umsetzbar sind und welche Projekte darstellen.
- Beheben und überprüfen. Nach Änderungen das Audit erneut ausführen. Sicherstellen, dass das Problem tatsächlich behoben ist – nicht nur, dass der Score gestiegen ist.
- Zur Gewohnheit machen. Ein einmaliges Audit ist eine Momentaufnahme. Regelmässige Tests erkennen neue Probleme, bevor sie ernst werden.
Ein nützliches Tool – keine Antwort
Automatisierte Tests haben ihre Berechtigung. Sie sind schneller und günstiger als manuelle Prüfung. Sie sind gut darin, eine bestimmte Klasse von Problemen konsistent zu erkennen. Aber sie messen, was messbar ist – nicht, was am meisten zählt.
Sie als Ausgangspunkt einer qualifizierten Beurteilung verstanden werden. Mit manuellen Tests, echtem Nutzerfeedback und gesundem Menschenverstand kombinieren. Scores mit gesunder Skepsis begegnen – auch hohen.
Das Ziel ist nicht eine bessere Zahl. Es ist eine bessere Website.
Häufige Fragen zu automatisierten Website-Tests
Automatisierte Test-Tools werfen viele praktische Fragen auf – besonders für alle, die neu im Thema Website-Audits sind. Hier sind Antworten auf die häufigsten.