CSS Bewertung (Seite 2)

dbosen schrieb:

Jetzt würde ich sagen, das alles passt.

Nicht unbedingt. Es scheint alles zu klappen, solange die geprüfte Datei eine Domain ist. Ist es eine Datei aus einem Unterverzeichnis werden die Dateigrößen nicht addiert bzw. gar nicht angezeigt. Beispiel:

finistere-ferienhaus.de

finistere-ferienhaus.de/haus/index.html

piratos schrieb:

Fazit:
es sind noch eine Menge mit dem alten IE 6 unterwegs und der bockt.

Was seit XP-Service Pack 2 behoben ist

piratos schrieb:

Shared Webserver bieten in der Regel keine Komprimierung an und das trifft bis auf die 4 te Kommastelle 99,9999 % aller Domains zu.

Man kann aber eine Menge sparen wenn man z.B. via PHP überflüssige Leerzeichen und Zeilenvorschübe aus dem html entfernt wie auch aus der css.

Die Ersparnis ist im Verhältnis zum Serveraufwand und den Gesamtinhalten die nicht komprimierungsfähig sind nicht berauschend.

So mache ich das z.B. bei powercms.org (Das ist CMS Standard).

Bei der CSS würde man in dem Zustand durch Komprimierung kaum etwas sparen.

Es ging mir nicht darum die komprimierung als "gut" oder "schlecht" zu bewerten, das halte ich auch für schwierig, da es von Fall zu Fall verschieden ist (Server leistung vs bandbreite). Ich meine nur, wenn man das Datentransfervolumen angibt, dann muss man auch die tatsächlich übertragenen daten angeben, und die sind dann im falle einer Komprimierung entsprechend besser.
Im Falle des von der angesprochenen powercms.org Homepage:
css ungezipped: ca 13kb
css gezipped: ca 3kb
html ungezipped: ca 19kb
html gezipped: ca 6kb

Gesamt zipped vs. ungezipped: 32 : 9

Da ist es falsch zu sagen das Datentransfervolumen beträgt 32kb (wäre powercms.org gezipped gewesen)

Wie gesagt, es geht mir nicht darum, ob zippen besser ist, als nicht!

Das ist mir schon klar - ohne Zweifel wird das Volumen immer kleiner sein, grundsätzlich und einfach betrachtet hast du natürlich Recht.

Nur im Zweifelsfalle wäre das ein ziemlicher Aufwand , denn dann müsste man auch einen Lastfaktor für die Komprimierung auf dem Server selbst und für das Gegenstück auf der Empfängerseite berechnen - was praktisch für Seitenreport unmöglich wäre.

Es entsteht ja ein zusätzlicher Aufwand und wenn wir über Transferleistungreden müssen wir den sehen , wie in einer Gewinn und Verlustrechnung.

Gewinn = weniger Daten, Verlust Aufbereitungszeiten.

Und dann müsste man auch die Netzanbindung des Besuchers sehen.

Nehmen wir mal das bereits erwähnte Beispiel.

Ersparnis 23 KB.

Ich gehe mit echten 20 Mbit rein, das entspricht rund 2,5 MB pro Sekunde.

Wie reden über eine Zeit von 0,00092 Sekunden die ich benötige um 23KB zu empfangen.

Wir nutzen einen shared Webserver mit rund 100 Domains und könnten auch gzip verwenden.

Da wir die Generierungszeiten ermitteln und wegen der verwendeten Programmierung kann ich sagen das eine Komprimierung im Schnitt mehr als 0.004 Sekunden kostet (ich bin was Generierungszeiten betrifft ein ausgesprochener Geizhals, deswegen checke ich so etwas).

Das bedeutet - in der Zeit in der man komprimiert könnte ich unkomprimiert mehr als das 4 fache an Daten schicken.

Also im Klartext wäre für mich eine Komprimierung eine ganz dicke Abwertung, da der Verlust größer ist als der Nutzen.

Es macht auch relativ wenig Sinn einen Vorteil für den Seitenbetreiber zu sehen (wegen Traffic).

