nicht angemeldet
Ich bin eben über CSS-JS-Boster gestolpert. Was spricht denn für den Einsatz dieses Verfahrens? Soll das ganze komplementär oder ersetzend zu CSS-Sprites sein? Ich hänge mich am "Image Inlining" auf…
Auch wenn du schon Spriting verwendest bringt Dir der Booster was, da er dafür sorge trägt, dass Dein CSS (und JS) in den Clients optimal gecached wird. Du hast also später null Requests, solange Du Deine CSS (und JS) Dateien nicht mehr anrührst.
Zudem sorgt er für eine ZIP-Komprimierung der Daten, und er führt alle 2KB ein Flushing durch, so dass schon nach 2KB erste Daten vom Browser verarbeitet werden können.
Durch das Spriting reduziere ich den HTTP Overhead bereits enorm. Aus 50 Requests wird noch einer. Also bleiben 2 Resourcen, eine Bild-Datei, eine CSS-Datei. Das Sprite kann hierbei sehr gerne mal >100KB sein. Diese Datei würde vom Booster nicht berücksichtigt werden. Demnach müsste auf Sprites verzichtet, oder eine Vielzahl davon eingesetzt werden.
Sprites werden durch das Inlining eigentlich überflüssig. Du kannst sie natürlich weiterhin einsetzen, aber Dein Bier, wenn Du Dir die Quälerei mit Pixelpositionierungen und so antun willst. Mir geht das tierisch auf den Nerv und spätestens wenn ich flexible (em-basierte) Layouts baue, kommt mir die Sprite-Technik als Boomerang entgegen. Nein danke. Ist Technik von gestern.
Üblicherweise nutzen die Einzelbilder des Sprites die gleiche Palette. Dadurch reduziert sich nicht nur der HTTP-Overhead, sondern das Sprite verliert gegenüber den einzelnen Dateien potentiell auch noch ein wenig Volumen.
Und sie sehen aufgrund des limitierten Farbraums schlechter aus. Zudem hast Du bei Sprites das Problem, dass Du nicht Fotos, Logos und Transparenzen unter Erhalt optimaler Qualität oder 8-Bit-Transparenz in einer Datei mixen kannst. Also steigt die Anzahl der Requests doch wieder, weil Du ein Sprite für JPGs, eines für 8-Bit-Dateien, udn eines für 24-Bit-PNGs anlegen musst. Nicht so beim Inlining. Da kann ich munter alle Dateitypen nebeneinander koexistieren lassen.
Der Booster versucht nun CSS und Bild in Einem zu übertragen. Das schafft er nur, wenn er die Binärsuppe des Bildes in Text überführt. Das wiederum bedeutet base64, das bedeutet wiederum künstliches Aufblasen des Volumens.
Stimmt. Aber dafür gibt es ja das ZIPing, das die ganze Geschichte dann wieder auf das Originalmaß eindampft. Zudem ist heutzutage nicht das Datenvolumen unser Hauptproblem, sondern einzig und allein die Zahl der Requests.
Damit der Browser, der multiple HTTP-Requests an den selben Host durchführen kann, von dieser Parallelität auch profitieren kann, teilt der Booster die zusammengeschobene CSS-base64kodierteBilder-Suppe wieder in zwei oder mehr Dateien auf. Also zuerst nativ unvereinbare Dateiformate auf Kosten des Volumens zusammenführen, dann wieder auftrennen. Hört sich irgendwie "komisch" an.
Bringt aber genau dann was, wenn Du insgesamt unter 8 Requests pro Seite erzeugst. Darfst Du aber gerne abschalten, per:
$booster->css_totalparts = 1;
Sprites: während die ggf. schneller geladene CSS-Datei bereits vom Browser verrendert wird, können die Sprites langsam eintrudeln. Position und Größe der Elemente, bei denen die Bilder zum Einsatz kommen, werden von den Bildern (da ohnehin nur Hintergrund) nicht beeinflusst. Theoretisch ist sukzessives Rendering möglich, ohne die bereits berechneten Positionen über den Haufen zu werfen.
Ist das beim Booster auch so, oder blockiert er das Rendern bis auch die Inlined Images angekommen sind?
In der Regel blockiert es. Deswegen ist es schlau, die Bilddefinitionen in eine separate CSS-Datei zu packen, und diese in den Fuß des Dokuments einzuhängen (mit insgesamt 2 Aufrufen des Boosters).
Warum muss ein PHP-Prozess bemüht werden, um quasi-statische Daten auszuliefern, wenn kein Reversed-Proxy (squid, nginx, ...) zur Verfügung steht?
Um den Timestamp der Dateien zu checken und ggfls. den Client die Datei aktualisieren zu lassen.
Hab ich hier irgendwas nicht kapiert?
Jepp. Jetzt besser? :)
Bei Fragen: frag!