Code Coverage testet jeden Selektor in jedem lesbaren Stylesheet mit der Live-Seite, sodass Sie sehen können, welche CSS-Regeln derzeit mit nichts übereinstimmen, wie viele Bytes jede Datei verschwendet und welche Skripte den ersten Malvorgang verzögern.
Stylesheets wachsen nur. Ein Theme kommt mit Regeln für Seiten, die Sie nicht haben, ein Framework liefert Komponenten, die Sie nie verwenden, und drei Redesigns später ist sich niemand mehr sicher, welche Hälfte der Datei lasttragend ist. Das Ergebnis ist CSS, das jeden Besucher Bandbreite und Renderzeit kostet, um Regeln bereitzustellen, die die Seite nicht verwenden kann.
Code Coverage misst dies direkt. Es durchläuft jede Regel in jedem Stylesheet, das der Browser lesen lässt – einschließlich Regeln, die in Medienabfragen, @supports- und @layer-Blöcken verschachtelt sind – und testet jeden Selektor anhand des Live-DOM. Eine Regel, die derzeit nichts zutrifft, wird pro Datei als nicht verwendet gemeldet, mit einem Prozentsatz, den verschwendeten Bytes und der vollständigen Liste der Selektoren, die Sie erweitern und kopieren können.
Es ist vorsichtig mit den offensichtlichen Fallen. Pseudoelemente und Zustandspseudoklassen werden vor dem Abgleich entfernt, sodass eine :hover- oder ::before-Regel danach beurteilt wird, ob ihr Basisselektor vorhanden ist, und nicht fälschlicherweise abgeschrieben wird. Stylesheets, die ursprungsübergreifend ohne CORS-Header bereitgestellt werden, können von keinem Skript gelesen werden, daher werden sie als unlesbar gekennzeichnet, anstatt stillschweigend als perfekt gezählt zu werden. Und da der Scan die Seite in ihrem aktuellen Zustand widerspiegelt, sehen Regeln für Menüs, Registerkarten und Modalitäten, die noch nicht geöffnet sind, ungenutzt aus – öffnen Sie sie also und klicken Sie auf „Erneut scannen“, bevor Sie etwas löschen.
Die Registerkarte „JavaScript“ beantwortet eine andere Frage: Gewicht und Blockierung. Es inventarisiert jedes Skript, das die Seite lädt, mit seiner Übertragungsgröße, seiner Downloadzeit und ob es asynchron, verzögert, ein Modul, dynamisch geladen ist oder den ersten Malvorgang verzögert, und summiert dann, wie viele Bytes blockiert werden. Es wird bewusst nicht als Ausführungsabdeckung verkauft – um zu wissen, welche JavaScript-Zeilen ausgeführt wurden, ist die Debugger-API von Chrome erforderlich, die DevSuite Pro nicht anfordert, sodass hier nichts vorgibt, ein Bericht auf Zeilenebene zu sein.
Jede Regel in jedem lesbaren Stylesheet wird anhand des Live-DOM getestet, einschließlich Regeln in Medienabfragen, @supports und @layer-Blöcken – nicht anhand von Dateinamen oder -größen geschätzt.
Jedes Stylesheet erhält einen ungenutzten Prozentsatz, eine verwendete versus nicht genutzte Regelanzahl und die Anzahl der verschwendeten Bytes, sortiert so, dass der schlimmste Übeltäter ganz oben steht.
Erweitern Sie eine beliebige Datei, um die Selektoren zu lesen, die mit nichts übereinstimmen, und kopieren Sie sie dann als CSS-Block, um sie in Ihrem Editor durchzuarbeiten oder an einen Teamkollegen weiterzugeben.
Pseudoelemente und Zustandspseudoklassen wie :hover und :focus-within werden vor dem Abgleich entfernt, sodass interaktive Regeln fair beurteilt und nicht abgeschrieben werden.
Jedes Skript wird mit seiner Größe, Downloadzeit und der Angabe, ob es asynchron, verzögert, ein Modul, dynamisch geladen oder blockierend ist, aufgelistet – plus den gesamten blockierenden Bytes.
Nicht lesbare Cross-Origin-Stylesheets werden gekennzeichnet und nicht bewertet, und auf der Registerkarte „JS“ wird deutlich angezeigt, dass sie die Gewichtung misst und nicht, welche Zeilen ausgeführt werden. Keine erfundenen Zahlen.
Ein gekauftes Theme enthält CSS für Dutzende Demo-Layouts. Sehen Sie, wie viel davon Ihre Website nie nutzt, und kürzen Sie die Datei anhand von Beweisen statt durch Vermutungen.
Überprüfen Sie, wie viel von einem CSS-Framework auf einer echten Vorlage erhalten bleibt und ob Ihre Bereinigungs- oder Tree-Shaking-Konfiguration das tut, was Sie denken.
Listen Sie die Skripte mit ihrer Größe auf, die das Rendern verzögern, und entscheiden Sie, was verschoben, geteilt oder gelöscht werden soll, damit Inhalte früher auf dem Bildschirm angezeigt werden.
Kommen Sie mit Zahlen herein: Welche Dateien verschwenden die meisten Bytes, wie viel JavaScript blockiert und wo sich die erste Arbeitsstunde am meisten auszahlt.
Wenn Sie eine Website übernehmen, die Sie nicht erstellt haben, erfahren Sie schnell, wie viel CSS und JavaScript noch ihren Platz verdient.
Klicken Sie im DevSuite Pro-Dock auf das Code Coverage-Symbol. Der Scan wird sofort ausgeführt und meldet, wie viele Regeln überprüft wurden und welcher Anteil davon ungenutzt ist.
In der oberen Zeile sehen Sie die Anzahl der Stylesheets, die Gesamtzahl der Regeln, den ungenutzten Prozentsatz und die verschwendeten Bytes. Die unten aufgeführten Dateien sind nach ihrer Verschwendung geordnet.
Klicken Sie auf Nicht verwendete Selektoren für eine beliebige Datei anzeigen, um genau zu lesen, welche Regeln auf dieser Seite mit nichts übereinstimmen.
Öffnen Sie Menüs, Registerkarten, Akkordeons und Modalitäten und drücken Sie dann auf „Erneut scannen“. Regeln, deren Elemente nur in diesen Zuständen vorhanden sind, werden von „Unbenutzt“ in „Genutzt“ verschoben – tun Sie dies immer, bevor Sie sie löschen.
Durch das Kopieren nicht verwendeter Selektoren erhalten Sie einen CSS-Block zum Durcharbeiten. JSON exportieren kopiert den vollständigen Bericht, einschließlich des JavaScript-Inventars, für ein Ticket oder ein Prüfdokument.
Installieren Sie DevSuite Pro kostenlos und schalten Sie 71+ Entwickler-Tools für Ihren Browser frei.
