serendipity.css inline ausgeben

[niffchen]

Hallo alle miteinander,

ich habe gerade wieder mal eine Idee und bevor ich mir da in PHP was baue, wollte ich vorher mal die Profis gefragt haben.
Ich würde gerne das Einbinden der senrendipity.css etwas anpassen.
Und zwar möchte ich sie nicht als Verweis eingebunden haben (<link ...> ), sondern den Inhalt der Datei inline im Quellcode haben.
Gibt es da einen einfachen Weg, oder muss ich mir mit einer selbstgestrickten Lösung behelfen?
Vielen Dank für Eure Mühe!

Gruß,
Jens

[Timbalu]

Oh Gott - DAS willst du nicht wirklich, ...oder?
Wozu?
Das ist ein dynamisches File, dass alle unterschiedlichen CSS styles aus default, fallback, dem eigenen Template (also Theme) und allen Plugins bereitstellt und sich je nach Situation ständig ändert. (Dies kann ziemlich groß werden und ist "bloat Müll" der dir den header versaut...)

[yellowled]

Und zwar möchte ich sie nicht als Verweis eingebunden haben (<link ...> ), sondern den Inhalt der Datei inline im Quellcode haben.

Glaub mir, das möchtest Du nicht. Ganz sicher nicht. In keinem Projekt, unter keinen Umständen.

Was soll das bringen?

YL

[onli]

Der einfachste Weg ist wahrscheinlich, mit fetch den CSS-Code zu holen.

Ansonsten müsstest du ein include(S9Y_INCLUDE_PATH . 'serendipity.css.php'); ausführen, bei der Seitenerstellung, die ausgabe speichern und das ganze als Variable an Smarty übergeben.

[niffchen]

@onli: Danke für den Tipp! Ich werde mir das mal durch den Kopf gehen lassen. Ich weiß zwar noch nicht genau, wie Du meinst wo den fetch zu nutzen, aber ich kann ja auch mal nachdenken

Ich experimentiere ein bisschen hinsichtlich verschiedener Performancekombinationen und untersuche, was sich wie auswirkt. Da gehört auch da dazu um mal zu schauen, wie sich das auswirkt. Experimentieren und lernen heißt die aktuelle Unterreichtsstunden-Serie bei mir

[niffchen]

@onli: Also das mit dem fetch habe ich wohl verstanden, Du meinst sicher den Smarty-Befehl. Das versuche ich mal, ich bin gespannt ob die Versuche von Erfolg gekrönt sind.

@Timbalu, yellowled: Mich würde dennoch mal interessieren, was Euch dazu bewegt, daß ich das bestimmt nicht möchte. Ich bin weiß Gott kein Profi auf dem Gebiet, aber bisher habe ich gedacht, daß es von der Datenmenge keinen großen Unterschied macht, ob die serendipity.css als Datei angezogen wird oder ob der Code inline ist. Von der Menge sind es dieselben Daten. Auch wenn der Server komprimiert schickt, sollte es identisch sein, was die Datenmenge angeht. Oder liege ich dort falsch?
Dann würde mir nur auffallen, daß im Falle des Inline-Codes ein Serverrequest weniger ausgeführt wird, was dann natürlich zu Lasten der Lesbarkeit des Quellendes geht. Oder habe ich da etwas wichtiges übersehen?
Mich lässt es nicht so ganz in Ruhe, daß ihr so klar Stellung gegen mein Vorhaben bezogen habt und will das mal hinterfragen ... vielleicht kann ich da auch noch etwas lernen.

Ich danke Euch dreien schon mal sehr für Eure Mühe!

Gruß,
Jens

[yellowled]

Ich bin weiß Gott kein Profi auf dem Gebiet, aber bisher habe ich gedacht, daß es von der Datenmenge keinen großen Unterschied macht, ob die serendipity.css als Datei angezogen wird oder ob der Code inline ist.

Generell: Du erhöhst die Datenmenge der HTML-Datei (die hier dynamisch per PHP erzeugt wird, aber egal). HTML wird nicht browserseitig gecached, externe Stylesheets oder Javascripte schon. Das Cachen eines externen Stylesheets wiegt locker den HTTP-Request des Stylesheets auf.

Spezifisch für s9y: Wie Ian bereits sagte, wird das Stylesheet in s9y dynamisch erzeugt, d.h. die Styles Deines Themes (in der style.css) werden mit denen, die Plugins ggf. erzeugen, kombiniert. Diesen Mechanismus würdest Du komplett aushebeln.

Darüber hinaus nimmst Du Dir die Möglichkeit, {TEMPLATE_PATH} zu nutzen, um z.B. Hintergrundgrafiken in deinen CSS-Anweisungen zu referenzieren. „Einfach styles.css in ein <style>-Element kippen“ wird also schon mal in den meisten Fällen ohnehin nicht klappen.

Es gibt Fälle, in denen man das so macht, ja. Das sind kleine Demos, die wenig CSS haben und ggf. einfacher zu maintainen sind, wenn man alles (also auch JS) inline in eine HTML-Datei wirft. Die notwendigen Styles eines durchschnittlichen Blogthemes sind erheblich umfangreicher.

YL

[niffchen]

Vielen Dank für die Nachhilfe!
Da habe ich in der Tat ein oder zwei Dinge außer acht gelassen. Im Ansatz gut, Ausführung verbesserungswürdig ... würde ich sagen

Vielen Dank dafür!

[onli]

Yl, ich fall dir mal in den Rücken. Nichts für ungut, aber das stimmt so nicht ganz…

