Frage zum Wiki-Artikel ‚Print-CSS‘

[Auge]

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

---

1. 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. ↩︎

2. Die Unterscheidung zwischen laden und nachladen beziehe ich auf den Zeitpunkt des Ladens im Ladeprozess der ganzen Seite. ↩︎

3. Ist wohl nach nicht ausgereift, aber das wird schon. ↩︎

4. Im April 2016 waren das laut einem Blogeintrag bei fefe satte 176884 Bytes. ↩︎