CSS-JS-Booster: Image Inlining?!

[globe]

n'abend,

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…

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.

Ü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.

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.

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.

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?

Warum muss ein PHP-Prozess bemüht werden, um quasi-statische Daten auszuliefern, wenn kein Reversed-Proxy (squid, nginx, ...) zur Verfügung steht?

Hab ich hier irgendwas nicht kapiert?

weiterhin schönen abend...

[Cheatah]

Hi,

Ich bin eben über CSS-JS-Boster gestolpert. Was spricht denn für den Einsatz dieses Verfahrens?

es nimmt einige Optimierungen vor, die durchaus sinnvoll sein können.

Soll das ganze komplementär oder ersetzend zu CSS-Sprites sein?

Nein, es ist offenbar unabhängig davon.

Ich hänge mich am "Image Inlining" auf…

Wenn "es sich lohnt", werden Grafiken innerhalb des CSS-Codes abgelegt. Das ergibt mehr CSS, aber weniger HTTP. Abwägungssache.

Durch das Spriting reduziere ich den HTTP Overhead bereits enorm.

Ja, bleib dabei.

Diese Datei würde vom Booster nicht berücksichtigt werden. Demnach müsste auf Sprites verzichtet, oder eine Vielzahl davon eingesetzt werden.

Nein, die Grafiken landen einfach nicht im CSS-Code. Andere Optimierungen des Verfahrens sind davon vermutlich nicht betroffen und arbeiten ganz normal.

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.

Und eine Reduktion der Requests, die insbesondere nur begrenzt parallelisierbar sind. Wenn Du bereits die Anzahl der Image-Requests auf 1 reduziert hast, ist hier ein Optimum erreicht. Das Verfahren scheint dies zu honorieren, indem es keine Änderung vornimmt.

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.

Ist aber gar nicht mal so verkehrt. Download-Beschleuniger verfahren ähnlich.

Sprites:

Sind in Deinem Fall offensichtlich das ideale Verfahren, was Grafiken betrifft. Die Dinge, die nichts (direkt) mit Grafiken zu tun haben, könnten vom Booster beschleunigt werden.

Ist das beim Booster auch so, oder blockiert er das Rendern bis auch die Inlined Images angekommen sind?

Der Booster kann gar nichts blockieren. Die Frage ist, wie hier eine Rendering Engine vorgeht, also insbesondere ob die große CSS-Datenmenge abgearbeitet werden muss, bevor etwas dargestellt wird, oder ob es den Flash of Unstyled Content gibt. In Deinem Fall ist die Fragestellung irrelevant, weil Deine Sprite-Grafik ohnehin nicht im CSS-Code landet.

Warum muss ein PHP-Prozess bemüht werden, um quasi-statische Daten auszuliefern, wenn kein Reversed-Proxy (squid, nginx, ...) zur Verfügung steht?

Ich kenne das Produkt nicht und habe auch nicht vor, es zu analysieren. Möglicherweise besteht im Regelfall die Arbeit des PHP-Prozesses darin festzustellen, dass eine gecachte Ressource ausgeliefert werden kann.

Hab ich hier irgendwas nicht kapiert?

Der Booster verlagert einen hohen Performance-Aufwand auf der Clientseite zu einem (vergleichsweise) geringen Performance-Aufwand auf der Serverseite.

Cheatah

[globe]

n'abend,

Sind in Deinem Fall offensichtlich das ideale Verfahren, was Grafiken betrifft. Die Dinge, die nichts (direkt) mit Grafiken zu tun haben, könnten vom Booster beschleunigt werden.

Dinge die nicht mit Grafiken zu tun haben… was bleibt denn da noch? Fonts?

Der Booster kann gar nichts blockieren.

Du legst meine Wortwahl auf die Goldwaage. Natürlich meine ich das vom Booster produzierte und an den Browser übermittelte Resultat…

Die Frage ist, wie hier eine Rendering Engine vorgeht, also insbesondere ob die große CSS-Datenmenge abgearbeitet werden muss, bevor etwas dargestellt wird, oder ob es den Flash of Unstyled Content gibt.

Das ist DIE Frage hier, genau. Wäre interessant gewesen…

Warum muss ein PHP-Prozess bemüht werden, um quasi-statische Daten auszuliefern, wenn kein Reversed-Proxy (squid, nginx, ...) zur Verfügung steht?

Ich kenne das Produkt nicht und habe auch nicht vor, es zu analysieren. Möglicherweise besteht im Regelfall die Arbeit des PHP-Prozesses darin festzustellen, dass eine gecachte Ressource ausgeliefert werden kann.

Ansich ist meine Frage irrelevant. Das vermeiden unnötiger Aufrufe des PHP-Interpreters ist wohl eine (serverseitige) Optimierungsstufe weiter und hat mit dem Ziel des Boosters (Optimierung des HTTP-Streams) erstmal nichts zu tun.

weiterhin schönen abend...

[globe]

n'abend,

Ok. Dem CSS-JS-Booster muss man wohl lassen, dass es eine recht einfach zu integrierende Lösung ist. Das Deployment der durch CSS-JS-Booster erzielten Optimierungen dürfte einiges einfacher / schneller sein, als (manuell oder durch eins dieser unsäglich widerlichen Tools) Sprites zu bauen und das Sprite-CSS wieder manuell zu verwursten.

weiterhin schönen abend...

[Schepp]

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!

[Vinzenz Mai]

Hallo,

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.

und vermutlich auch dann nur, wenn der Browser nicht Google Chrome oder ein Internet Explorer ist? Siehe https://forum.selfhtml.org/?t=201131&m=1356999. Oder sehe ich das falsch?

Freundliche Grüße

Vinzenz

[Schepp]

und vermutlich auch dann nur, wenn der Browser nicht Google Chrome oder ein Internet Explorer ist? Siehe https://forum.selfhtml.org/?t=201131&m=1356999. Oder sehe ich das falsch?

Naja, es ist es bei allen Browsern unterschiedlich, aber 8 Requests darf man als globalen Richtwert stehenlassen. Mehr über den Ladezeiteneffekt kannst Du auf der folgenden Präsentation ab Seite 15 finden:

Performance Optimierung - Barrierefreiheit beginnt mit Ladezeiten