nicht angemeldet
marctrix
Matthias Apsel
marctrix
Auge
Matthias Apsel
Gunnar Bittersmann
marctrix
Hej alle,
was ist eigentlich der Vorteil von @media print gegenüber einer expliziten print.css - in dem Artikel des Wiki wird von "Übersichtlichkeit" geredet. Das dürfte Ansichtssache sein.
Der hauptsächliche Vorteil ist IMHO einen HTTP-Request zu sparen und beim minifizieren usw nur eine Datei handeln zu müssen.
BTW: warum laden die Browser die print.css überhaupt, wenn die Seite auf einem Bildschirm angezeigt wird? - Macht es Sinn, die print.css aus Performance-Gründen am Seitenende einzubinden - habe das schlicht nie probiert...
Marc
Hallo marctrix,
was ist eigentlich der Vorteil von @media print gegenüber einer expliziten print.css - in dem Artikel des Wiki wird von "Übersichtlichkeit" geredet. Das dürfte Ansichtssache sein.
Der hauptsächliche Vorteil ist IMHO einen HTTP-Request zu sparen und beim minifizieren usw nur eine Datei handeln zu müssen.
Und du benötigst ggf. doppelte Einträge. Regeln, die für screen und print gleichermaßen gelten sollen, müssen dann auch in beiden Ressourcen stehen.
BTW: warum laden die Browser die print.css überhaupt, wenn die Seite auf einem Bildschirm angezeigt wird?
k. A.
Macht es Sinn, die print.css aus Performance-Gründen am Seitenende einzubinden - habe das schlicht nie probiert...
Es ergibt Sinn, auf eine print.css zu verzichten. CSS gehört zudem in den head, falls es kein scoped-Attribut besitzt. Die Unterstützung ist mau.
Bis demnächst
Matthias
Hej Matthias,
was ist eigentlich der Vorteil von @media print gegenüber einer expliziten print.css - in dem Artikel des Wiki wird von "Übersichtlichkeit" geredet. Das dürfte Ansichtssache sein.
Der hauptsächliche Vorteil ist IMHO einen HTTP-Request zu sparen und beim minifizieren usw nur eine Datei handeln zu müssen.
Und du benötigst ggf. doppelte Einträge. Regeln, die für screen und print gleichermaßen gelten sollen, müssen dann auch in beiden Ressourcen stehen.
Die habe ich nie benötigt, als ich noch mit mehreren Dateien gearbeitet habe - eine Datei galt für alle Medien-typen, in der print.css wurde nur überschrieben, was im Druck anders sein sollte.
Wenn das nicht reicht, braucht man drei Dateien (all, screen und print), um möglichst DRY zu arbeiten (dont repeat yourself).
Macht es Sinn, die print.css aus Performance-Gründen am Seitenende einzubinden - habe das schlicht nie probiert...
Es ergibt Sinn, auf eine print.css zu verzichten.
Ja, aber warum?
CSS gehört zudem in den head, falls es kein scoped-Attribut besitzt. Die Unterstützung ist mau.
Ich habe es selber auch immer im head, hatte aber mal Kontakt zu einem PHPler, der an beliebigen Stellen des Dokumentes <style></style> eingebaut hat - wo immer es ihm gerade passte. - Auch wenn ich es selbst nie so machen würde: es hat funktioniert.
Für die Druck-Datei könnte ich es mir darum durchaus am Ende des Dokumentes vorstellen - wenn es denn eine Druck-CSS sein muss. Was duchaus Sinn machen könnte, um die Bildschirmdarstellung zu beschleunigen.
Mich nervt es ehrlich gesagt, dass die print.css übrhaupt geladen wird, obwohl eine Webseite heutzutage kaum noch ausgedruckt wird - man hat sie ja auf dem Smartphone immer dabei.
Die Styles in eine CSS-Datei für alle zu schreiben ist für die allermeisten auch unnötiger Datenballast, der nie benötigt wird. - Unschön, aber ich weiß auch keine Lösung. Alles in eine Datei zu schreiben ist aber nur die am wenigsten schlechte Lösung IMHO...
Marc
Hallo
CSS gehört zudem in den head, falls es kein scoped-Attribut besitzt. Die Unterstützung ist mau.
Ich habe es selber auch immer im head, hatte aber mal Kontakt zu einem PHPler, der an beliebigen Stellen des Dokumentes <style></style> eingebaut hat - wo immer es ihm gerade passte. - Auch wenn ich es selbst nie so machen würde: es hat funktioniert.
Gesehen habe ich sowas auch schon, auch, dass es funktioniert. Das sollte an der Fehlertoleranz der Browser liegen. Verlassen sollte man sich also darauf nicht, auch wenn eine Änderung an der Stelle nicht sehr wahscheinlich ist.
Mich nervt es ehrlich gesagt, dass die print.css übrhaupt geladen wird, obwohl eine Webseite heutzutage kaum noch ausgedruckt wird - man hat sie ja auf dem Smartphone immer dabei.
Im Gegensatz z.B. zu einem Aural-CSS, dessen Laden nur in einem vorlesefähigen Client Sinn ergibt, kann ein Ausdruck theoretisch von so ziemlich jedem Client aus erfolgen. Ein Aural-CSS sollte also nur von einem fähigen Programm geladen werden, ein Print-CSS, wenn es denn schon einmal da ist, sollte sofort geladen werden, damit es instantan benutzt werden kann, wenn der User einen Ausdruck erstellen will. Wenn das CSS erst dann geladen wird, wenn der Druck gestartet wird, meckert der User nämlich wegen der Verzögerung.
Dass der Ausdruck einer Seite eher die Ausnahme ist, steht auf einem anderen Blatt.
Die Styles in eine CSS-Datei für alle zu schreiben ist für die allermeisten auch unnötiger Datenballast, der nie benötigt wird. - Unschön, aber ich weiß auch keine Lösung. Alles in eine Datei zu schreiben ist aber nur die am wenigsten schlechte Lösung IMHO...
Der Regelsatz für den Ausdruck ist ja typischerweise recht übersichtlich. Spielt dieses (vermutlich übersichtliche) Mehr in Zeiten von Minifizierung und komprimierter Übertragung eine so große Rolle?
Tschö, Auge
Hej Auge,
[Nutzer beschweren sich über Zeitverzögerung beim Druck]
Würde man das denn überhaupt merken? - Wenn ein einziger HHTP-Request ausgeführt qwerden muss? Bei der Version die von allen Besuchern gesehen wird, hältst du es für akzeptabel, dass diese Verzögerung in Kauf genommen wird, die wenigen, die eine Seite dann tatsächlich ausdrucken willst du vor dieser Verzögerung schützen (wobei die natürlich auch warten müssen - nur eben schon beim Aufruf der Bildschirm-Version).
Die Styles in eine CSS-Datei für alle zu schreiben ist für die allermeisten auch unnötiger Datenballast, der nie benötigt wird. - Unschön, aber ich weiß auch keine Lösung. Alles in eine Datei zu schreiben ist aber nur die am wenigsten schlechte Lösung IMHO...
Der Regelsatz für den Ausdruck ist ja typischerweise recht übersichtlich. Spielt dieses (vermutlich übersichtliche) Mehr in Zeiten von Minifizierung und komprimierter Übertragung eine so große Rolle?
Keine Ahnung. Kommt darauf an, wie viel Byte für eine ordentliche Druckversion tatsächlich anfallen, wie viel das im Verhältnis zu dem von allen Browsern benötigten. Viel ist ja immer relativ. Bei 300 Seitenuafrufen im Monat langweilt sich ein Server eh - selbst wenn der heimische Router diese Aufgabe zusätzlich zu allen anderen mit erledigt. Bei 300 Mio Seitenaufrufen im Monat sieht es wieder anders aus. Was ist "viel"?
Marc
PS: Wenn ich 300 Mio Seitenaufrufe habe, mach ich Feirabend!
Hallo
[Nutzer beschweren sich über Zeitverzögerung beim Druck]
Würde man das denn überhaupt merken? - Wenn ein einziger HHTP-Request ausgeführt qwerden muss?
Ehrlich gesagt, keine Ahnung. Das Laden der paar hundert Bytes selbst werden es wohl nicht sein. Mit Overhead und Verarbeitung wird etwas herauskommen, was irgendwem den Kamm schwellen lässt.
Bei der Version die von allen Besuchern gesehen wird, hältst du es für akzeptabel, dass diese Verzögerung in Kauf genommen wird, die wenigen, die eine Seite dann tatsächlich ausdrucken willst du vor dieser Verzögerung schützen
Ich will in dieser Hinsicht garnichts. Schon garnicht will ich irgendwen vor irgendetwas schützen, indem ich jemanden anders etwas aufbürde. Du fragtest nach dem Grund, warum dsa Druck-CSS immer mitgeladen wird, ich wollte dir einen Erklärungsansatz liefern. Es mag weitere technische Gründe dafür geben, auf die wollte ich aber nicht hinaus.
Der Regelsatz für den Ausdruck ist ja typischerweise recht übersichtlich. Spielt dieses (vermutlich übersichtliche) Mehr in Zeiten von Minifizierung und komprimierter Übertragung eine so große Rolle?
Keine Ahnung. Kommt darauf an, wie viel Byte für eine ordentliche Druckversion tatsächlich anfallen, wie viel das im Verhältnis zu dem von allen Browsern benötigten.
Mein Druck-CSS für das SelfForum, das fast dem hier tatsächlich eingesetzten CSS-Regelwerk entspricht, umfasst mit Autorennennung und Formatierung – also unminifiziert – 2,15 kB, das zugehörige JS ein weiteres kB. Die HTML-Struktur des Forums hat aber auch seine ganz eigenen Anforderungen. Typischerweise wird man an dieser Stelle mit weniger CSS und ohne JS auskommen.
Viel ist ja immer relativ. Bei 300 Seitenuafrufen im Monat langweilt sich ein Server eh - selbst wenn der heimische Router diese Aufgabe zusätzlich zu allen anderen mit erledigt. Bei 300 Mio Seitenaufrufen im Monat sieht es wieder anders aus. Was ist "viel"?
In Anbetracht der steigenden durchschnittlichen Seitengrößen mache ich mir um die paar hinzukommenden CSS-Regeln nicht so viele Gedanken. Wobei natürlich abgewogen werden sollte, ob man für seine Seiten überhaupt ein Druck-CSS braucht. In einer Dokumentation halte ich es für angebracht, eines dabei zu haben, für den Großteil der Seiten, die ich oft frequentiere (Foren, Nachrichtenseiten, Unterhaltungskram), hingegen nicht.
PS: Wenn ich 300 Mio Seitenaufrufe habe, mach ich Feirabend!
:-)
Tschö, Auge
Hej Auge,
Bei der Version die von allen Besuchern gesehen wird, hältst du es für akzeptabel, dass diese Verzögerung in Kauf genommen wird, die wenigen, die eine Seite dann tatsächlich ausdrucken willst du vor dieser Verzögerung schützen
Ich will in dieser Hinsicht garnichts.
Schon klar, mir schien das nur widersprüchlich... _ sollte kein Angriff sein.
Der Regelsatz für den Ausdruck ist ja typischerweise recht übersichtlich. Spielt dieses (vermutlich übersichtliche) Mehr in Zeiten von Minifizierung und komprimierter Übertragung eine so große Rolle?
Keine Ahnung. Kommt darauf an, wie viel Byte für eine ordentliche Druckversion tatsächlich anfallen, wie viel das im Verhältnis zu dem von allen Browsern benötigten.
Mein Druck-CSS für das SelfForum, das fast dem hier tatsächlich eingesetzten CSS-Regelwerk entspricht, umfasst mit Autorennennung und Formatierung – also unminifiziert – 2,15 kB, das zugehörige JS ein weiteres kB.
Trotzdem wäre es ein technischer Ansatz. Die mir nicht immer nachvollziehbaren Wünsche von Designern erfordern aber mitunter mehr.
Die HTML-Struktur des Forums hat aber auch seine ganz eigenen Anforderungen. Typischerweise wird man an dieser Stelle mit weniger CSS und ohne JS auskommen.
Nun ja, jede Seite hat ihre Besonderheiten, jedenfalls fast jede. Aber das ist schon sehr wenig. Auch in Anbetracht der Tatsache, dass das screendesign "normal" viel Platz beansprucht.
Viel ist ja immer relativ. Bei 300 Seitenuafrufen im Monat langweilt sich ein Server eh - selbst wenn der heimische Router diese Aufgabe zusätzlich zu allen anderen mit erledigt. Bei 300 Mio Seitenaufrufen im Monat sieht es wieder anders aus. Was ist "viel"?
In Anbetracht der steigenden durchschnittlichen Seitengrößen mache ich mir um die paar hinzukommenden CSS-Regeln nicht so viele Gedanken.
Bei allen, denen das eh Wurscht ist, muss man über die paar Kilobyte natürlich nicht reden ;-)
Marc
@@Auge
Wenn das CSS erst dann geladen wird, wenn der Druck gestartet wird, meckert der User nämlich wegen der Verzögerung.
Würde da wirklich was verzögert werden? Oder würde der Drucker nicht losrattern ohne auf das Nachladen des Stylesheets zu warten, d.h. eine ungewollte Ausgabe erzeugen?
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Hallo
Wenn das CSS erst dann geladen wird, wenn der Druck gestartet wird, meckert der User nämlich wegen der Verzögerung.
Würde da wirklich was verzögert werden? Oder würde der Drucker nicht losrattern ohne auf das Nachladen des Stylesheets zu warten, d.h. eine ungewollte Ausgabe erzeugen?
Gute Frage, wenn auch nur eine akademische. Wenn in den Browsern implementiert wäre, ein Druck-CSS (als eigene Datei) beim laden der Seite nicht zu berücksichtigen und erst bei Bedarf, wenn der Druckbefehl gegeben wurde, nachzuladen, würde ich erwarten, dass der Ausdruck entsprechend verzögert würde, bis das Druck-CSS geladen und interpretiert wurde. Da das aber nicht so funktioniert, ist ein gleich mitgeladenes Druck-CSS da und wird berücksichtigt oder es ist nicht da und die Seite wird, mit den vorhandenen Regeln gerendert, an den Drucker ausgeliefert.
Tschö, Auge
Hej Gunnar,
@@Auge
Wenn das CSS erst dann geladen wird, wenn der Druck gestartet wird, meckert der User nämlich wegen der Verzögerung.
Würde da wirklich was verzögert werden? Oder würde der Drucker nicht losrattern ohne auf das Nachladen des Stylesheets zu warten, d.h. eine ungewollte Ausgabe erzeugen?
Das ist meine Befürchtung - ich probiere es mal aus.
Kurztest-Ergebnis: Die unten angegebenen Styles funktionieren in FF und Safari, aber nicht in Chrome.
Marc
Hej marctrix,
Korrektur meines anderen Ichs: es funktioniert in keinem Browser (wenn man eine externe Datei einbindet):
Ich hatte einen Fehler in meinem Test (desto seltsamer, wie die Browser darauf reagieren, aber das ist ein anderes Thema). Was in einigen Browsern funktioniert: eine Angabe wie diese vor dem schließenden </html>:
<style type="text/css" media="print">
body {
border: 1px solid red;
}
</style>
Ersetzt man die Regel durch @import klappt es in keinem Browser mehr...
Marc
Hallo marctrix,
Die habe ich nie benötigt, als ich noch mit mehreren Dateien gearbeitet habe - eine Datei galt für alle Medien-typen, in der print.css wurde nur überschrieben, was im Druck anders sein sollte.
Geregelt durch die Reihenfolge der Einbindung. Ok. Möglich.
Bis demnächst
Matthias
@@marctrix
CSS gehört zudem in den head, falls es kein scoped-Attribut besitzt. Die Unterstützung ist mau.
Die Unterstützung von scoped ja; für die Unterstützung von style im body gilt das nicht.
… der an beliebigen Stellen des Dokumentes <style></style> eingebaut hat - wo immer es ihm gerade passte. - Auch wenn ich es selbst nie so machen würde: es hat funktioniert.
Siehste.
Für die Druck-Datei könnte ich es mir darum durchaus am Ende des Dokumentes vorstellen - wenn es denn eine Druck-CSS sein muss. Was duchaus Sinn machen könnte, um die Bildschirmdarstellung zu beschleunigen.
Aus diesem Grund gibt es Bestrebungen, style im body zu erlauben: The future of loading CSS (Jake Archibald).
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Hallo Marc,
CSS gehört zudem in den head, falls es kein scoped-Attribut besitzt. Die Unterstützung ist mau.
Ich habe es selber auch immer im head, hatte aber mal Kontakt zu einem PHPler, der an beliebigen Stellen des Dokumentes <style></style> eingebaut hat - wo immer es ihm gerade passte. - Auch wenn ich es selbst nie so machen würde: es hat funktioniert.
So ist es auch logisch. Ich baue meine HTML-PLatzhalter-Dateien aus Bausteinen auf. Zu jedem Stein gehört auch das Layout. Das Konzept wird anderswo als "objektorientiert" beworben, nur in einer HTML-Datei sollen Objekte von ihren Eigenschaften getrennt werden?
Mich nervt es ehrlich gesagt, dass die print.css übrhaupt geladen wird, obwohl eine Webseite heutzutage kaum noch ausgedruckt wird - man hat sie ja auf dem Smartphone immer dabei.
Witziges Argument. Ich drucke viel. Ein Blatt Papier ist deutlich günstiger, als jedesmal ein Smartphone wegzugeben //frechgrins//
Die Styles in eine CSS-Datei für alle zu schreiben ist für die allermeisten auch unnötiger Datenballast, der nie benötigt wird.
Hmm ... wer sind die "allermeisten", die auf jeder Seite ein anderes Layout haben? Kenne ich nicht. In der Regel wird eine zentrale CSS-Datei aus dem Cache geholt, damit muss sie nicht als "Daten-Ballast" erneut bei jeder Seite über die Leitung gehen.
Unschön, aber ich weiß auch keine Lösung. Alles in eine Datei zu schreiben ist aber nur die am wenigsten schlechte Lösung IMHO...
Ich weiss nicht, ob ich hier ein Geheimnis lüften darf. Ich habe in der zentralen CSS-Datei die übergeordneten Regeln für alle Seiten. Die kann man in der Einzelseite ergänzen und sogar überschreiben.
Aber ich bin ja noch aus dem letzten Jahrtausend, als man mehrere Seiten einer Web-Präsentation nacheinander anschaute. Die "allermeisten" hüpfen wohl mal hier, mal dahin?
Linuchs
Hej Linuchs,
CSS gehört zudem in den head, falls es kein scoped-Attribut besitzt. Die Unterstützung ist mau.
Ich habe es selber auch immer im head, hatte aber mal Kontakt zu einem PHPler, der an beliebigen Stellen des Dokumentes <style></style> eingebaut hat - wo immer es ihm gerade passte. - Auch wenn ich es selbst nie so machen würde: es hat funktioniert.
So ist es auch logisch. Ich baue meine HTML-PLatzhalter-Dateien aus Bausteinen auf. Zu jedem Stein gehört auch das Layout. Das Konzept wird anderswo als "objektorientiert" beworben, nur in einer HTML-Datei sollen Objekte von ihren Eigenschaften getrennt werden?
Das war auch sein Argument als Programmierer - für mich als CSS-Opa ist es angenehmer, einen Ort zu haben, an dem ich alles steuern kann.
Mich nervt es ehrlich gesagt, dass die print.css übrhaupt geladen wird, obwohl eine Webseite heutzutage kaum noch ausgedruckt wird - man hat sie ja auf dem Smartphone immer dabei.
Witziges Argument. Ich drucke viel. Ein Blatt Papier ist deutlich günstiger, als jedesmal ein Smartphone wegzugeben //frechgrins//
Ja, der ist gut! - Was für die Zitate-Sammlung!
Ich gebe nur urls weiter...
Die Styles in eine CSS-Datei für alle zu schreiben ist für die allermeisten auch unnötiger Datenballast, der nie benötigt wird.
Hmm ... wer sind die "allermeisten", die auf jeder Seite ein anderes Layout haben? Kenne ich nicht. In der Regel wird eine zentrale CSS-Datei aus dem Cache geholt, damit muss sie nicht als "Daten-Ballast" erneut bei jeder Seite über die Leitung gehen.
Die Allermeisten sind IMHO diejenigen, die nicht ausdrucken.
Unschön, aber ich weiß auch keine Lösung. Alles in eine Datei zu schreiben ist aber nur die am wenigsten schlechte Lösung IMHO...
Ich weiss nicht, ob ich hier ein Geheimnis lüften darf. Ich habe in der zentralen CSS-Datei die übergeordneten Regeln für alle Seiten. Die kann man in der Einzelseite ergänzen und sogar überschreiben.
Schwer zu pflegen...
Aber ich bin ja noch aus dem letzten Jahrtausend, als man mehrere Seiten einer Web-Präsentation nacheinander anschaute. Die "allermeisten" hüpfen wohl mal hier, mal dahin?
Den habe ich nicht gerafft...
Marc
was ist eigentlich der Vorteil von @media print gegenüber einer expliziten print.css - in dem Artikel des Wiki wird von "Übersichtlichkeit" geredet. Das dürfte Ansichtssache sein.
Den Artikel solltest du auch nicht als der Weisheit letzter Schluss ansehen. Was übersichtlich ist, soll jeder selber entscheiden und hängt vor allem auch von der Situation ab.
Braucht eine Seite nur eine Handvoll zusätzlicher Anweisungen für den Druck, ist eine zusätzliche Datei ganz bestimmt nichts, was die Übersichtlichkeit steigert; da könnte eher das Gegenteil der Fall sein. Andersrum mag sich jemand bei sehr umfangreichen Geschichten in separaten Dateien besser zurecht finden als in einem zwanzig Seiten umfassenden CSS-Gebirge. Und sind andere Personen in die Entwicklung eingebunden, kann das noch wieder anders sein.
Also, völlig richtig: Ansichtssache.
BTW: warum laden die Browser die print.css überhaupt, wenn die Seite auf einem Bildschirm angezeigt wird?
Dazu wäre vorweg anzumerken, dass wohl keine Seite zuerst auf einem Drucker ausgegeben wird, jede erscheint zuerst auf einem Bildschirm.
Es dürfte dann grundsätzlich sinnig sein, alle zur Seite gehörigen Elemente zur selben Zeit zu laden. Mal als realitätsfernes, aber dafür um so offensichtlicheres Beispiel: Werden die Druckdaten erst einen Monat nach den Bildschirmdaten geladen, passen erste möglicherweise nicht mehr zu letzteren.
Vielleicht sollen auch alle Daten so schnell wie möglich zur Verfügung stehen, wenn sie gebraucht werden – manche Browser laden ja sogar ganze Webseiten noch bevor sie überhaupt aufgerufen werden, einfach auf Verdacht hin.
In Kombination dürfte es vermutlich am Klügsten sein, Elemente, die eindeutig nur für den Druck gedacht sind, zwar sofort bei Seitenaufruf zu laden, aber erst ganz am Ende der Warteschlange.
Und ganz vielleicht hat sich darüber aber auch einfach niemand Gedanken gemacht.
Macht es Sinn, die print.css aus Performance-Gründen am Seitenende einzubinden
Sowas hängt immer von der Seite ab. Was hast du davon, ein Element, das nur 1% des Gesamtvolumens der Seite ausmacht, zuletzt zu laden? Der Flaschenhals liegt dann woanders und wenn die Inhalte so uninteressant sind, dass du beim Übertragen ein halbes Sekündchen sparen musst, um die Besucher zu halten …
Hej Isch,
BTW: warum laden die Browser die print.css überhaupt, wenn die Seite auf einem Bildschirm angezeigt wird?
Dazu wäre vorweg anzumerken, dass wohl keine Seite zuerst auf einem Drucker ausgegeben wird, jede erscheint zuerst auf einem Bildschirm.
Ich kann mir schon Drucker mit Internet-Anschluss vorstellen - oder ein Skript, das HTML-Seiten automatisiert an einen Drucker ausgibt...
Es dürfte dann grundsätzlich sinnig sein, alle zur Seite gehörigen Elemente zur selben Zeit zu laden. Mal als realitätsfernes, aber dafür um so offensichtlicheres Beispiel: Werden die Druckdaten erst einen Monat nach den Bildschirmdaten geladen, passen erste möglicherweise nicht mehr zu letzteren.
Was meinst du mit "Bildschirmdaten" und "Druckdaten"? Styles?
Vielleicht sollen auch alle Daten so schnell wie möglich zur Verfügung stehen, wenn sie gebraucht werden – manche Browser laden ja sogar ganze Webseiten noch bevor sie überhaupt aufgerufen werden, einfach auf Verdacht hin.
Aber hier besteht kein Grund für einen Verdacht - die Styles werden per media="print" ja ausdrücklich als irrelevant für die Bildschirm-Darstellung gekennzeichnet.
Das "Vorladen" NACH dem Laden der zuerst benötigten Daten für die Bildschirmdarstellung kann sein. Klar. Aber vorher? - Guck Dir mal die Timeline an in den Entwicklerwerkzeugen eines Browsers. Die werden in der Reihenfolge geladen, wie sie im HTML angegeben werden (was wenig überraschend ist, da dies mit allen externen Dateien so gemacht wird - deswegen bindet man ja z. B. JavaScript so weit wie möglich am Seitenende ein).
In Kombination dürfte es vermutlich am Klügsten sein, Elemente, die eindeutig nur für den Druck gedacht sind, zwar sofort bei Seitenaufruf zu laden, aber erst ganz am Ende der Warteschlange.
Sehe ich genauso. Machen Browser aber nciht so.
Und ganz vielleicht hat sich darüber aber auch einfach niemand Gedanken gemacht.
Mindestens bei Google macht man sich eigentlich viel Gedanken über Performanz. Ich bi mir sicher es gibt einen (technischen) Grund. Den wüsste ich halt gern...
Macht es Sinn, die print.css aus Performance-Gründen am Seitenende einzubinden
Sowas hängt immer von der Seite ab. Was hast du davon, ein Element, das nur 1% des Gesamtvolumens der Seite ausmacht, zuletzt zu laden?
1% und einen HTTP-Request weniger VOR dem Laden der eigentlichen Inhalte. Außerdem kann das auf gut gemachten Seiten schon mehr sein (beim ersten Seitenaufruf, danach kommt das CSS eh aus dem Cache).
Der Flaschenhals liegt dann woanders und wenn die Inhalte so uninteressant sind, dass du beim Übertragen ein halbes Sekündchen sparen musst, um die Besucher zu halten …
Speed is a feature!
Ein halbes Sekündchen dauert das zum Glück nicht. Das wäre eine Katastrophe - du hast nur ein bis drei Sekunden INSGESAMT, bevor dir die Besucher weglaufen (zwei Sekunden musst du für den Verbindungsaufbau in mobilen Netzen einplanen, nach drei bis 5 Sekunden sind 50% Deiner Besucher futsch - nach dem verlinkten Artikel. Auf anderen Seiten habe ich schon von 3 Sekunden gehört, das heßt, da bleibt dir nur eine Sekunde um Deine Seite auf den Handy-Bildschirm zu bringen)! Die Bersucher, die verschwinden wissen ja nicht, was für tolle Inhalte du hast und werden es nie erfahren, weil die meisten auch nicht wiederkommen.
Auch Google belohnt schnelle Webseiten. Auch die Leute, die dich bei google nciht finden, wissen ncihts von Deinen Inhalten. Um nur zwei Gründe zu nennen. ;-)
Marc
Hallo
Vielleicht sollen auch alle Daten so schnell wie möglich zur Verfügung stehen, wenn sie gebraucht werden – manche Browser laden ja sogar ganze Webseiten noch bevor sie überhaupt aufgerufen werden, einfach auf Verdacht hin.
Aber hier besteht kein Grund für einen Verdacht - die Styles werden per media="print" ja ausdrücklich als irrelevant für die Bildschirm-Darstellung gekennzeichnet.
Es sollte aber für den zugegebenermaßen nicht sehr wahrscheinlichen Fall des Drucks der Seite ohne weitere Ladeverzögerung, also sofort funktionieren. Also muss es dann auch schon geladen sein.
Macht es Sinn, die print.css aus Performance-Gründen am Seitenende einzubinden
Sowas hängt immer von der Seite ab. Was hast du davon, ein Element, das nur 1% des Gesamtvolumens der Seite ausmacht, zuletzt zu laden?
1% und einen HTTP-Request weniger VOR dem Laden der eigentlichen Inhalte. Außerdem kann das auf gut gemachten Seiten schon mehr sein (beim ersten Seitenaufruf, danach kommt das CSS eh aus dem Cache).
Wieviel mehr als 1% vermutest du hinter einem Druck-CSS?
Speed is a feature!
Unbestritten.
Ein halbes Sekündchen dauert das zum Glück nicht. Das wäre eine Katastrophe - du hast nur ein bis drei Sekunden INSGESAMT, bevor dir die Besucher weglaufen
Sagt wer? Ich sehe einen recht kurzen Blogeintrag, der einen längeren über die unbestrittenen(!) Vorteile kürzerer Ladezeiten ankündigt, eine Grafik, die sich auf zwei Quellen bezieht [1] und das Postulat von „Facts and Stats“, die man doch bitte selbst per Twitter verbreiten soll. Letzteres stinkt mMn danach, diese „Facts and Stats“ erst durch das Twittern zu dem zu machen, was sie behaupten, schon zu sein.
Davon abgesehen scheint es mir irgendwie realitätsfern, von Ladezeiten von unter drei Sekunden zu reden, wenn mittlerweile sehr viele Websites JS-Bibliotheken, Fonts, zusätzliche CSS-Dateien, Multimedia-Klimbim etc. pp. aus teilweise -zig Quellen laden und nachladen [2]. Angeblich ist die durchschnittliche Page mittlerweile größer als ein Doom-Installationsmedium von 1993 (2,2MB). Als Benutzer eines Mobilgeräts muss man in unseren Mobilfunknetzen ja schon froh sein, wenn man da Ladezeiten von unter 10 Sekunden hinbekommt.
Dass man, wenn der Autor sich Mühe gegeben hat, schon weit vor dem Ablauf der von mir in den Raum gestellten 10 Sekunden schon etwas zu sehen bekommt, trifft zu. Mir ist es in einer solchen Situation aber nicht selten passiert, dass die Seite bis zum Ablauf der 10 Sekunden nicht bedienbar war, weil praktisch alle Funktionen, die per HTML hätten bereitgestellt werden können, mit den letzten Schnipseln JavaScript, das geladen wurden, implementiert waren.
In solch einem Moment interessiert es mich kein bisschen, dass ich schon früh etwas von der Seite gesehen habe. Wenn ich sie erst so viel später habe benutzen können, war im Zweifelsfall das der Grund, die Seite zukünftig zu meiden.
Sich an der Stelle über die vermutlich ein paar hundert Bytes eines Druck-CSS Gedanken zu machen, setzt mMn an der falschen Stelle an.
Auch Google belohnt schnelle Webseiten. Auch die Leute, die dich bei google nciht finden, wissen ncihts von Deinen Inhalten.
Interessant ist mMn der Weg, den Google in dieser Hinsicht einschlagen will. Einerseits ist es mMn begrüßenswert, schlanke Seiten zu belohnen. Andererseits stellt Google dazu unter Anderem eine Technik namens AMP [3] bereit, für deren Nutzung, die Autoren/Websitebetreiber zusätzliche Elemente in ihre Seiten einbauen und JS-Code [4] von Google nachladen müssen, was zusätzlichen Traffic verursacht. Weiteren Traffic verursacht die zur Auswertung dieser Elemente notwendige Verbindungsaufnahme mit Google, was ihnen, bei entsprechender Verbreitung auf Websites, zudem eine ständige Verfolgung der Internetbenutzer ermöglicht. und als letztes kommt noch hinzu, dass diese AMP-Seite der mobiloptimierte Spiegel einer echten™ HTML-Seite ist, woraus sich die Notwendigkeit für ein Meta Canonical ergibt, um Duplicated Content zu vermeiden. Das alles ist mMn nicht begrüßenswert.
Tschö, Auge
Die Quellen werden in der Grafik zwar genannt, allerdings nur mit deren Domainnamen. Was dort geschrieben wurde und ob das mit den in der Grafik aufgezeigten Schlussfolgerungen übereinstimmt, können wir mit den Angaben nicht überprüfen. ↩︎
Die Unterscheidung zwischen laden und nachladen beziehe ich auf den Zeitpunkt des Ladens im Ladeprozess der ganzen Seite. ↩︎
Ist wohl nach nicht ausgereift, aber das wird schon. ↩︎
Im April 2016 waren das laut einem Blogeintrag bei fefe satte 176884 Bytes. ↩︎
Hej Auge,
danke für deinen Input!
Ein halbes Sekündchen dauert das zum Glück nicht. Das wäre eine Katastrophe - du hast nur ein bis drei Sekunden INSGESAMT, bevor dir die Besucher weglaufen
Sagt wer? Ich sehe einen recht kurzen Blogeintrag, der einen längeren über die unbestrittenen(!) Vorteile kürzerer Ladezeiten ankündigt, eine Grafik, die sich auf zwei Quellen bezieht [^1] und das Postulat von „Facts and Stats“, die man doch bitte selbst per Twitter verbreiten soll. Letzteres stinkt mMn danach, diese „Facts and Stats“ erst durch das Twittern zu dem zu machen, was sie behaupten, schon zu sein.
Vielleicht war ich da zu gutgläubig. Passte aber zu anderen Zahlen, die ich häufiger gesehen habe. Werde da in Zukunft genauer hinschauen. Die hier und heute von mir verlinkte Quelle hat ja auch ein naheliegendes Interesse an Speed Optimization-Panik...
Auch Google belohnt schnelle Webseiten. Auch die Leute, die dich bei google nciht finden, wissen ncihts von Deinen Inhalten.
Interessant ist mMn der Weg, den Google in dieser Hinsicht einschlagen will. Einerseits ist es mMn begrüßenswert, schlanke Seiten zu belohnen. Andererseits stellt Google dazu unter Anderem eine Technik namens AMP [^3] bereit, für deren Nutzung, die Autoren/Websitebetreiber zusätzliche Elemente in ihre Seiten einbauen und JS-Code [^4] von Google nachladen müssen, [...] Das alles ist mMn nicht begrüßenswert.
Da gebe ich Dir unbedingt recht. Facebook hat ja was ganz ähnliches am Start mit den instant news oder wie das heißt - sicherlich auch mit ähnlicher Intention wie Google... :-(
Marc
Hallo
danke für deinen Input!
Ein halbes Sekündchen dauert das zum Glück nicht. Das wäre eine Katastrophe - du hast nur ein bis drei Sekunden INSGESAMT, bevor dir die Besucher weglaufen
Sagt wer? …
Vielleicht war ich da zu gutgläubig. Passte aber zu anderen Zahlen, die ich häufiger gesehen habe.
Die grundsätzliche Richtung des Blogartikels stimmt ja auch. Wenn es zu lange dauert, bis ich als Nutzer etwas zu sehen bekomme, gehe ich von einem Defekt der Seite oder davon, dass sie schnarchlangsam ist. Als technischer Autor einer Seite sollte man ein natürliche Interesse daran haben, die Ladezeiten kurz zu halten. Die dort genannten Zahlen halte ich allerdings für fragwürdig.
Werde da in Zukunft genauer hinschauen.
Es wird jedem von uns immer wieder passieren, auf irgendwas hereinzufallen. :-)
Die hier und heute von mir verlinkte Quelle hat ja auch ein naheliegendes Interesse an Speed Optimization-Panik...
Klar, das ist ein Teil ihres Geschäfts. Selbst wenn du selber schon Optimierungen durchgeführt hast, wirst du – aus deren Blickwinkel heraus hoffentlich – weitere Maßnahmen von ihnen kaufen, wenn du deren Benchmarks nicht erfüllst.
Auch Google belohnt schnelle Webseiten. Auch die Leute, die dich bei google nciht finden, wissen ncihts von Deinen Inhalten.
Interessant ist mMn der Weg, den Google in dieser Hinsicht einschlagen will. … AMP …
Da gebe ich Dir unbedingt recht. Facebook hat ja was ganz ähnliches am Start mit den instant news oder wie das heißt - sicherlich auch mit ähnlicher Intention wie Google... :-(
Dabei könnte es so einfach sein, den Durchschnitt der Ladezeiten zu drücken. Wenn man als Betrieber denn fähige Leute an die Aufgabe lassen und auch bezahlen wollte. Da das in den Augen vieler Auftraggeber aber nur unnötige Mehrarbeit ist, wird das wohl nichts. Dass – wie der Blogeintrag zu „Webseiten im Durchschnitt so groß wie DOOM“ ausführt – die Seiten/Portale mit den größten Zugriffszahlen ihre Strukturen optimieren, um die Ladezeiten zu drücken, ist zwar schön und gut, wenn es alle anderen lassen, weil sich die Vorteile der Optimierung nicht herumsprechen, werden wir im Durchschnitt nicht mal in die Nähe der drei Sekunden kommen.
Tschö, Auge