Oh nein! Unser Stylesheet wächst und wächst und wächst! (Das Append-Only-Stylesheet-Problem)

Das ist heutzutage eine echte Sorge. Ich höre das von vielen vielen Entwicklern. Die Jahre vergehen in ihren Projekten, und alles, was sie zu tun scheinen, ist, ihr CSS zu erweitern, niemals zu entfernen. Es ist nicht nur ein Gefühl, ich habe schon mit Unternehmen gesprochen, die harte Daten dazu sammeln. Über fünf Jahre Verfolgung der Größe ihres Stylesheets, und alles, was es je getan hat, ist, im Umfang zuzunehmen.

Dies kann aus mehreren Gründen problematisch sein

1. Dateien, die größer werden, sind schlechter für die Leistung
2. Die Entwickler haben Angst vor dem CSS

Punkt 2 ist meiner Meinung nach ein viel größeres Problem als Punkt 1. Die Gesamtgröße von CSS-Dateien ist heutzutage wahrscheinlich eher gering im Vergleich zu Bilddateien und sogar der JavaScript-Nutzlast. Ausgefallene Tools und die immer schneller werdende Internetgeschwindigkeit der Welt werden Punkt 1 wahrscheinlich zu keinem großen Problem machen.

Aber Angst vor dem eigenen Stil zu haben, ist ein größeres Problem.

„Angst“ ist normalerweise nicht die Art und Weise, wie dieses Problem diskutiert wird, aber ich denke, darum geht es. Es wird oft im Hinblick darauf diskutiert, wie die globale Natur von CSS problematisch ist oder dass das mittlere „S“ in „CSS“ das einzige ist, das gerettet werden sollte.

„Unbenutztes CSS“

Ein Teil dieser Geschichte könnte sicherlich davon handeln, CSS zu löschen, das als „unbenutzt“ in einem Projekt bestimmt wird. Ich weiß, dass es eine unglaubliche Nachfrage nach dieser Art von Tools gibt. Ich habe das Gefühl, dass einige Entwickler fast schon sabbern, um ihr CSS durch eine Art ausgefallenes Tool zu jagen, um alles Unnötige zu entfernen.

Das beunruhigt mich ein wenig. Es fühlt sich an, als würde man sagen: „Ja, ich habe Angst vor unseren Stylesheets. Ich möchte sie nicht verstehen, ich möchte nur, dass etwas sie für mich repariert.“

So hat es ein Unternehmen, von dem ich gehört habe, gemacht

1. Sie haben ein Skript auf der Seite für eine Teilmenge von Benutzern eingefügt.
2. Das Skript würde sich das CSSOM ansehen und jeden einzelnen Selektor im CSS für diese Seite finden.
3. Es würde auch eine querySelectorAll („*“) ausführen und jeden einzelnen DOM-Knoten auf dieser Seite finden.
4. Es würde diese beiden Mengen vergleichen und alle Selektoren finden, die unbenutzt zu sein scheinen.
5. Um die besten Ergebnisse zu erzielen, würde es dieses Skript nach einer zufälligen Anzahl von Sekunden, bei einer zufälligen Auswahl von Benutzern, unter zufälligen Bedingungen ausführen. Selbst damit benötigte es viele Daten über einen langen Zeitraum.
6. Nachdem dies lange genug gelaufen war, gab es eine Reihe von CSS-Selektoren, die wahrscheinlich unbenutzt waren.
7. Um sicherzugehen, wurden auf all diese Selektoren eindeutige Hintergrundbilder angewendet.
8. Nachdem diese angewendet und eine weitere Zeit gewartet wurde, wurden die Serverprotokolle überprüft, um sicherzustellen, dass diese Bilder nie aufgerufen wurden. Wenn sie aufgerufen wurden, wurde dieser Selektor verwendet und musste bleiben.
   Letztendlich konnten die unbenutzten Selektoren sicher aus dem CSS gelöscht werden.

Puh! Das ist eine Menge Arbeit, um etwas CSS zu entfernen.

Aber wie Sie sich vorstellen können, ist es ziemlich sicher. Stellen Sie sich vor, Sie überprüfen nur die CSS-Abdeckung **einer Seite**. Sie werden definitiv eine Menge unbenutztes CSS finden. Eine Seite in einem bestimmten Zustand ist kein repräsentativer Querschnitt Ihrer gesamten Website.

Websites haben mehrere Seiten. JavaScript läuft auf ihnen und beeinflusst das HTML. Benutzer können sich anmelden, wodurch Dinge in einem anderen Zustand angezeigt werden. Auf Websites passieren dynamische Dinge. Um wirklich zu wissen, welches CSS verwendet wird, müssten Sie jede mögliche Seite in jeder möglichen interaktiven Permutation testen, was eine große Aufgabe ist. Ich bin sicher, Sie können sich CSS vorstellen, das nur für ein ausgewähltes Menü für einen angemeldeten Benutzer mit abgelaufener Abonnementdatei gilt, der sich angemeldet hat, um eine Kreditkarte zu aktualisieren, was in einem modalen Fenster mit einem Formular geschieht, das auf eine bestimmte Weise angezeigt wird, weil die Karte American Express ist.

Allerdings gibt es Tools, die behaupten, beim Auffinden von unbenutztem CSS zu helfen

Chrome hat ein „Coverage“-Panel (in Canary, während ich schreibe), das Ihnen sagen kann, wie viel Ihres CSS verwendet wird.

Es ist ziemlich nett, wie Sie auf die **Aufzeichnen**-Schaltfläche klicken können, herumklicken und eine Menge Dinge tun (sogar Seiten wechseln), und es analysiert weiterhin, wie viel des CSS verwendet wird. Dann können Sie mit den roten oder grünen Balken neben dem CSS sehen, was verwendet wird oder nicht.