HTML wird nicht browserseitig gecached, externe Stylesheets oder Javascripte schon.

HTML wird nicht serverseitig gecached, wenn die Cache-Header (last-modified, Etag) nicht sauber gesetzt werden. Das kann für s9y sogar stimmen, ist aber nicht automatisch generell der Fall.

Spezifisch für s9y: Wie Ian bereits sagte, wird das Stylesheet in s9y dynamisch erzeugt, d.h. die Styles Deines Themes (in der style.css) werden mit denen, die Plugins ggf. erzeugen, kombiniert. Diesen Mechanismus würdest Du komplett aushebeln.

Darüber hinaus nimmst Du Dir die Möglichkeit, {TEMPLATE_PATH} zu nutzen, um z.B. Hintergrundgrafiken in deinen CSS-Anweisungen zu referenzieren. „Einfach styles.css in ein <style>-Element kippen“ wird also schon mal in den meisten Fällen ohnehin nicht klappen.

Wenn die CSS im PHP-code erzeugt und einer Variable übergeben werden, bleibt das beides erhalten. Wenn die CSS-Datei vom Server gefetcht wird, bliebe ebenfalls erhalten (das sollte nur unwesentlich schneller sein, weil der Server den HTTP-Request rausschicken muss. Aber entlastet den Client, und wird vll von Smarty gecached).

Das Hauptargument dagegen ist: Es wird dir nur unwesentlich Performance-Vorteile bringen, wenn überhaupt!

Aber es ist ein nettes Projekt, um in den Code von s9y reinzustöbern oder sauber benchmarken zu üben, was absolut nicht einfach ist. Also, nur zu, aber die Modifikation am besten nur auf nem Testblog testen und nicht in ein Livesystem fließen lassen.

[yellowled]

HTML wird nicht serverseitig gecached, wenn die Cache-Header (last-modified, Etag) nicht sauber gesetzt werden. Das kann für s9y sogar stimmen, ist aber nicht automatisch generell der Fall.

Wenn ich es in den Chrome Devtools richtig sehe, ist das so. Mag vom konkreten Serversetup abhängen, weil ich nicht. Ganz so einfach ist es ohnehin nicht, da kommt dann ja auch noch fingerprinting für sich gelegentlich ändernde Ressource ins Spiel usw.

Formulieren wir es um: man sollte nicht davon ausgehen, dass Markup cachebar ist.

Wenn die CSS im PHP-code erzeugt und einer Variable übergeben werden, bleibt das beides erhalten.

Wenn ich {TEMPLATE_PATH} im <head> der index.tpl verwende, bekomme ich einen white screen of death, aber vielleicht meinst Du etwas anderes.

YL

[Timbalu]

@onli: Danke für den Tipp! Ich werde mir das mal durch den Kopf gehen lassen. Ich weiß zwar noch nicht genau, wie Du meinst wo den fetch zu nutzen, aber ich kann ja auch mal nachdenken

Ich experimentiere ein bisschen hinsichtlich verschiedener Performancekombinationen und untersuche, was sich wie auswirkt. Da gehört auch da dazu um mal zu schauen, wie sich das auswirkt. Experimentieren und lernen heißt die aktuelle Unterreichtsstunden-Serie bei mir

Rumspielen, um zu lernen, ist völlig OK.
Wenn es wirklich um Performance ginge, müsstest du wesentlich früher ansetzen, denn sonst sattelst du mit der vorgeschlagenene Smarty fetch Methode ja noch ein oder mehr request(s) zusätzlich drauf und das wäre kontraproduktiv.

[niffchen]

Über Eure Ausführungen bin ich mehr zufällig auf einen anderen Ansatz gekommen den ich aktuell am lebenden Objekt teste. Ich pflücke jetzt den Header auseinander um die elementaren CSS-Dateien von den Add-Ons zu trennen. Prinzipiell ist die serendipity.css für den Seitenaufbau elementar, alles andere ist bei mir nicht direkt zum Start der Seite notwendig und kann nachgeladen werden.

Jetzt pflücke ich die auseinander und schiebe alle später wichtigen Dateien an das Ende der HTML-Datei. Somit blockieren die Dateien nicht mehr den Seitenaufbau. Mal sehen wie sich das produktiv auf Dauer verhält. Im Moment funktioniert das ganz gut.

Mal sehen ob ich das mit dem inline-Code nochmal angehe.

Gruß,
Jens

[yellowled]

Prinzipiell ist die serendipity.css für den Seitenaufbau elementar, alles andere ist bei mir nicht direkt zum Start der Seite notwendig und kann nachgeladen werden.

Jetzt pflücke ich die auseinander und schiebe alle später wichtigen Dateien an das Ende der HTML-Datei. Somit blockieren die Dateien nicht mehr den Seitenaufbau. Mal sehen wie sich das produktiv auf Dauer verhält.

Ich weiß, Du spielst nur rum. Trotzdem.

Wenn Du CSS außerhalb des <head> einfügst, wirst Du die Performance sehr wahrscheinlich bremsen. CSS sollte komplett geparst sein, ehe der Seitenaufbau beginnt. Ansonsten kann jeder weitere CSS-Block einen “reflow” auslösen, d.h. ein erneutes Kalkulieren diverser CSS-Werte (Breiten, Positionen usw.), was eben das Seitenrendering ausbremst.

Faustregel:

* CSS in den <head>
* JS vor das schließende </body> (es sei denn, es gibt gute Gründe, warum das JS im <head> sein sollte)

Letzteres ist leider in vielen CMS/Blogsystemen (auch in s9y) praktisch oft nicht leicht umzusetzen.

YL