Minfied JS, CSS Erfahrungen, links

[omaliesschen]

Hi,

ich hatte vor längerem mal einen kleinen minifizierten JS Codesnippet eingestellt um ihn zu deminifizieren. Einige Reaktionen waren der Meinung das im gesamten kaum ein Vorteil zu erwarten ist.

Mittlerweile weiß ich auch wie der Code minifiziert, optimiert wurde.

Google bietet einen JS optimierer an der weit über die Standards hinausgeht:
https://developers.google.com/closure/compiler/docs/gettingstarted_ui

Dazu gibt es hier den meiner Meinung nach besten, freien, CSS Optimierer:
http://www.art2digital.com/new-media/tools/css-optimiser.php


Nachdem ich mein JS und das CSS mit den Tools optimiert hate hat sich die Zeit des Seitenaufbaus halbiert.

Sehr zu empfehlen.

 

[SymA]

Du könntest es zusätzlich noch steigern, indem du alle Stylesheets und Skriptdateien zusammenfassen lässt von Google Minify - dadurch hast du nur noch maximal 2 HTTP-Requests für CSS und JS jeweils. Das beschleunigt den Vorgang doch nochmal (enorm) - Reihenfolge muss jedoch beachtet werden, vor allem bei der Vernwendung mit jQuery und zusätzlichen Plugins.

 

[John Reese]

Wie SymA empfohlen hat:
http://code.google.com/p/minify/

Minify - ein Vorteil ist, dass du trotzdem ganz normal deine Dateien handhaben kannst und auch so entwickeln kannst und sich das Skript vollautomatisch um das "minifizieren" kümmert.

 

[omaliesschen]

Ich werd eine cache Lösung nehmen die CSS und JS zusammenführt und cached. Glaube das war nicht von google.

 

[carom]

Neben dem Minifizieren und Kombinieren von JS und CSS lohnt noch ein Blick auf die expire header sowie gzip, außerdem kann man größere Mengen kleinerer Grafien (z.B. Icons) als Sprite ausliefern. Dann ist man für's erste ganz gut aufgestellt, bringen tut es jedenfalls eine Menge.

 

[ice-breaker]

Und was ist an der Erkenntnis von JS- und CSS-Minifiern so neu?

Die geschickte Person lässt sich das von nem grunt script erledigen, inkl. vieler weiterer Deployment-Schritte.

 

[omaliesschen]

Ist es falsch die guten Tools hier zu nennen? Es gibt vll. Leute die davon profitieren könnten.

Der google closure optimizer kann weit mehr als nur minimieren.

 

[Daaron]

Ich bleib für JS beim yui-compressor. Da muss ich nicht jedes Mal Google bemühen, sondern änder meine 2-3 Stellen im Code und fütter die Commandline.

Viel wichtiger als solche Kompressoren ist das Zusammenfassen der verschiedenen Code-Schnipsel sowie gutes Caching. Ob der Besucher beim ersten Seitenaufruf 2 oder 3 Sekunden braucht spielt weniger eine Rolle als die Frage, was mit Unterseiten ist. Wenn er da durch ne gute Caching-Strategie jeweils nur 1s braucht ist das viel wertvoller als bereits beim ersten Aufruf hochgradig optimierten Code auszugeben.

So gesehen: Eine CSS-Deklaration mit allen Werten, eine js-File mit allen Scripten. Alles was nicht in die eine JS-Datei kann, kommt aus einem CDN.

 

[SymA]

Ich bleib für JS beim yui-compressor. Da muss ich nicht jedes Mal Google bemühen, sondern änder meine 2-3 Stellen im Code und fütter die Commandline.

Viel wichtiger als solche Kompressoren ist das Zusammenfassen der verschiedenen Code-Schnipsel sowie gutes Caching. Ob der Besucher beim ersten Seitenaufruf 2 oder 3 Sekunden braucht spielt weniger eine Rolle als die Frage, was mit Unterseiten ist. Wenn er da durch ne gute Caching-Strategie jeweils nur 1s braucht ist das viel wertvoller als bereits beim ersten Aufruf hochgradig optimierten Code auszugeben.

So gesehen: Eine CSS-Deklaration mit allen Werten, eine js-File mit allen Scripten. Alles was nicht in die eine JS-Datei kann, kommt aus einem CDN.

Google Minify erzeugt beim Aufruf der Seite ein einzige große Datei mit allen Skripten und Stylesheets - somit sparst du dir den Umweg manuell per Hand den Yuicompressor zu bemühen. Darüber hinaus kannst du auch Google Minify sagen, dass er YUI benutzen soll für die Kompression und Zusammenfassung. Imho ist 1s für jede Seite mit statischem Kontext viel zu viel.

 

[Speedy.]

Was ich noch empfehlen kann sind Data URIs. Über die Seite http://websemantics.co.uk/online_tools/image_to_data_uri_convertor/ lassen sich Bilder in Data URIs konvertieren und können so direkt in den Code eingebunden werden. Der Vorteil ist, dass HTTP-Anfragen verringert werden, da die Bilder nicht mehr vom Server abgeholt sondern direkt mit dem Code geladen und angezeigt werden. Der Nachteil ist, dass es den Quellcode ziemlich aufblasen kann nicht schön aussieht. Aber wer achtet da am Ende schon drauf