Es leidet unter den gleichen Problemen, die ich beschrieben habe, da bloßes Herumklicken nicht ausreicht, um die Abdeckung zu garantieren. Sie werden höchstwahrscheinlich Grenzfälle übersehen, und wenn Sie Entscheidungen zum Löschen von CSS basierend auf Ihren unvollständigen Tests treffen, werden Sie sich selbst Probleme bereiten.

Es gibt andere Tools, die sich bemühen, unbenutztes CSS zu entfernen, wobei UnCSS wahrscheinlich das beliebteste ist.

UnCSS macht einige clevere Dinge, wie z. B. die Möglichkeit, eine ganze Reihe von URLs zum Testen aufzulisten, Mediabeschränkungen anzugeben und JavaScript auszuführen. Hier ist ihre Beispielkonfiguration

var uncss = require('uncss');

var files   = ['my', 'array', 'of', 'HTML', 'files', 'or', 'http://urls.com'],
    options = {
        ignore       : ['#added_at_runtime', /test\-[0-9]+/],
        media        : ['(min-width: 700px) handheld and (orientation: landscape)'],
        csspath      : '../public/css/',
        raw          : 'h1 { color: green }',
        stylesheets  : ['lib/bootstrap/dist/css/bootstrap.css', 'src/public/css/main.css'],
        ignoreSheets : [/fonts.googleapis/],
        timeout      : 1000,
        htmlroot     : 'public',
        report       : false,
        uncssrc      : '.uncssrc'
    };

uncss(files, options, function (error, output) {
    console.log(output);
});

Ich würde mir immer noch Sorgen machen, dass dies schwierig zu konfigurieren (und zu konfigurieren zu halten) wäre, sodass es eine 100%ige Testabdeckung bietet. Jedes Mal, wenn Sie eine neue CSS-Regel schreiben, müssten Sie sicherstellen, dass sie hier keinen Fehlalarm auslöst. Das heißt, vorausgesetzt, Sie verwenden dieses Tool tatsächlich zum Löschen von CSS.

Ganz zu schweigen davon, dass es zwar JavaScript ausführt, aber keine Interaktionen simuliert.

Anderer Ansatz: Frameworks

Stellen Sie sich vor, Sie verwenden ein CSS-Framework, das jeden praktisch gewünschten Stil bereitstellt. Anstatt CSS zu schreiben, würden Sie die Klassen anwenden, die das Framework zum Erledigen Ihrer Aufgaben verwendet. Sie haben Ihre HTML-Klassen jetzt ziemlich stark an dieses Framework gebunden, aber Sie haben das Problem des wachsenden CSS gelöst. **Im Laufe der Jahre wird Ihr CSS flach bleiben.**

Ich bin kein Experte für Tachyons, aber so scheint es mir. Nachdem Sie sich an die Verwendung gewöhnt haben, werden Sie ziemlich schnell darin, das Nötige zu kodieren, mit dem Nebeneffekt dieser sich selten ändernden statischen CSS-Datei, vor der niemand Angst hat.

Dies fällt in eine Kategorie, die als Atomic CSS bekannt geworden ist, von denen es viele Akteure gibt. Eine Version von Atomic CSS ist „programmatisch“, bei der Sie spezielle Klassen und einen Verarbeitungsschritt verwenden, um das endgültige CSS für Sie zu **generieren**. Die Idee ist, dass Sie nun kein statisches Framework von CSS mehr versenden, sondern nur den sehr kleinen Teil CSS, den Sie tatsächlich benötigen.

John Polacek hat kürzlich darüber geschrieben. Er stellt fest, dass er sowohl vom Problem des wachsenden CSS betroffen war als auch feststellte, dass Atomic CSS den Trend nicht nur gestoppt, sondern umgekehrt hat.

Himmel, selbst Frameworks wie Bootstrap, Foundation, Materialize oder Bulma passen hier. Die Idee ist, dass Sie, wenn Sie sich an das Framework halten, niemals in diesen unerwünschten Zustand geraten, Angst vor Ihrem eigenen CSS zu haben.

CSS in JS

Das Verwalten von Stilen in JavaScript (empfohlene Lektüre) kann ebenfalls bei diesem Problem helfen. Stile, die vollständig auf ein bestimmtes Modul beschränkt sind, sind von Natur aus leicht zu löschen. Benötigen Sie das Modul nicht, benötigen Sie die Stile nicht.

Machen Sie sich nicht zu viele Sorgen

Ich finde all diese Dinge faszinierend zu beobachten und darüber nachzudenken. Wie so oft gesagt wird: Das Web ist ein großer Ort. Wir alle haben einzigartige Umstände. Dieses Problem betrifft einen Prozentsatz von uns, und ich wage zu sagen, wahrscheinlich einen ziemlich kleinen Prozentsatz.

Wenn Sie sich nicht besonders um die Größe Ihres CSS kümmern und keine besondere Angst davor haben, ist das großartig! Ich auch nicht, bei den meisten meiner Projekte.

Ich habe nur ein Gefühl (eigentlich eine Vorhersage), dass es eine modulare Zukunft für CSS gibt.

Wenn wir Stile schreiben, werden wir immer eine Wahl treffen. Sind das globale Stile? Lecke ich absichtlich diesen Stil über die gesamte Website? Oder schreibe ich CSS, das spezifisch für diese Komponente ist? CSS wird zwischen diesen beiden geteilt. Komponentenspezifische Stile werden gekapselt und mit der Komponente gebündelt und bei Bedarf verwendet.

Was die vorherrschende Tooling dafür sein wird, bin ich mir nicht sicher, falls es überhaupt eine gibt.