CSS Kompressor?

Quote from MEGAbiker1971

Das es komplex ist dachte ich mir, mein Problem ist, das ich 1400 Zeilen CSS habe, da dachte ich das es da vllt. was gibt das dass Reduziert.

Wie soll ein Amateur nach solchen Tools noch erkennen können, wo neue Probleme im CSS entstanden sind, weil das Tool "falsch gehandelt" hat? Man kann doch überhaupt nicht alles auf der Website überblicken, um dann selbst die Fehler zu finden - jedenfalls nicht, wenn das Tool tatsächlich entscheidend viel Overhead reduzieren könnte. Wenn das Tool fast nichts findet/verändert, dann hat es auch nichts relevantes gespart.

Davon auszugehen, dass ein Tool ja Fehler machen könnte, ist grundsätzlich eine schlechte Annahme. Wenn man so argumentiert, dürfte man gar nichts von einem Dritten einsetzen. Ich weiß auch nicht, von was für einem Overhead die Rede ist. Klar, wenn man das komprimierte CSS bei jedem Seitenaufruf neu generiert, ist das nicht optimal. Aber wenn die Kompromierung als Teil des Build-Prozesses geschieht, gibt es auch keinen Overhead.

Ich stimme jedenfalls nicht zu, dass die Komprimierung von CSS eine "Micro-Optimierung" sei, die "reiner Selbstzweck ohne Mehrwert" wäre, zumindest nicht, wenn wir von etwas größeren Projekten sprechen und nicht nur ein paar hundert Zeilen CSS.

In meinen Website-Projekten ist das seit Jahren Teil des Build-Prozesses, der im Deployment auch keinen Mehraufand verursacht, weil das im selben Ablauf passiert, der sowieso für die Zusammenlegung aller Assets und die LESS-CSS-Konvertierung stattfinden muss. Das Deployment dauert dann halt dadurch vielleicht eine Sekunde länger. Und Probleme gab es durch die Kompromierung in all den Jahren noch nie.

Tatsache ist, dass Performance ein Riesen-Thema ist und nicht zuletzt durch Google zum immer größeren Thema wird. Eine 196 KB große CSS-Datei auf "nur" noch "164 KB zu bekommen, um reale Zahlen aus einem meiner Projekte zu nennen, macht vielleicht nicht die Welt aus, ist aber auch nicht nichts, vor allem, wenn man das ohne Mehraufwand erreichen kann. Die notwendigen Strukturen muss man ja nur einmal einrichten und kann sie dann für jeden Kunden wieder nutzen.

Und wenn man's nicht für die Performance macht, dann wenigstens für die Umwelt, Stichwort geringere CO2-Emissionen durch geringere Dateigrößen:

CO2 emissions on the web

I’ve spent the last month trying to reduce the carbon footprint of the websites I have (some) control over. When talking about this with other people they…

dannyvankooten.com

Saving the planet, 1024 bytes at a time

Reducing the size of Javascript files can reduce your CO2 emissions

blog.addressfinder.io

Wenn man das mal hochrechnen würde, was man global erreichen könnte, wenn jeder nur ein bisschen einsparen würde, würde in Summe auch eine riesengroße Zahl bei rauskommen… Auch scheinbar kleine Dinge können großen Einfluss haben!

Das ist vor allem ein Weg, wie man Verbesserung realistisch erreichen kann. Denn klar ist auch: Verzicht auf Bilder, Verzicht auf besondere Schriften, solche Dinge würden auch viele Bytes einsparen. Aber der Kunde will "schöne" Websites und da der Kunde bezahlt, bekommt er das, was er will. CSS-Komprimierung auf der anderen Seite tut niemandem weh und ein bisschen Verbesserung ist immer noch sehr viel besser als gar nichts.

Quote from Cadeyrn

von was für einem Overhead die Rede ist

Damit meinte ich den Teil des CSS, den man mit Optimierung einsparen könnte - also nichts, was Dir widersprechen würde.

Ich denke man müsste hier im Thema differenzieren, in ein Profi die Optimierung macht bzw sich mit dem Ergebnis auseinander setzt oder ein Amateur. Und niemand stellt in Frage, dass Optimierung prinzipiell gut ist. Die Frage ist aber, ob es sich für "unsere" zusätzlichen Codezeilen lohnt.

Ich gebe Cadeyrn recht, eine komprimierung (minify) von CSS kann sehr viel Sinn ergeben.

Durch mein gestern erstmals richtig mit Tailwind arbeiten, bin ich ja auf den Purge Modus davon aufmerksam geworden und muss sagen, das macht wenn man es mal kapiert hat (ich war müde...) richtig Spaß sogar.

Man kann auch andere CSS-Frameworks wie zB Bootstrap damit verkleinern, dort nennt sich das PurgeCSS als Beispiel und wird einfach beim Deployment via Webpack über die Seite gejagt und alles entfernt, was aktuell nicht dort verwendet wird.

Das hat bei einem meiner Projekte die nicht minified Version von 168kB auf 66kB gesenkt, minified brachte es dann auf 48kB sogar herunter.

Gerade bei Google's PageSpeed Insight (Lighthouse) bekommt man so direkt ein paar Punkte mehr.

Ich denke aber das zB Alexander hier von der Sicht Woltlabs geredet/argumentiert hat. In dem Falle wäre ein Einsatz von Tools wie PurgeCSS mehr kontraproduktiv wenn man an die Möglichkeit der Pakete denkt. Klar, man könnte die Installation von Paketen anpassen, das Entwickler eben ihre Templates dabei mitteilen, man im Background Webpack alles neu erstellen lässt und somit effizient die Dateien verkleinert. Das könnte aber auch zu mehr Fehlern führen.

Dafür kann man auch das Page-Speed-Modul von Google verwenden. Das kann das in Teilen auch.