Keine Website wird auf einen Schlag langsam. Sie wird es in Schritten von 20 KB. Ein zusätzliches Skript für die Terminbuchung, ein weiterer Schriftschnitt für die neue Kampagne, ein Video auf der Startseite, ein Plugin für die Bewertungssterne. Jede einzelne Entscheidung ist begründbar, keine ist auffällig, und nach zwei Jahren wiegt dieselbe Seite das Dreifache. Das ist der Grund, warum Guideline 2.15 nicht von einmaligen Audits spricht, sondern von Intervallen. Sie nennt sogar konkrete: monatlich oder quartalsweise. So etwas findet man in Standards selten.
Die drei Erfolgskriterien von Guideline 2.15
Laufende Bewertung: Bewerte die aktuelle Nutzererfahrung, prüfe die Codebasis auf Fehler, identifiziere Performance-Probleme und berücksichtige Fragen der Barrierefreiheit, der Nachhaltigkeit und der Sicherheit in angemessenen regelmäßigen Abständen, etwa monatlich oder quartalsweise.
Automatisierte Tests: Pflege eine automatisierte Testsuite, die die kritischen Funktionen abdeckt, und führe sie bei Builds und Releases konsequent aus, um Regressionen früh zu erkennen.
Performance-Tests: Erkenne und behebe Engpässe oder Probleme im zugrundeliegenden Code oder in der Infrastruktur, die Nachhaltigkeit und Performance beeinträchtigen könnten, damit der Nutzerweg reibungslos bleibt. Beziehe sowohl simulierte als auch reale Messwerte ein. Überwache die Performance über jeden Release-Zyklus hinweg mit geeigneten Werkzeugen oder durch Recherche und Audits.
Meine Einordnung
Das erste Kriterium ist bemerkenswert breit: Nutzererfahrung, Fehler, Performance, Barrierefreiheit, Nachhaltigkeit und Sicherheit stehen in einem einzigen Satz. Das ist kein Redaktionsversehen, sondern eine Aussage. Diese Themen werden in Organisationen üblicherweise von unterschiedlichen Leuten zu unterschiedlichen Zeiten betrachtet, und genau deshalb fällt durch, was zwischen ihnen liegt. Ein Cookie-Banner ist ein Rechtsthema, ein Performanceproblem und ein Bedienhindernis zugleich.
Ich prüfe deshalb regelmäßig mit PageSpeed Insights, dazu Barrierefreiheit und Datenschutz. Und ich installiere Hugo-Updates konsequent, weil ein nicht aktualisiertes System die einzige Sicherheitslücke ist, die mit der Zeit von allein größer wird.
Beim dritten Kriterium steckt ein Detail, das viele übersehen: simulierte und reale Messwerte. PageSpeed Insights liefert beides in einem Bericht. Oben stehen die Felddaten aus dem Chrome User Experience Report, also Messungen echter Besucher mit echten Geräten. Darunter die Labordaten aus einem simulierten Durchlauf. Beide gehören zusammen. Die Labordaten sagen Dir, was Du geändert hast. Die Felddaten sagen Dir, ob es bei jemandem angekommen ist. Wer nur den Labor-Score anschaut, optimiert für eine Maschine, die es nicht gibt.
Und das zweite Kriterium ist für statische Seiten anders zu lesen als für Anwendungen. Eine Testsuite bedeutet hier keine Unit-Tests, sondern Prüfungen beim Build: Bricht der Build? Sind alle internen Links gültig? Ist das HTML valide? Hat sich das Seitengewicht gegenüber dem letzten Release verändert? Das lässt sich in wenigen Zeilen automatisieren und verhindert genau die schleichende Verschlechterung aus dem Einstieg.
Wo ich weiter gehe
An zwei Stellen reicht mir die Guideline nicht.
Erstens fehlt in der aktuellen W3C-Fassung ein Kriterium, das ältere Interpretationen noch führen: die datenschutzkonforme Messung. Dort stand die Anforderung, nur die Daten zu erheben, die tatsächlich gebraucht werden, und dabei Barrierefreiheits- und Datenschutzrecht einzuhalten. Diese Streichung halte ich für einen Fehler. Ein Audit ist selbst eine Datenerhebung. Wer mit externen Werkzeugen prüft, übermittelt seine URLs und manchmal mehr an einen Dritten. Und wer Verhalten misst, um Probleme zu finden, sammelt Bewegungsprofile. Ich prüfe deshalb bei jedem Audit mit: Welches Werkzeug bekommt hier welche Daten, und brauche ich das?
Zweitens die Nachhaltigkeitsmessung selbst. Die Guideline nennt Nachhaltigkeitsprobleme, gibt aber keine Kennzahl vor.
Meine Prüfliste hat deshalb eine Zeile mehr als die Standardwerkzeuge: Kilobyte pro Seitenaufruf, gemessen bei leerem Cache. Diese Zahl ist unbestechlich. Sie steigt nicht, weil ein Algorithmus sich geändert hat, sondern nur, weil jemand etwas hinzugefügt hat.
Dein erster Schritt heute
Du brauchst kein Monitoring-System. Du brauchst einen wiederkehrenden Termin und fünf Zeilen.
Wenn Du einen Build-Prozess hast, ergänze eine automatische Linkprüfung. Kaputte interne Links sind der häufigste Fehler auf gewachsenen Seiten und der billigste zu finden.
Was nicht regelmäßig gemessen wird, wird zuverlässig schlechter.
Quelle: W3C-Fassung von Guideline 2.15