Optimierung CSS und JS

[shadowcat]

Manchmal hab ich so ein "und täglich grüßt das Murmeltier"-Gefühl. Da war es früher gaaaaaaanz wichtig, Grafiken möglichst klein zu halten, weil die Ladezeiten sonst so unterirdisch waren. Dann kamen die Breitband-Netze und die Webseiten wurden lustig bunt und kein Mensch redete mehr über Ladezeiten. Und jetzt ist CSS- und JS-Komprimierung gerade DAS Geheimrezept für schnellere Webseiten, sozusagen der Heilige Gral. Irgendwie glaub ich das nicht so richtig. Aber sei's drum, es gibt offenbar Bedarf.

Nun haben wir ja dank get_page_headers() schon mal einen wunderbaren Ansatz, den ganzen Schrumms komprimiert abzuliefern, da wir da ja ohnehin das ganze CSS und JS Gelumpe einsammeln. Ich wage zwar nicht, mir die Folgen eines automatischen Komibinierens und Komprimierens vorzustellen - das war schon bei LibraryAdmin immer so ein wunder Punkt -, aber "wenn's schee macht...".

Ich hätte da gern mal ein paar Meinungen gehört. Hat jemand echte, eigene Erfahrungen, wie hilfreich und wichtig das _wirklich_ ist? Ist das jetzt nur so ein Heilsbringer-Trend - so nach dem Motto, "SEO hatten wir schon, jetzt reden wir mal über ... äh ... okay, gibt nix, also nehmen wir einfach mal CSS und JS?"

Zu bedenken ist natürlich auch, daß so ein serverseitiges Komprimieren durchaus auch Zeit kostet. Ob das wirklich aufgewogen wird durch den Gewinn auf der Ladezeit-Seite, weiß ich nicht, das muß man dann messen. Doof halt, daß man es zum Messen auch erst mal umsetzen muß.

[Morpheus]

Wenn "unser eins" Bilder einstellt wird man sich sicher Gedanken über das Thema machen,
aber wenn ich aber den normalen "Editor" betrachte, wird sie/er keine Gedanken darüber macht.

Ist nicht das Thema im KitFrameWork
https://github.com/phpManufaktur/kfImageTweak

Hab ich nocht nicht ausprobiert !

[shadowcat]

Ja, aber es geht gerade nicht um Bilder, sondern JS und CSS.

[MK70]

Ich kann Dir da nicht viel zu sagen.

Wie Du sagst, müsste das wer messen, dann kann man was sagen. Ich als Endnutzer eines Produktes werde das sicher nicht augenscheinlich merken...

[Morpheus]

ups

[shadowcat]

Ich habe das jetzt mal ein wenig analysiert und verschiedene Tools ausprobiert. Folgendes ist mir negativ aufgefallen:

1. Wenn man CSS für verschiedene Medien hat (screen,print etc.), müßte man die getrennt abfackeln. Es ist kaum möglich, das aktuelle Anzeigemedium auf der Serverseite zu ermitteln; dazu bräuchte man JavaScript und hätte damit ein klassisches Henne-Ei-Problem.

2. jQuery und "restliches JS" lassen sich zwar komprimieren, es sind dann aber immer noch zwei Dateien.

3. Das Erzeugen der komprimierten Dateien ist zeitaufwendig. Im Backend gibt es beim ersten Mal eine deutlich spürbare Verzögerung, wenn die Dateien mal da sind (Cache) geht es dafür aber nicht spürbar schneller, jedenfalls nicht auf einem lokalen XAMPP.

4. Es ist durchaus möglich, daß durch das Komprimieren Darstellungs- oder Funktionsfehler auftreten.

Ich persönlich bin daher zu der Ansicht gelangt, daß der Aufwand das Ergebnis nicht rechtfertigt. Eher sollte man das Backend-Theme sowie die Templates für den Produktiveinsatz optimieren. Wir hatten das für Freshcat schon mal vor, das Problem ist nur, daß das Komprimieren die Pflege erheblich schwieriger macht. Man müßte daher für die Entwicklung mit getrennten Dateien arbeiten und diese für den Release komprimieren. Das wiederum führt zu deutlichem Mehraufwand für das Erstellen eines Release, außerdem müßte man bei GitHub vor dem Release die Dateien austauschen und hinterher wieder die unkomprimierten hochladen...

Es mag andere Wege geben, etwa auf GitHub von vornherein nur die komprimierten Dateien zu haben und die unkomprimierten nur lokal, das ist aber auch wieder Mehraufwand, und man muß höllisch aufpassen, daß man nicht das Falsche hochlädt.

Kurzum: Wer wirklich ein Performanceproblem hat, kann es mal versuchen, über den Online YUI Compressor JavaScripts und CSS zu komprimieren und dann zu schauen, ob das wirklich was bringt. Eine vollautomatische "on-the-fly"-Kompression von Seiten des Core würde ich derzeit aber ausschließen.

[nicoletta]

Ich hab ja noch nicht so den Durchblick, aber ich denke die CSS, JS. jQuerry Dateien nach möglichkeit zusammenzufassen sollte möglich sein. Ich sehe zu das nach Möglichkeit das Including in einer Datei, wie beispielsweise die frontend.css, stattfindet.
Auch wenn diese nicht kompromiert werden meine ich hat das schon erhebliche Vorteile in Performance und SEO.

[shadowcat]