Eine Stressimulation bei nur 100 gleichzeitige anwesenden Besuchern die alle zufällige Seiten im Wechsel bei Zeitintervallen von 2 Sekunden (ist ja ein Stresstest) geht die Leistung eines guten Webservers und das exklusiv derart runter, das die Verluste gewaltig werden - von einem Nutzen für den Betreiber und den Besucher kann man in keinster Weise reden - genau das Gegenteil ist der Fall.

Wenn ich an den Text des Tooltips denke "Niemand möchte lange warten" geht die Komprimierung in so gut wie allen Fällen nach hinten los.

Wenn ich dazu bedenke, das in fast allen Fällen Bestandteile (Images) die nicht komprimierungsfähig sind im größeren Umfang enthalten sind als der komprimierbare Teil, kann man das in der Bewertung so einfach lassen, denn die wenigsten der über 200 Mio., Domains in der Welt nutzen es.

Das was du schreibst wollte ich gar nicht diskutieren. Ich wollte nur aufzeigen, dass es falsch ist das Datentransfervolumen auszuweisen, und dann aber die unkomprimierten Dateigrößen auszuwerten. Das ist bei Seiten, die ihre Inhalte komprimiert ausgeben schlicht der falsche Wert. Also entweder das ganze nicht Transfervolumen nennen, sondern zB Dateigröße, oder das tatsächliche Transfervolumen angeben.

Und ich wollte nachweisen das es sinnvoll ist dabei zu bleiben wie es jetzt ist.

Ok, dann haben wir schlicht eine unterschiedliche Vorstellung davon, was Datentransfer ist

Was die Definition von Datentransfer betrifft sind wir sicher einer Meinung.

Hier jedoch geht es um diese Frage:

Größe der HTML inklusive eingebettetem CSS und JavaScript. Niemand möchte lange warten, bis eine Homepage geladen ist. Achten Sie darauf, dass Ihre (X)HTML-Datei nicht größer wird als 30 KByte.

und damit auch letzten Endes darum ob man Teufel mit Belzebub bewertet, denn es geht schlichtweg um Zeitgewinn.

Also kann man nicht eine komprimierte Ãœbetragung positiv bewerten, wenn man im Backend den Gewinn nicht nur verpulvert hat sondern auch noch einen Zeitverlust erzeugt und zwar nicht nur für den einen sondern für alle Besucher und dazu noch mit dem Wissen - je mehr desto negativer.

Da sich die Frage bei der Mehrzahl von über 200 Mio Domains nicht stellt, kann man es ruhig so lassen, da man das auch vergleichen kann.

Der Seitenreport wird natürlich in absehbarer Zeit eine komprimierte Ãœbertragung (GZIP) erkennen und in den Analysen anzeigen.

Ich denke schon, dass in der Analyse "Größe der HTML-Datei" die tatsächlich übertragene Größe angezeigt werden sollte, also im Falle der Komprimimierung eine kleinere Dateigröße als derzeit.

Ein etwaiger langsamerer Seitenaufbau wird der Fairness halber dann in einer anderen (neuen) Analyse wieder abgewertet ("Zugriffszeit/Ping" o.ä.).

Insgesamt sollte eine mit GZIP komprimierte Webseite (meiner Meinung nach) schon schneller übertragen und angezeigt werden als eine nicht-komprimierte. Dies ist hier im Forum allerdings ein sehr kontrovers diskutiertes Thema :wink:

z.B. hier:

www.seitenreport.de/forum/beitraege/ideen_verbesserungsvorschlaege/gzip_komprimierung_testen.html

Man kann hier

www.gidnetwork.com/tools/gzip-test.php

Mir ist aufgefallen das einige kleine Sites offenbar auf Reaktion dieser Diskussion Komprimierung eingeschaltet haben und sich damit hier in der Liste ziemlich nach oben katapultiert haben.

Die Frage ist wirklich was denn das ganze Ranking hier noch soll wenn es nicht annähernd die Realität spiegelt.
Da wird dieser Report nicht nur unglaubwürdig sondern sogar lächerlich.
Jeder Profi der sich das näher ansieht würde das hier in die Ablage P werfen.

Wenn es nur eine Bewertung der Ausnutzung aller technischen Möglichkeiten ist dann ok, aber dann haben PR, Alexa und Yahoo hier nichts zu suchen.