Ich würde das aber nicht für normale Bilder sondern eher für Grafiken wie Icons nutzen.

 

[Daaron]

Imho ist 1s für jede Seite mit statischem Kontext viel zu viel.

Welche Seite hat schon nur statischen Content? Und von welcher Bandbreite reden wir hier? Meist ist die Time To First Byte der Löwenanteil.

Was ich noch empfehlen kann sind Data URIs. Über die Seite http://websemantics.co.uk/online_tools/image_to_data_uri_convertor/ lassen sich Bilder in Data URIs konvertieren und können so direkt in den Code eingebunden werden.

Genau deshalb mag ich Contao (3): Einfach in der internen Stylesheet-Deklaration sagen, dass Background-Images bis zu ner bestimmten Größe als URI konvertiert werden sollen. Wenn man dann das Icon doch mal ändern muss, weil z.B. n kleiner Fehler bei den Farben ist, reagiert das CMS automatisch und erzeugt die URI nebst komprimierter CSS automatisch neu.

 

[omaliesschen]

Wenn man dann das Icon doch mal ändern muss, weil z.B. n kleiner Fehler bei den Farben ist, reagiert das CMS automatisch und erzeugt die URI nebst komprimierter CSS automatisch neu.

Warum keinen Icon-Font nutzen? Hintergründe etc. mit CSS.

 

[palace4d]

Die geschickte Person lässt sich das von nem grunt script erledigen, inkl. vieler weiterer Deployment-Schritte.

Genau so wirds gemacht. Alles vollautomatisiert, ohne sinnsloses umschreiben im HTML bspw.

 

[SymA]

Die geschickte Person verwendet auch Design Pattern, Abstraktion und Architektur. Darüber brauchen wir aber nicht reden....

 

[Daaron]

Warum keinen Icon-Font nutzen? Hintergründe etc. mit CSS.

1.) Traffic: Wenn ich 20 Icons hab, dann nehm ich ne Icon-Font. Wenn ich 3 Icons hab, dann spare ich enorm viel Traffic, indem ich die Dinger als URI ausgebe.
2.) Flexibilität: Eine .png kann vieles, was eine Font nicht kann. Besser gesagt: Ich müsste die Font selbst definieren, wenn ich spezielle Icons will. Will ich ein Icon marginal ändern, dann muss ich die ganze Font ändern. Aufwand und Nutzen....
Soviel zu den Icons...

Und CSS-Hintergründe können bei weitem nicht alles, was man gern hätte. Du kannst z.B. in CSS kein kleines Gittermuster erzeugen, oder ein statisches Rauschen. Dabei sind das alles sehr hübsche Effekte, die in einer 20x20px großen PNG schnell gemacht sind.

 

[ice-breaker]

Was ich noch empfehlen kann sind Data URIs.

[...]

Ich würde das aber nicht für normale Bilder sondern eher für Grafiken wie Icons nutzen.

Und die Icons dürfen bei jedem Webseitenaufruf neu geladen werden, hurrah...
Dafür wurden schon vor Ewigkeiten das Konzept der "Spritesets" erfunden, alle Icons in eine Datei packen, nur noch 1 HTTP-Anfrage und die kann gecacht werden.
Wer besonders trickreich ist und die Icons nur über CSS einbindet (z.B. Bootstraps icon-envelope) kann aber eine Data-URI in der CSS-Datei nutzen, spart eine HTTP-Anfrage und lässt die CSS-Datei cachen, dann sollte aber das Icon wirklich nur per CSS-Klasse genutzt werden.


Zusammenfassend würde ich sagen:
Wer sich dafür interessiert findet heutzutage dafür im Netz mehr als genug Informationen, die über Jahre zusamengetragen wurden, Frontend Performance ist kein #Neuland mehr. Und es gibt soviele Aspekte und Optimierungen, dass es den Umfang eines solchen Threads sprengt. Wer noch nie von Google PageSpeed gehört hat, sollte das nachholen und die Performancetips umsetzen, damit hat man gut 99% der wirklich nützlichen Tipps schon umgesetzt.

 

[Daaron]

Und die Icons dürfen bei jedem Webseitenaufruf neu geladen werden, hurrah...

Wenn man die Data URIs korrekt verwendet (in CSS-Dateien) stellt das kein Problem dar. Die werden genauso gecached wie alles andere auch. Glaub, niemand ist so dämlich und gibt im HTML-Code eine Data URI an.

Dafür wurden schon vor Ewigkeiten das Konzept der "Spritesets" erfunden, alle Icons in eine Datei packen, nur noch 1 HTTP-Anfrage und die kann gecacht werden.

Spritesets stoßen schnell mal an ihre Grenzen. Sobald du eine Wiederholung in 2 Achsen brauchst gehts gar nicht, in eine Achse gehts zumindest mies. Und wenn du nur ein Icon des Spritesets änderst muss der User das ganze Set neu laden.

Wer noch nie von Google PageSpeed gehört hat, sollte das nachholen und die Performancetips umsetzen, damit hat man gut 99% der wirklich nützlichen Tipps schon umgesetzt.

YSlow sollte man auch angucken.