Nicht verwendetes CSS finden
Tote Regeln auf jeder Seite aufspüren

Was ein Finder für nicht verwendetes CSS macht

Stylesheets wachsen immer. Du fügst Funktionen hinzu und änderst das Design, und alter Code bleibt zurück. Daher lädt jeder Besucher Styles für Teile deiner Website, die es nicht mehr gibt.

Ein Finder für nicht verwendetes CSS beantwortet eine Frage. Welche Regeln können weg, ohne dass sich eine Seite ändert? Also liest dieser hier dein HTML, dein CSS und dein JavaScript. Dann ordnet er jede Regel in eine von vier Gruppen.

Die Gruppen sind leicht zu lesen. Zuerst Regeln, die nichts nutzt. Dann Regeln, bei denen nur einige Selektoren der Liste treffen. Danach Regeln, die bleiben, weil ein Skript sie brauchen könnte. Zuletzt Regeln, die deine Seiten gerade nutzen.

Das Ergebnis ist ein Plan, kein Glücksspiel. Jede Regel hat ihren Grund, also kannst du sie prüfen, bevor du etwas löschst. Danach lädst du das saubere Stylesheet in einem Schritt herunter.

Wie dieses Tool nicht verwendetes CSS in deinem Code liest

Die Arbeit läuft in drei Durchgängen. Zuerst macht die Seite aus deinem HTML einen Baum aus Elementen, jedes mit Klasse, ID und Attributen. Dann liest sie dein CSS und teilt jede Selektorliste in einzelne Selektoren. Zuletzt prüft sie jeden Selektor gegen jedes Element.

Dein Browser erledigt das alles. Denn diese Seite sperrt unsichere Wege, Markup zu lesen, also nutzt der Finder seinen eigenen Leser. Daher führt er deinen Code nie aus, und ein eingefügtes Skript tut nichts.

Der Abgleich folgt den echten Regeln von CSS. Zum Beispiel heißt ein Leerzeichen Nachfahre, und ein Größer-als-Zeichen heißt Kind. Außerdem zählt :nth-child Geschwister genau wie ein Browser. Also sagt der Bericht es, wenn ein Selektor dein Markup verfehlt.

Nicht verwendetes CSS über mehrere Seiten finden

Eine Seite zeigt selten das ganze Bild. Zum Beispiel wirkt eine Regel für die Kasse auf der Startseite tot, doch die Kasse braucht sie. Deshalb nimmt dieses Tool so viele Seiten, wie du ihm gibst.

Du kannst mehrere Seiten in ein Feld einfügen. Beginne jede neue Seite einfach mit einer Kommentarzeile, in der page steht. Oder lade deine HTML-Dateien hoch, dann zählt jede Datei als eine Seite.

Jede genutzte Regel zeigt auch, wo sie lebt. Zum Beispiel sagt dir genutzt auf 2 von 5 Seiten, dass ein Style zu einer Vorlage gehört. Also hilft dieser Hinweis, wenn du später ein großes Stylesheet in kleinere teilst.

Warum eine Seite nicht reicht

Die meisten Websites teilen ein Stylesheet über viele Vorlagen. Also wirkt etwa die Hälfte der Datei ungenutzt, wenn du nur eine Seite testest, und das ist falsch. Aber füge eine Produktseite, einen Blogartikel und ein Kontaktformular hinzu, dann zeigt sich das echte tote Gewicht.

Die Faustregel ist einfach. Füge eine Seite von jeder Art hinzu, die deine Website hat, denn der Finder kann nur die Seiten beurteilen, die er sieht.

Klassen, die dein JavaScript später hinzufügt

Menüs gehen auf, Tabs wechseln und Fenster erscheinen. Dabei fügt jedes Mal ein Skript eine Klasse hinzu, also steht die Klasse anfangs nicht im HTML. Daher nennt ein nachlässiges Tool diese Regeln ungenutzt, und das Löschen macht das Menü kaputt.

Dieser Finder liest auch deine Skripte. Er sammelt jeden String darin, sogar Teile von Template-Strings. Also bleibt die Regel für .menu.is-open, wenn ein Skript is-open nennt, mit einem Etikett statt einer Löschung.

Präfixe zählen auch. Zum Beispiel kann ein Skript, das btn--${state} baut, jede Klasse erzeugen, die mit btn-- beginnt. Daher bleibt jede Regel für diese Klassen, und das Etikett erklärt, warum.