Hier ein Update: Ich arbeite an einer Lösung für BC v1.2. Wir werden zunächst mal optional als Bibliothek das Projekt "Munee" anbieten. Ich arbeite noch an einer Erweiterung von Munee, da dieses derzeit keine @import Anweisungen auflöst; hierzu gibt es einen Issue im Munee-Repository bei GitHub. Munee wird offiziell nicht mehr weiter entwickelt, der Autor leistet aber noch Support und ist sehr aufgeschlossen.

Es gibt noch weitere Projekte, die dieses Thema fokussieren, aber bisher erschien mir Munee am geeignetsten. Eventuell integrieren wir später noch weitere Bibliotheken, aber wenn das mit Munee gut klappt, ist das vermutlich erst mal nicht nötig. Es sei denn, Munee funktioniert irgendwann nicht mehr, oder es gibt was Neues a la Bootstrap, was unbedingt alle haben wollen.

Die Umsetzung ist so geplant: Sofern lib_munee verfügbar ist, gibt es im Backend eine Option, um die automatische Komprimierung zu aktivieren (oder eben nicht). Der Page Helper liefert dann statt der getrennten <link>-Einträge im Header nur noch einen, der wiederum auf lib_munee verweist. Dort gibt es dann einen Handler, der alles weitere verhackstückt. Die komprimierten Dateien werden von Munee verwaltet und liegen in ./temp/cache.

Externe Dateien - also z.B. vom CDN geladene Themes für jQuery UI oder Bootstrap - werden hierbei nicht angefaßt. Diese erscheinen weiterhin als eigene <link>-Einträge im Header.

Performancemäßig dauert das erste Komprimieren natürlich seine Zeit; je schneller der Server, desto schneller geht das.

SEO-mäßig gibt es Pluspunkte für weniger Header-Einträge.

Wenn der CSS-Teil fertig ist, wende ich mich dem JS-Teil zu. Das ist noch etwas sensibler - versemmeltes CSS versaut "nur" die Optik, versemmeltes JS kann die ganze Seite unbrauchbar machen. (Vor allem im Backend.)

[creativecat]

Wieso gibt es hier eigentlich noch kein Statement von mir?!?
Ich bastel gerade genau an dieser Lösung

Setze gerade auf dieses aktive Repository:
https://github.com/matthiasmullie/minify

Habe es inzwischen mal in die Page.php eingebaut und klappt soweit super. Auch so Spezialfreunde wie @media, @import oder aber auch calc() (=> Da haben die meisten echt Probleme) funktionieren damit einwandfrei!
Bilder werden dabei zB in base64 reingepackt. Insgesamt habe ich bei einem ersten Test mindestens 30% eingespart (hab nicht alle Bilder gecheckt, also könnte es durchaus mehr sein...).

Ich werde das Ding jetzt auch mal auf JS loslassen und testen...
Macht aber auf den ersten Blick einen sehr guten Eindruck. Evtl. könnte man im Sinne von SEO noch überlegen, ob die Dateien nicht irgendwie gecacht werden können. Also irgendeine Strategie so dass - wenn die gleichen CSS-Dateien aufgerufen werden würden - das Skript direkt den Link zum vorhandenen CSS ausspuckt anstatt noch mal alles zu packen. Da bin ich aber gerade noch am überlegen, ob und wie das sinnvoll umzusetzen wäre.

Zum generellen Sinn:
Es würde sich der Aufwand durchaus lohnen. Bei mir passiert es beinahe immer, dass ich 5-7 CSS-Dateien habe, weil jedes Modul und evtl Modulvarianten eigene CSS-Dateien benötigen. Teilweise habe ich schon über 10 CSS-Dateien gehabt. Ähnlich ist es mit JS (wobei ich hier in der Regel nicht ganz so viele Dateien habe).Was jeweils doch einiges an Zeit in Anspruch nimmt sind die vielen zusätzlichen Requests, die auch nicht durch ein @import vermieden werden. Das ist ja auch der Grund, warum Suchmaschinen einem es durchaus anrechnen, wenn man CSS Dateien packt. Dadurch, dass bei dem Minify-Tool auch noch die Bilder als base64 eingebettet sind, entfallen auch diese Requests.... also gleich noch ein Daumen hoch. Wie das mit print und media etc. ist... da bin ich aber auch noch nicht weiter als Bianka. Oder hast du hier inzwischen noch eine gute Idee?

[shadowcat]

Ich hatte dazu schon mal Code, muß ich mal suchen. Evtl. im 1.3 Strang im Repo. Das Munee cacht selbst, wenn ich mich recht erinnere. Letztlich geht es wohl nur so:

* Alle Dateien zusammenpacken
* Checksumme bilden
* Checksumme prüfen

Macht allerdings wenig Sinn, weil man erst mal packen muß, also nichts spart. Alternativ:

* Ganz normal die Dateien zusammensuchen
* Checksumme für jede Datei bilden
* Mit gespeicherter Checksumme vergleichen

Das würde bedeuten, dass man alle JS und CSS Dateien mit Checksummen versieht und diese speichert. Auch etwas Overhead.

Dritte Alternative:

* Beim Ändern einer Seite (Backend) -> Seite rendern, CSS und JS speichern, diese Version im FE ausgeben

Am wenigsten Overhead, dafür aber auch am wenigsten dynamisch. Problem mit AFE und Änderungen per FTP, weil das BE die nicht mitkriegt.