nicht angemeldet
Der Martin
Matthias Apsel
MudGuard
Der Martin
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Guten Morgen!
Ich versuche zZ angestrengt, mir eine vernünftige Strategie zu überlegen, um CSS und Javascript möglichst zügig zu laden. Da da aber nicht so super vertraut mit der Materie bin, wollte ich mal fragen, ob folgende Überlegung klappen könnte oder ob jemand einen Denkfehler entdeckt:
Da ich CSS, welches für die Darstellung above-the-fold benötigt wird, nicht (oder nur sehr mühsam) eindeutig identifizieren kann, würde ich erstmal alles im head laden.
Ich lade es inline, um zusätzliche Requests einzusparen
Ich binde exakt denselben CSS Code nochmal als externes Script vor dem schließenden body tag ein. Dadurch wird die Seitenladezeit doch nicht negativ beeinflusst oder doch?
Falls es weitere Seitenaufrufe durch denselben Benutzer gibt (mittels Session Variable oder Cookie ermitteln???), gebe ich das CSS nur noch als externes Script im head aus (kein inline und kein Footerscript mehr).
Falls das Script beim allerersten Seitenaufruf im Browsercache gespeichert wurde, müsste bei folgenden Seitenaufrufen doch der Browser das externe Script im head ignorieren. Falls caching aus ist (eher selten oder?), läd der Browser das Script erneut -> Pech für den User.
Mit Javascript könnte ich dann ähnlich vorgehen. Mit dem Unterschied, dass einige Funktionen im head noch gar nicht benötigt werden und gleich in den Footer können.
Hochachtungsvoll socki
Hallo,
Ich versuche zZ angestrengt, mir eine vernünftige Strategie zu überlegen, um CSS und Javascript möglichst zügig zu laden.
die Überlegung ist an sich in Ordnung, aber ich fürchte, dass du teilweise auf dem Holzweg bist.
- Da ich CSS, welches für die Darstellung above-the-fold benötigt wird, nicht (oder nur sehr mühsam) eindeutig identifizieren kann, würde ich erstmal alles im head laden.
"above-the-fold"?? Alle CSS-Referenzen im head ist zunächst mal normal, ja geradezu zwingend. Woanders darf es nämlich gar nicht stehen.
- Ich lade es inline, um zusätzliche Requests einzusparen
Das ist kontraproduktiv. Die Einsparung eines Requests pro Seitenaufruf in allen Ehren, aber damit steigt für dich der Pflegeaufwand. Denn die Wahrscheinlichkeit ist doch sehr groß, dass wesentliche Teile des Stylesheets für alle Seiten deiner Website gleich sind. Hier würde ich die Wartungsfreundlichkeit höher ansetzen als ein paar Zehntelsekunden wegen eines weiteren Requests - abgesehen davon, dass das Stylesheet bei weiteren Aufrufen dann schon im Browser-Cache wäre und überhaupt nicht mehr geladen werden muss.
Ich gehe mal nicht davon aus, dass du mit inline meinst, style-Attribute im Markup zu verwenden.
- Ich binde exakt denselben CSS Code nochmal als externes Script vor dem schließenden body tag ein.
Das ist Unfug. Was soll das bringen? Abgesehen davon, dass <style> an dieser Stelle nicht erlaubt ist.
- Falls es weitere Seitenaufrufe durch denselben Benutzer gibt (mittels Session Variable oder Cookie ermitteln???), gebe ich das CSS nur noch als externes Script im head aus (kein inline und kein Footerscript mehr).
Warum?? Oder besser: Warum nicht von Anfang an so?
- Falls das Script beim allerersten Seitenaufruf im Browsercache gespeichert wurde, müsste bei folgenden Seitenaufrufen doch der Browser das externe Script im head ignorieren. Falls caching aus ist (eher selten oder?), läd der Browser das Script erneut -> Pech für den User.
Du konstruierst Probleme, wo keine sind.
Ciao, Martin
PS: CSS ist kein Script-Code. Den Begriff Script im Zusammenhang mit CSS zu verwenden, ist verwirrend.
Ich glaube, der Sinn meines Vorhabens ist noch kein Stück rübergekommen oder? Liegt vielleicht auch daran, dass ich einige Begriffe falsch verwendet habe. Sorry! Mit inline CSS meine ich eigentlich ein zentrales style-Element. Und mit CSS Script meine ich eine externe CSS-Datei (richtig so oder?). Also nochmal zum Kern der Sache:
Ich möchte die Vorteile eines style-Elements im html (weniger Requests) mit den Vorteilen des externen CSS (Browser Caching) verbinden. Die meisten deiner Einwände sollten sich vor diesem Hintergrund erübrigt haben. Aber ich will nochmal kurz auf die Kommentare eingehen.
"above-the-fold"?? Alle CSS-Referenzen im head ist zunächst mal normal, ja geradezu zwingend. Woanders darf es nämlich gar nicht stehen.
Hier mal eine Seite, die ganz am Ende in Dokument noch ein style-Element verwendet: https://www.was-soll-ich-schenken.net/ Die Seite läd sogar außergewöhnlich schnell. Wenn's funktioniert, funktioniert's.
- Ich lade es inline, um zusätzliche Requests einzusparen
Das ist kontraproduktiv. Die Einsparung eines Requests pro Seitenaufruf in allen Ehren, aber damit steigt für dich der Pflegeaufwand. Denn die Wahrscheinlichkeit ist doch sehr groß, dass wesentliche Teile des Stylesheets für alle Seiten deiner Website gleich sind. Hier würde ich die Wartungsfreundlichkeit höher ansetzen als ein paar Zehntelsekunden wegen eines weiteren Requests - abgesehen davon, dass das Stylesheet bei weiteren Aufrufen dann schon im Browser-Cache wäre und überhaupt nicht mehr geladen werden muss.
Ich gehe mal nicht davon aus, dass du mit inline meinst, style-Attribute im Markup zu verwenden.
Da du ja schon selbst erkannt hast, dass ich mit "inline" ein zentrales style-Element meinte und kein Style Attribut (nochmals sorry), macht deine Aussage nicht wirklich Sinn. Die CSS Regeln, die für alle Seiten gleich sind, können als CSS-Block in den head geschrieben werden oder aus einer externen Datei eingebunden werden. Macht vom Aufwand keinen Unterschied. Und das mit dem Browser Cache versuche ich ja durch die externe Datei im footer zu bezwecken.
- Ich binde exakt denselben CSS Code nochmal als externes Script vor dem schließenden body tag ein.
Das ist Unfug. Was soll das bringen? Abgesehen davon, dass <style> an dieser Stelle nicht erlaubt ist.
Das befördert das CSS für spätere Seitenaufrufe in den Browsercache. <style> ist zwar nicht erlaubt, funktioniert aber trotzdem (s.o.). Und wie ich bereits geschrieben habe, will ich es auch per <link> tag einbinden.
- Falls es weitere Seitenaufrufe durch denselben Benutzer gibt (mittels Session Variable oder Cookie ermitteln???), gebe ich das CSS nur noch als externes Script im head aus (kein inline und kein Footerscript mehr).
Warum?? Oder besser: Warum nicht von Anfang an so?
Weil meine Methode beim erstmaligen Seitenaufruf schneller läd (hoffe ich jedenfalls).
Der Kern meiner Frage ist vermutlich: Beeinträchtigt eine zusätzliche CSS Datei im Footer (extern per <link..> eingebunden) die Ladezeit? Und wird bei darauffolgenden Seitenaufrufen dieselbe Datei (diesmal im head eingebunden) vom Browser ignoriert? Sie sollte ja im Cache sein.
Ich werd es mal auf einer Testseite ausprobieren. Bliebe zuletzt aber noch die Frage bei welchem Prozentsatz der User das Browsercaching fehlschlägt.
Mahlzeit,
Ich möchte die Vorteile eines style-Elements im html (weniger Requests) mit den Vorteilen des externen CSS (Browser Caching) verbinden. Die meisten deiner Einwände sollten sich vor diesem Hintergrund erübrigt haben.
nein, keineswegs, und ich glaube, ich hatte es auch durchaus richtig verstanden. Nur kann ich nicht nachvollziehen, dass du an Symptomen "optimieren" willst, die so minimal sind, dass sie im allgemeinen Rauschen untergehen. Und noch dazu willst du für derartige Micro-Optimierungen die Validität des Dokuments aufgeben (so sie denn überhaupt gegeben ist).
Hier mal eine Seite, die ganz am Ende in Dokument noch ein style-Element verwendet: https://www.was-soll-ich-schenken.net/ Die Seite läd sogar außergewöhnlich schnell. Wenn's funktioniert, funktioniert's.
Browser sind fehlertolerant. Vieles, was nicht erlaubt ist, funktioniert trotzdem. Für mich trotzdem kein Grund, bewusst fehlerhafte Dokumente zu bauen.
Das ist kontraproduktiv. Die Einsparung eines Requests pro Seitenaufruf in allen Ehren, aber damit steigt für dich der Pflegeaufwand. Denn die Wahrscheinlichkeit ist doch sehr groß, dass wesentliche Teile des Stylesheets für alle Seiten deiner Website gleich sind. Hier würde ich die Wartungsfreundlichkeit höher ansetzen als ein paar Zehntelsekunden wegen eines weiteren Requests - abgesehen davon, dass das Stylesheet bei weiteren Aufrufen dann schon im Browser-Cache wäre und überhaupt nicht mehr geladen werden muss. Da du ja schon selbst erkannt hast, dass ich mit "inline" ein zentrales style-Element meinte und kein Style Attribut (nochmals sorry), macht deine Aussage nicht wirklich Sinn.
Nein? Ist es nicht einfacher, ein externes Stylesheet zu pflegen, das in allen Dokumenten eingebunden wird, als den style-Block in, sagen wir, einem Dutzend HTML-Dokumenten zu editieren?
- Falls es weitere Seitenaufrufe durch denselben Benutzer gibt (mittels Session Variable oder Cookie ermitteln???), gebe ich das CSS nur noch als externes Script im head aus (kein inline und kein Footerscript mehr). Warum?? Oder besser: Warum nicht von Anfang an so? Weil meine Methode beim erstmaligen Seitenaufruf schneller läd (hoffe ich jedenfalls).
In der Theorie, ja. Vielleicht auch in der Praxis. Aber die zwei bis drei Zehntelsekunden wird vermutlich niemand bemerken.
Ich werd es mal auf einer Testseite ausprobieren. Bliebe zuletzt aber noch die Frage bei welchem Prozentsatz der User das Browsercaching fehlschlägt.
Das wird ein verschwindend geringer Anteil sein, vermute ich.
Ciao, Martin
Nur nochmal zum Verständnis, da du die ganze Zeit von "fehlerhaft" sprichst: Wenn ich folgendes im Footer einbinde: <link rel="stylesheet" href="style.css" type="text/css"> ...dann geht es doch nur darum, es in den Browsercache zu befördern. Selbst wenn es nicht valide ist, wird die Seite doch mittels des restlichen Codes (der valide ist) gerendert. Auf einen Fehler mehr oder weniger im Validator kommt es doch da nicht an.
Nein? Ist es nicht einfacher, ein externes Stylesheet zu pflegen, das in allen Dokumenten eingebunden wird, als den style-Block in, sagen wir, einem Dutzend HTML-Dokumenten zu editieren?
Ich benutze ein CMS und muss den CSS Block nur einmal in die header.php schreiben.
In der Theorie, ja. Vielleicht auch in der Praxis. Aber die zwei bis drei Zehntelsekunden wird vermutlich niemand bemerken.
Danke für die Einschätzung!
Ich werd es mal auf einer Testseite ausprobieren. Bliebe zuletzt aber noch die Frage bei welchem Prozentsatz der User das Browsercaching fehlschlägt.
Das wird ein verschwindend geringer Anteil sein, vermute ich.
Danke!
@@Der Martin:
nuqneH
Nein? Ist es nicht einfacher, ein externes Stylesheet zu pflegen, das in allen Dokumenten eingebunden wird, als den style-Block in, sagen wir, einem Dutzend HTML-Dokumenten zu editieren?
Nein. Es geht nicht darum, den Inhalt des style-Elements in verschiedenen HTML-Dateien händisch zu pflegen. Sondern das Stylesheet automatisiert serverseitig in das HTML-Dokument einzubauen, wenn es der Client nicht schon im Cache oder im LocalStorage hat.
Qapla'
@@Gunnar Bittersmann:
Es geht nicht darum, den Inhalt des style-Elements in verschiedenen HTML-Dateien händisch zu pflegen. Sondern das Stylesheet automatisiert serverseitig in das HTML-Dokument einzubauen, wenn es der Client nicht schon im Cache oder im LocalStorage hat.
Nochmal fürs Archiv: Inlining critical CSS for first-time visits (Jeremy Keith)
LLAP
Om nah hoo pez nyeetz, Der Martin!
Abgesehen davon, dass <style> an dieser Stelle nicht erlaubt ist.
In HTML5 schon, mit einem scoped-Attribut, Browserunterstützung mangelhaft.
Matthias
Guten Morgen!
- Da ich CSS, welches für die Darstellung above-the-fold benötigt wird, nicht (oder nur sehr mühsam) eindeutig identifizieren kann, würde ich erstmal alles im head laden.
above-the-fold scheint ein neuer SEO-Trick zu sein. Ich habe mal ein bischen recherchiert, bin jedoch aus den Suchergebnissen nicht schlau geworden. Könntest Du hier mal mit ein paar wenigen Worten erklären, was das ist?
Hochachtungsvoll
Horst Helium
@@hotti:
nuqneH
above-the-fold scheint ein neuer SEO-Trick zu sein.
Nö, mit SEO hat das hier nichts zu tun, sondern mit performance.
Ich habe mal ein bischen recherchiert, bin jedoch aus den Suchergebnissen nicht schlau geworden.
Unter „critical path“ solltest du fündig werden.
Qapla'
> above-the-fold scheint ein neuer SEO-Trick zu sein. Ich habe mal ein bischen recherchiert, bin jedoch aus den Suchergebnissen nicht schlau geworden. Könntest Du hier mal mit ein paar wenigen Worten erklären, was das ist?
Das meint alle Elemente, die ohne scrollen sichtbar sind. Für jede Bildschirmauflösung ist das natürlich anders. Aber scheinbar gibt es Gründe zwischen CSS und Javascript für den above-the-fold Bereich und den nicht-above-the-fold Bereich zu unterscheiden. Siehe dieser Artikel: http://www.blog-it-solutions.de/wordpress-performance-inline-external-javascript-css/
above-the-fold scheint ein neuer SEO-Trick zu sein. Ich habe mal ein bischen recherchiert, bin jedoch aus den Suchergebnissen nicht schlau geworden. Könntest Du hier mal mit ein paar wenigen Worten erklären, was das ist?
Das meint alle Elemente, die ohne scrollen sichtbar sind. Für jede Bildschirmauflösung ist das natürlich anders. Aber scheinbar gibt es Gründe zwischen CSS und Javascript für den above-the-fold Bereich und den nicht-above-the-fold Bereich zu unterscheiden. Siehe dieser Artikel: http://www.blog-it-solutions.de/wordpress-performance-inline-external-javascript-css/
Interessanter Artikel. Soweit ich das verstehe, wird das Rendern der Inhalte durch das Laden von CSS-Ressoucen ausgebremst. Styles asynchron nachzuladen (ajax) wäre eine mögliche Lösung. Funktional habe ich das eben mal erfolgreich getestet, ob es wirklich was bringt, muss ich mir näher anschauen.
above-the-fold scheint ein neuer SEO-Trick zu sein. Ich habe mal ein bischen recherchiert, bin jedoch aus den Suchergebnissen nicht schlau geworden. Könntest Du hier mal mit ein paar wenigen Worten erklären, was das ist?
Das meint alle Elemente, die ohne scrollen sichtbar sind. Für jede Bildschirmauflösung ist das natürlich anders. Aber scheinbar gibt es Gründe zwischen CSS und Javascript für den above-the-fold Bereich und den nicht-above-the-fold Bereich zu unterscheiden. Siehe dieser Artikel: http://www.blog-it-solutions.de/wordpress-performance-inline-external-javascript-css/
Interessanter Artikel. Soweit ich das verstehe, wird das Rendern der Inhalte durch das Laden von CSS-Ressoucen ausgebremst. Styles asynchron nachzuladen (ajax) wäre eine mögliche Lösung. Funktional habe ich das eben mal erfolgreich getestet, ob es wirklich was bringt, muss ich mir näher anschauen.
Done ;)
Unterscheide zwischen kritischem und unkritischem CSS. Above-the-fold ist das, was sofort nach dem Aufruf der Seite sichtbar ist (ohne dass gescrollt werden muss). Hierzu muss das kritische CSS geladen sein. Möglich sind serverseitige Maßnahmen zur Optimierung.
Below-the-fold ist das, was nach dem Scrollen sichtbar wird. Das damit verbundene unkritische CSS kann bspw. asynchron nachgeladen werden, Beispiel in der Callback-Funktion:
Auge
if(eav.mesg.css){
var style = document.createElement('style');
style.innerHTML = eav.mesg.css;
var head = document.getElementsByTagName('head')[0];
head.appendChild(style);
}
Die eigentliche Strategie zur Optimierung besteht jedoch darin, die Styledefinitionen aufzuteilen (kritisch/unkritisch).
MfG
[CSS]
Ich lade es inline, um zusätzliche Requests einzusparen
Ich binde exakt denselben CSS Code nochmal als externes Script vor dem schließenden body tag ein. Dadurch wird die Seitenladezeit doch nicht negativ beeinflusst oder doch?
Hm. Wäre ich der User-Agent, dann würde ich mit dem Rendern abwarten, bis auch das externe Stylesheet geladen wurde. Und dann überschreibe ich in Deinem Fall, die schon erhaltenen Informationen und rendere.
Folge: Gerade kein Zeitgewinn, doppelte Arbeit für alle.
Hast Du statische oder quasistatische Webseiten und ist die der Stylesheet relativ klein, dann binde ihn "indocument" ein ("inline" wäre in der Zeile...) und schau, wie Du das gezippt sendest.
Jörg Reinholz
Hi,
um wieviele Megabyte CSS/JS geht es eigentlich?
Sprich: lohnt es sich überhaupt, darüber nachzudenken?
cu, Andreas
Hi,
um wieviele Megabyte CSS/JS geht es eigentlich?
Sprich: lohnt es sich überhaupt, darüber nachzudenken?
Es geht ja vor allem um die Anzahl der Requests. Die Dateigröße reduziert sich ja durch meine Methode nicht.
CSS: 19 kb 5 Requests
Javascript: 119 kb 15 Requests
Einige Javascripts wie zB solche durch Google Adsense müssen wohl aber so oder so extern eingebunden werden.
Es geht ja vor allem um die Anzahl der Requests. Die Dateigröße reduziert sich ja durch meine Methode nicht.
CSS: 19 kb 5 Requests
Javascript: 119 kb 15 Requests
Und wieso, bitte, soll sich das nicht zusammenfassen lassen? Unter Linux gibt es dafür ein Werkzeug namens "cat". Du musst also nicht einmal einen Texteditor bemühen ...
Jörg Reinholz
Hi,
Und wieso, bitte, soll sich das nicht zusammenfassen lassen? Unter Linux gibt es dafür ein Werkzeug namens "cat".
und unter Windows lässt sich dasselbe mit "copy" erreichen.
Du musst also nicht einmal einen Texteditor bemühen ...
Alternativ wäre SSI eine nette Idee: Man behält einzelne Dateien, die unabhängig voneinander gepflegt werden, liefert sie aber als eine einzige Ressource aus.
Ciao, Martin
Alternativ wäre SSI eine nette Idee: Man behält einzelne Dateien, die unabhängig voneinander gepflegt werden, liefert sie aber als eine einzige Ressource aus.
Und ein Wordpress Plugin (JS & CSS Script Optimizer) habe ich gerade gefunden, das dasselbe tut. Ich merke schon, wegen einem einzigen Request, der da noch übrig bliebe, muss man nicht so'n Aufriss machen.
Danke für alle Tipps!
@@Der Martin:
nuqneH
Und wieso, bitte, soll sich das nicht zusammenfassen lassen? Unter Linux gibt es dafür ein Werkzeug namens "cat".
und unter Windows lässt sich dasselbe mit "copy" erreichen.
Und wenn man einen CSS-Präprozessor einsetzt, kriegt man schon eine CSS-Datei aus mehreren Quelldateien generiert.
Für JavaScript wird man ein Tool einsetzen, das neben dem Minifying auch das Zusammenfassen übernimmt.
Qapla'
Hi,
Und wieso, bitte, soll sich das nicht zusammenfassen lassen? Unter Linux gibt es dafür ein Werkzeug namens "cat".
und unter Windows lässt sich dasselbe mit "copy" erreichen.
Du musst also nicht einmal einen Texteditor bemühen ...
Alternativ wäre SSI eine nette Idee: Man behält einzelne Dateien, die unabhängig voneinander gepflegt werden, liefert sie aber als eine einzige Ressource aus.
SSI ist der ultimative Performancekiller, nur zu ;)
Und wieso, bitte, soll sich das nicht zusammenfassen lassen? Unter Linux gibt es dafür ein Werkzeug namens "cat". Du musst also nicht einmal einen Texteditor bemühen ...
Man, manchmal hab ich glaub ich ein Brett vor'm Kopf. Danke für den Hinweis! Alles was ich in ein style-Element geschrieben hätte, hätte ich ja damit schon zusammengefasst. Ich hätte also gegenüber deiner Methode nur einen einzigen Request gespart.
Vielleicht probier ich's trotzdem mal aus, wenn alle anderen Optimierungsmaßnahmen abgeschlossen sind :)
Tut mir leid, dass ich hier soviel Wind gemacht habe. Ich hab ja gesagt, ich bin noch nicht ganz fit in der Materie...
Hallo
Man, manchmal hab ich glaub ich ein Brett vor'm Kopf. Danke für den Hinweis! Alles was ich in ein style-Element geschrieben hätte, hätte ich ja damit schon zusammengefasst. Ich hätte also gegenüber deiner Methode nur einen einzigen Request gespart.
Weil du hier immer auf den Requests herumreitest, mal so als Denkanstoß:
Nehmen wir an, du fasstest alle CSS-Regeln zusammen und ließest sie per PHP, SSI, WAI [1] in den <head>-Bereich eines jeden Dokuments einbauen, um einen oder mehrere Requests zu sparen. Der zusätzliche oder die zusätzlichen Requests unterblieben nun. Du erkauftest dir diesen Performancegewinn allerdings damit, alle CSS-Regeln bei jeder Auslieferung eines Dokuments mitzuschicken, da sie ja dort drinnen stünden.
Bei statischen Dokumenten mag das keine Rolle spielen, da sie selbst gecacht werden. Bei dynamischen Seiten, die aufgrund möglicher Änderungen des Inhalts immer wieder direkt vom Server kommen, hast du eher Verluste, weil die größere Datenmenge mit einiger Wahrscheinlichkeit die Zeitersparnis des oder der Requests aufwiegt. Dass das dynamische Einbinden des CSS-Blocks in den <head>-Bereich selbst auch Rechenzeit kostet, lassen wir mal dahingestellt. Wenn die Seite sowieso durch den Interpreter der Wahl geht, spielt das wohl nicht mehr die entscheidende Rolle.
[1] WasAuchImmer; ich kann das „you name it“ echt nicht mehr hören/lesen.
Tschö, Auge
@@Auge:
nuqneH
Nehmen wir an, du fasstest alle CSS-Regeln zusammen und ließest sie per PHP, SSI, WAI [1] in den <head>-Bereich eines jeden Dokuments einbauen, um einen oder mehrere Requests zu sparen. Der zusätzliche oder die zusätzlichen Requests unterblieben nun. Du erkauftest dir diesen Performancegewinn allerdings damit, alle CSS-Regeln bei jeder Auslieferung eines Dokuments mitzuschicken, da sie ja dort drinnen stünden.
Qapla'
Hallo
Nehmen wir an, du fasstest alle CSS-Regeln zusammen und ließest sie per PHP, SSI, WAI [1] in den <head>-Bereich eines jeden Dokuments einbauen, um einen oder mehrere Requests zu sparen. Der zusätzliche oder die zusätzlichen Requests unterblieben nun. Du erkauftest dir diesen Performancegewinn allerdings damit, alle CSS-Regeln bei jeder Auslieferung eines Dokuments mitzuschicken, da sie ja dort drinnen stünden.
Du tust mir echt leid. Ist es dir auf deinem hohen Ross wirklich derart unmöglich, dich verständlich auszudrücken? Besteht deine Kommunikationsfähigkeit wirklich nur im Hinwerfen von Brocken, von selbstreferenziellen Links auf eigene Postings, in denen nicht selten auch nur ein verlinktes „Nein“ steht?
Auf diesen asozialen Scheiß habe ich keine Lust mehr.
Tschö, Auge
@@Auge:
nuqneH
Besteht deine Kommunikationsfähigkeit wirklich nur im Hinwerfen von Brocken, von selbstreferenziellen Links auf eigene Postings, in denen nicht selten auch nur ein verlinktes „Nein“ steht?
Ich sollte also – weil Postings anscheinend nicht gelesen werden – alles doppelt und dreifach aufschreiben? Auch innerhalb eines Threads? Muss es jedesmal neu formuliert werden oder genügt es per copy and paste?
Anstelle von copy and paste gibt es im Web übrigens was ganz Großartiges: Links.
Also gehen wir dem Link nochmal zusammen nach. Ich : „[Es geht darum,] das Stylesheet automatisiert serverseitig in das HTML-Dokument einzubauen, wenn es der Client nicht schon im Cache oder im LocalStorage hat.“
Was war daran nicht verstämdlich?
„Nebensatz“ sagt etwas über die grammatikalische Struktur; nicht, dass der Inhalt nebensächlich wär.
Nachdem ich also schon klarstellte „wenn der Client [das Stylesheet] nicht schon im Cache oder im LocalStorage hat“, kommst du mit „alle CSS-Regeln bei jeder Auslieferung eines Dokuments mitzuschicken“.
Offensichtlich hattest du mein Posting nicht gelesen, deshalb hatte ich es dir nochmals verlinkt.
Solltest du es doch gelesen haben und sogar den Nebansatz nicht überlesen haben, aber dessen Bedeutung nicht erfasst, hättest du nachfragen können.
Ich komme dem jetzt mal zuvor. Serverseitiger Pseudocode könnte so aussehen:
[code]WENN Cookie „habe Stylesheet schon“:
<script>
hole Stylesheet aus LocalStorage
</script>
SONST
<style>
alle Regeln im Dokument
</style>
<script>
speichere Stylesheet im LocalStorage
setze Cookie „habe Stylesheet schon“
</script>[/code]
Qapla'
@@Gunnar Bittersmann:
nuqneH
[code]SONST
<style>alle Regeln im Dokument</style>[/code]
Wobei „alle Regeln im Dokument“ wie nicht heißt, dass der CSS-Code direkt drinsteht, sondern dass er serverseitig eingebunden wird. Also eher
[code]SONST
<style>
include 'default.css'
</style>[/code]
include ist hier metasyntaktisch zu verstehen und kann, wenn es sich bei der serverseitigen Technik um PHP handelt, durchaus readfile bedeuten.
Qapla'
Hehe. Das kannst Du bei besserer Laune bestimmt auch ganz anders - oder?
Jörg Reinholz
Hallo
Hehe. Das kannst Du bei besserer Laune bestimmt auch ganz anders - oder?
Hätte ich vielleicht können können.
Tschö, Auge
Wenn man es ganz richtig machen will, dann speichert man die Dateien auch noch vorkomprimiert ab - das entlastet den Server und beschleunigt die Auslieferung. Das browswerseitige Dekomprimieren liegt dann vom Aufwand her betrachtet im Millisekunden-Bereich.
Allerdings sollte man das nicht tun, wenn es sich um "Dreizeiler" handelt, weil dann der Aufwand den Nutzen steigt.
Jörg Reinholz
Guten Morgen!
- Falls es weitere Seitenaufrufe durch denselben Benutzer gibt (mittels Session Variable oder Cookie ermitteln???), gebe ich das CSS nur noch als externes Script im head aus (kein inline und kein Footerscript mehr).
Es gibt tatsächlich eine Möglichkeit, die effektiver ist, als der Browser-Cache: Die CSS-Datei wird im Hauptspeicher gecached. Das setzt natürlich voraus, dass auch der Prozess im Speicher verbleibt und nicht bei jedem Request neu gestartet werden muss. Techniken hierzu sind z.B. mod_perl oder FastCGI.
MfG
Es gibt tatsächlich eine Möglichkeit, die effektiver ist, als der Browser-Cache: Die CSS-Datei wird im Hauptspeicher gecached. Das setzt natürlich voraus, dass auch der Prozess im Speicher verbleibt und nicht bei jedem Request neu gestartet werden muss. Techniken hierzu sind z.B. mod_perl oder FastCGI.
Fachlich hilfreich? Wie kann - selbst der schnellste Server der Welt - schneller sein als ein clientseitiger Cache?
Es gibt tatsächlich eine Möglichkeit, die effektiver ist, als der Browser-Cache: Die CSS-Datei wird im Hauptspeicher gecached. Das setzt natürlich voraus, dass auch der Prozess im Speicher verbleibt und nicht bei jedem Request neu gestartet werden muss. Techniken hierzu sind z.B. mod_perl oder FastCGI.
Fachlich hilfreich? Wie kann - selbst der schnellste Server der Welt - schneller sein als ein clientseitiger Cache?
Überhaupt nicht. Aber ein serverseitiger MemCache käschd auch das, was ein Client noch gar nicht im eigenen Cache hat, was z.B. ein ganz anderer Benutzer zetlich vorher angefordert hat. Ein Benutzer profitiert somit von einem solchen Cache bereits beim seinem ersten Request.
Es gibt tatsächlich eine Möglichkeit, die effektiver ist, als der Browser-Cache: Fachlich hilfreich? Wie kann - selbst der schnellste Server der Welt - schneller sein als ein clientseitiger Cache? Überhaupt nicht.
Zitat: "Es gibt tatsächlich eine Möglichkeit, die effektiver ist, als der Browser-Cache"
Es gibt tatsächlich eine Möglichkeit, die effektiver ist, als der Browser-Cache: Fachlich hilfreich? Wie kann - selbst der schnellste Server der Welt - schneller sein als ein clientseitiger Cache? Überhaupt nicht.
Zitat: "Es gibt tatsächlich eine Möglichkeit, die effektiver ist, als der Browser-Cache"
Deine Wortspielereien sind kein Ersatz für fachliche Kompetenz.
Es gibt tatsächlich eine Möglichkeit, die effektiver ist, als der Browser-Cache: Fachlich hilfreich? Wie kann - selbst der schnellste Server der Welt - schneller sein als ein clientseitiger Cache? Überhaupt nicht.
Zitat: "Es gibt tatsächlich eine Möglichkeit, die effektiver ist, als der Browser-Cache"
Deine Wortspielereien sind kein Ersatz für fachliche Kompetenz.
Definitiv. Nur waren es Deine Worte.
Definitiv.
Hast ja Recht. Der hotti hat sich da beim Formulieren ein wenig vertan, weil sein memcache mit dem Browsercache natürlich nicht viel zu schaffen hat. Aber ihn mal als Idee zu benennen war natürlich auch "fachlich hilfreich".
Wobei es aus meiner Sicht immer noch besser ist, quasistatisches Zeug (also gerade CSS und JS!) zu jeweils möglichst wenigen Dateien zusammenzufassen und vorgezippt zum Abruf bereit zu halten.
Jörg Reinholz
@@socki:
nuqneH
Ich versuche zZ angestrengt, mir eine vernünftige Strategie zu überlegen, um CSS und Javascript möglichst zügig zu laden.
Beim Guardian hat man sich darüber Gedanken gemacht. Andere machen’s nach.
In Improving Smashing Magazine’s Performance: A Case Study (unter Front-End Optimization) und Using localStorage to improve critical CSS rendering solltest du Informationen dazu (incl. weiterführender Links) finden.
Qapla'
@@socki:
nuqneH
Ich versuche zZ angestrengt, mir eine vernünftige Strategie zu überlegen, um CSS und Javascript möglichst zügig zu laden.
Font Loading Revisited with Font Events
Qapla'
@@socki:
Noch ein Lesebefehl: Inlining critical CSS for first-time visits (Jeremy Keith)
LLAP