Framework-Bindungen bekommen dieselbe Sorgfalt. Der Finder prüft Klassen-Attribute von Vue, Alpine und Angular, dazu Data-Attribute und Inline-Events. Kurz gesagt deckt er die üblichen Quellen versteckter Klassen ab.

Die Schutzliste für alles andere

Manche Klassen kommen von Orten, die kein Tool lesen kann. Zum Beispiel fügt ein Plugin sie auf dem Server hinzu, oder ein Redakteur tippt sie von Hand. Für diese nutze die Schutzliste.

Jede Zeile nimmt einen Klassennamen, einen Namen mit Stern oder ein Muster zwischen Schrägstrichen. Also behält wp-* jede WordPress-Klasse. Außerdem behält ein Muster wie /^is-/ alle Zustandsklassen auf einmal.

Pseudo-Klassen, Pseudo-Elemente und Zustände

Viele Tools für nicht verwendetes CSS liegen genau hier falsch. Sie suchen .card::after oder .menu summary::before, finden kein solches Element und erklären die Regel für tot. Aber ein pseudo-element gestaltet einen Teil seines Elements. Also zählt die Regel als genutzt, sobald das Element existiert.

Zustände funktionieren genauso. Wenn eine Seite lädt, hat noch niemand etwas überfahren, fokussiert oder angehakt. Doch Besucher fahren bald darüber und klicken. Daher gelten :hover, :focus und :checked hier als erreichbar.

Trotzdem zählt die Struktur. Zum Beispiel trifft li:nth-child(4) in einer Liste mit drei Einträgen nie, denn kein Klick fügt einen vierten Eintrag hinzu. Kurz gesagt behält der Finder nur, was wirklich passen könnte.

Nicht verwendetes CSS entfernen und dein Format behalten

Tote Regeln zu finden ist nur die halbe Arbeit. Die andere Hälfte ist eine saubere Datei, die du ausliefern kannst. Daher schneidet dieses Tool tote Regeln aus deinem eigenen Text. Es baut dein Stylesheet nicht neu.

Deine Kommentare, Abstände und Reihenfolge bleiben. Wenn nur ein Teil einer Selektorliste tot ist, fällt nur dieser Teil weg. Außerdem entfernt das Tool leere Media Queries.

Du wählst die Form des Ergebnisses. Lass es lesbar für dein Projekt, oder wähle Minify für eine kleinere Kopie. Dann kopiere es, oder lade es neben dem CSV-Bericht herunter.

Tote @keyframes, Schriften und Variablen

Regeln sind nicht das einzige tote Gewicht. Eine ungenutzte Animation, eine ungenutzte Schrift und eine Custom Property, die keiner liest, kosten auch Bytes. Daher listet der Finder jede davon unter einer eigenen Überschrift.

Diese Prüfung läuft, nachdem die toten Regeln weg sind. Daher markiert der Finder eine Schrift auch als ungenutzt, wenn nur eine entfernte Regel sie nutzte. Eine einfache Textsuche würde das übersehen.

Er findet auch den umgekehrten Fehler. Wenn eine Regel eine Custom Property liest, die nichts setzt, listet der Finder sie. Meistens heißt das Tippfehler oder fehlende Datei.

Eine echte Seite über ihre Adresse abrufen

Manchmal hast du nur die Webadresse. Dann tippe sie ein, und diese Seite holt die Seite, ihre Stylesheets und ihre eigenen Skripte. Danach läuft die Prüfung wie gewohnt in deinem Browser.

Der Abruf ist vorsichtig. Er folgt einer Ebene @import, überspringt Skripte von anderen Websites und stoppt bei einer sicheren Größe. Also kosten dich ein Tag Manager oder ein Chat keine Zeit.

Dieser Modus passt für einen schnellen Blick auf eine fremde Website. Für dein eigenes Projekt füge aber lieber die Quelldateien ein oder lade sie hoch. So kannst du alle Vorlagen auf einmal hinzufügen.

Was der Finder nicht wissen kann

Keine statische Prüfung sieht alles. Zum Beispiel bleibt eine Klasse aus einem Server-Wert oder Markup, das ein Skript später lädt, verborgen. Deshalb hat jede Löschung einen Grund, den du vorher lesen kannst.

Also behandle das Ergebnis wie ein Code-Review. Prüfe die Liste, setze Nötiges auf die Schutzliste und teste die saubere Datei auf einer Testkopie. Für eine zweite Meinung zeigt das Coverage panel in Chrome DevTools, was ein Besuch genutzt hat.