Lohnt sich Dateikomprimierung?

[DiVaO]

Moinsen,

ich habe mal einen Versuch gemacht und mal getestet wie es sich mit der Dateigröße von .js, .html, .php und .css Dateien verhält, wenn man sämtliche Leerzeichen und Kommentare entfernt. Mein Ergebnis war, dass sich die Dateigröße auf ca. 70-80% reduziert.

Nun zu meiner Frage.. man ließt ja viel von Suchmaschinen Optimierung und wie wichtig das alles ist und da läuft einem auch öfters die Datei-Komprimierung als Stichwort über den Weg. Ich würde nun gerne wissen, ob sich das bei einer gut besuchten Seite lohnen würde, sämtliche Dateien zu komprimieren und damit wie oben beschrieben kleiner zu machen?

Was habt ihr da für Erfahrungen ?

Grüße

 

[mermshaus]

Ja! Die Auslieferungsgeschwindigkeit einer Seite ist ein ganz extrem wichtiger Faktor. Ich kann dich spontan auf keine offizielle Quelle verweisen, aber ich bin mir praktisch sicher, dass Suchmaschinen schnelle Seiten bevorzugen beziehungsweise eher umgekehrt langsame benachteiligen.

 

[sysop]

Sehe ich eigentlich auch so, wobei die Frage ist, ob man den Quellcode komprimiert oder z.B. die gzip-Komprimierung des Browsers verwendet.
Ich nutze meistens letzteres, was die Bereinigung des Codes fast hinfällig werden lässt.

 

[DiVaO]

Sehe ich eigentlich auch so, wobei die Frage ist, ob man den Quellcode komprimiert oder z.B. die gzip-Komprimierung des Browsers verwendet.
Ich nutze meistens letzteres, was die Bereinigung des Codes fast hinfällig werden lässt.

Das werd ich mir mal genauer anschauen

 

[FoXMorayn]

lohnt sich nicht. ist aber empfehlenswert. du kannst punkte im plugin pagespeed sammeln. in meinen augen sind das nur punkte und kein wirklicher faktor. problematisch wird es, wenn deine seite eine überdurchschnittliche ladezeit hat, oder google sogar wegen der langen ladezeit die indexierung unterlässt.

der gedanke, dass man durch komprimierung des codes mehr text in das ranking einfließen lassen kann, ist auch veraltet. angekommen google würde nur 200kb idexieren und der quellcode hätte 250kb: in dem fall macht es sinn. google zeigt aber eine vorschau der kompletten webseite, auch wenn diese 400kb hat.

 

[mermshaus]

lohnt sich nicht. ist aber empfehlenswert. du kannst punkte im plugin pagespeed sammeln. in meinen augen sind das nur punkte und kein wirklicher faktor. problematisch wird es, wenn deine seite eine überdurchschnittliche ladezeit hat, oder google sogar wegen der langen ladezeit die indexierung unterlässt.

Ja, wegen des letzten Arguments würde ich aber klar „lohnt sich definitiv“ sagen.

der gedanke, dass man durch komprimierung des codes mehr text in das ranking einfließen lassen kann, ist auch veraltet.

Den hatte hier auch niemand aufgebracht, oder? Ich meine, ist natürlich dennoch unter Umständen eine interessante Info.

Schnelle Ladezeiten sind eigentlich auch nichts, das nur Suchmaschinen nutzt, sondern tatsächlich auch normalen Besuchern.

Nach Möglichkeit sollte bei jeder Seite die automatische Komprimierung (gzip, deflate) aktiviert werden (in aller Regel eine simple serverseitige Einstellung). Ich habe etwa in einer .htaccess-Datei diese Regeln stehen (ehrlichgesagt auch nur kopiert, wirklich eingelesen habe ich mich da nie):

# GZIP compression
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

Ob's klappt, lässt sich etwa mit Page Speed testen.

Auch die Minifizierung von JavaScript und CSS kann nicht schaden, ich denke aber auch, dass generelle Kompression da den Löwenanteil ausmacht.

Der dritte Punkt wären ordentliche Cache-Header, damit ein Client Ressourcen überhaupt nicht nachfragen muss, wenn er sie im Cache stehen hat. Die sind aber etwas kniffliger zu setzen.

 

[FoXMorayn]

Der dritte Punkt wären ordentliche Cache-Header, damit ein Client Ressourcen überhaupt nicht nachfragen muss, wenn er sie im Cache stehen hat. Die sind aber etwas kniffliger zu setzen.

das interessiert mich auch noch sehr. suche schon länger eine automatische lösung dafür. idealerweise für wordpress.
auf der anderen seite möchte ich aber auch nicht alle bilder aus 3 monaten surfen auf meiner festplatte cachen.

vllt ein fehler von mir "lohnen" mit "besseres ranking -> mehr besucher -> mehr geld" gleich zu setzen.

 

[mermshaus]

vllt ein fehler von mir "lohnen" mit "besseres ranking -> mehr besucher -> mehr geld" gleich zu setzen.

Ach, vermutlich stimmt's, dass es da nicht auf ein paar Millisekunden ankommt. So gesehen passt das irgendwie schon.

Ich bin da einfach ein gebranntes Kind. Beispiel: Teile meiner Homepage haben bis vor einiger Zeit im Schnitt 5 Sekunden oder länger geladen, da ich einen Haufen ungecachter XML-Umformungen gemacht habe. Die entsprechenden Seiten sollten zwar per Robots-Einstellung überhaupt nicht indiziert werden (waren Übersichtsseiten, ich wollte nur die einzelnen Einträge im Index haben), aber ich glaube, das war der Grund, wieso ich praktisch nicht im Google-Index auftauchte (laut Webmaster Tools). Seit ich alle Inhalte vorberechne und cache (hatte vorher keine Zeit, das zu programmieren) und sich die Seiten in Millisekunden aufbauen, habe ich die 20-fache Anzahl indizierter Seiten.

Das ist zwar nur ein Fallbeispiel. Aber ich könnte mir schon denken, dass die Suchmaschine den Seitenbetreiber ab einer gewissen Ladezeit massiv abstraft. Die wird nicht bei 400 oder 500 oder meinetwegen gar 1200 ms liegen, aber Google-Bot hat auch noch andere Sachen zu tun. :)

das interessiert mich auch noch sehr. suche schon länger eine automatische lösung dafür. idealerweise für wordpress.

Ich bin da seit einiger Zeit an einem Konzept dran, sowas zu basteln. (Nicht für WordPress, das wird es aber auch schon fertig geben.) Falls ich da in absehbarer Zeit zu komme, was auf die Beine zu stellen, poste ich hier noch mal.

auf der anderen seite möchte ich aber auch nicht alle bilder aus 3 monaten surfen auf meiner festplatte cachen.

Das ist einfach Einstellungssache im Browser. Aus Server-/Seitenbetreibersicht willst du, dass möglichst wenig Daten übertragen werden. Ob der Nutzer seinen Browser (etwa die Cache-Größe) dann so einstellt, dass Ressourcen tatsächlich lokal gespeichert werden, ist nicht von dir beeinflussbar. Wenn der Browser eine Ressource nicht hat, lädt er sie so oder so neu.

 

[ladomat]

Grenznutzen

lohnt sich nicht. ist aber empfehlenswert. du kannst punkte im plugin pagespeed sammeln. in meinen augen sind das nur punkte und kein wirklicher faktor. problematisch wird es, wenn deine seite eine überdurchschnittliche ladezeit hat, oder google sogar wegen der langen ladezeit die indexierung unterlässt. der gedanke, dass man durch komprimierung des codes mehr text in das ranking einfließen lassen kann, ist auch veraltet. angekommen google würde nur 200kb idexieren und der quellcode hätte 250kb: in dem fall macht es sinn. google zeigt aber eine vorschau der kompletten webseite, auch wenn diese 400kb hat.

Mein Kenntnisstand sagt das gleiche. Und Wenn ich mir ansehe, wiw viele KB ,anche allein mit Design-Firlefanz verballern ... Tstststs. Wie wär´s denn mit einer ordentlihen Bild-Komrimierung? Bei einem mittelgroßen Bild kann man locker das doppelte rausholen, was einem die CSS-Optimierung bringt. Und überhaupt - eine reine HTML/CSS-Seite ohne Bilder noch zu komprimieren - das wäre wohl wirklich ein geradezu obszöner Fall von abnehmendem Grenznutzen!

 

[mermshaus]

Bilder werden aber gecachet. Gerade dann, wenn sie zum Rahmendesign einer Seite gehören, das auf jeder Unterseite gleich ist. Individueller HTML-Inhalt muss dagegen zwangsläufig immer neu übertragen werden.

Komprimierung von Textdaten einen „geradezu obszöne[n] Fall von abnehmendem Grenznutzen“ zu nennen, ist in meinen Augen absolut falsch.

Ich habe auf die Schnelle keine gesicherten Informationen dazu gefunden, aber ich würde tippen, dass sich die zu übertragende Text-Datenmenge oftmals um Faktor drei oder vier verringert. Das macht auch bei einer schnellen Verbindung locker 100 ms Wartezeit aus bei jedem ungecacheten Request. Das ist überaus signifikant.

 

[Degers]

Ist die gzip- Kompression per .htaccess gefahrlos anwendbar? Dann würde ich den Code mal guttenbergen.

 

[mermshaus]

Ja.* Für den hier geposteten Code hat mich aber kürzlich mal jemand gedisst.**

- ob_start("ob_gzhandler") - XHTMLforum

*) Ich glaube, ich setze ab jetzt einfach hinter alle „Angaben ohne Gewähr“ ein Sternchen, das ich nicht weiter erkläre. Das wird so super.
**) Habe ich das richtig gesagt? „Gedisst“?



Am Rande:

Wenn ihr für eine Seite wie diese die Seiteninformationen aufruft, steht da unter Größe etwas wie 17.3 KB.

Wenn ihr den Code anzeigen lasst und abspeichert, ergibt das eine Dateigröße von – gleich wieder da – 75.6 kB.

Denkt mal drüber nach.

 

[FoXMorayn]

<FilesMatch “\.(js|css|html|htm|php|xml)$”>
SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/plain text/xml
</FilesMatch>

wenn ich zum buss renne und vorher noch meinen rucksack packen muss, bin ich meist ne minute zu spät.... und wenn dann noch das bad besetzt ist..
bin mir auch nicht sicher ob apache die gzips cachen kann. außerdem würde ich als client schonmal das html verwerten, dass ich habe. vllt kann ich schon einen weiteren request senden.
aber google rät zu gzip und die haben schließlich nen verdammt schnellen browser programmiert.

gefühlt ist es mir egal ob gzip oder nicht. wenn ich irgendwelche erratenen zahlen zusammenwürfel, gibs allerdings nen plus fürs gzip. für seo immer noch egal.

 

[mermshaus]

Komprimierte Übertragung ist zudem sinnvoll zur Vermeidung des Falls „schneller Rechner an langsamer Verbindung“. „Langsamer Rechner an schneller Verbindung“ dürfte wohl eher selten auftreten.

wenn ich irgendwelche erratenen zahlen zusammenwürfel, gibs allerdings nen plus fürs gzip.

Gegen solche Aussagen kann und sollte man nicht argumentieren. Das ist reine Zeitverschwendung. Ich bin raus.

 

[FoXMorayn]

Komprimierte Übertragung ist zudem sinnvoll zur Vermeidung des Falls „schneller Rechner an langsamer Verbindung“. „Langsamer Rechner an schneller Verbindung“ dürfte wohl eher selten auftreten.
Gegen solche Aussagen kann und sollte man nicht argumentieren. Das ist reine Zeitverschwendung. Ich bin raus.

bin ja schon diese abwürger gewöhnt^^ geb mir trotzdem mühe den gedanken dahinter zu konkretisieren: du möchtest dagegen argumentieren..., du musst es öffentlich machen..., du hast keine argumente... genau! weil wir keine zahlen haben sondern immernoch drauf los raten. ich kann erfahrungswerte liefern, aber keine fakten über messungen für die performance von gzip. auch wenn ich das könnte, liefern unterschiedliche server eine unterschiedliche performance. ich habe von unterschiedlichsten messungen gelesen: so ist auf dem einem server funktion x schneller und auf dem anderen funktion y (php array funktionen).

rein nach dem bauchgefühl würde man sagen, dass 20kg schneller am boden ankommen als 10kg!

internet auf dem handy hat z.b. einen extrem langsamen ping, dazu kann eine langsame datenverbindung kommen, oder der normale durchsatz von 500kb/s für aktuelle datentarife. empfängt das handy jetzt den header, kann es parallel die css datei anfordern. wird gzip verwendet muss zuerst die erste seite vollständig geladen werden um an den header zu gelangen. was hier schneller ist kann ich erstmal nur erraten. (das ist ein theoretisches beispiel. ob der browser die requests so verarbeitet, kann ich auch nur erraten) 50ms oder 400ms ping * 2, wieviel schneller ist gzip?
ein ähnliches prinzip beim interlacing von bildern. wenn ich mich nicht irre verwendet facebook diese technik, obwohl es mehr datendurchsatz erzeugt.

hier nochmal ein beispiel für eine bemerkenswerte komprimierung die sich bei langsamen verbindungen wirklich lohnt: opera für android liefert ein proxy mit, welches die daten, inkl. bilder, komprimiert. der request geht an den proxy server, dieser ruft die daten von der webseite ab und komprimiert wirklich alle daten erheblich. danach geht das ganze zurück auf das handy. in der ubahn merkt man das sehr.

 

[sysop]

.....
gefühlt ist es mir egal ob gzip oder nicht. wenn ich irgendwelche erratenen zahlen zusammenwürfel, gibs allerdings nen plus fürs gzip. für seo immer noch egal.

Dagegen kann man ja auch nicht argumentieren, das steht im Raum und bewegt sich nicht mehr weg.

gzip zahlt sich bei dynamischen Seiten immer aus und sei es nur, den Cache zu aktualisieren. Genau der macht das Messen auch nicht einfach. Mal greift man auf den Cache zu mal nicht. Bemerken würde man gzip massiv wenn man ohne Cache arbeitet.
Ich habe immer einen Schalter um gzip ein/aus zu schalten.
Das sind dann auch keine gefühlten Informationen, die kann man messen, indem man die Auslieferungszeit berechnet.

 

[igestalten]

Da das hier die SEO Abteilung ist, lasse ich die technischen Aspekte mal beiseite.

Page Speed ist defiinitiv ein SEO Faktor ( s. Google Pagespeed und Matt Cutts persönlich und inzwischen auch über Analytics einsehbar ) und das nicht erst seit kurzem.

Insofern "lohnt" sich Speed Optimierung (unter all den bisher aufgeführten Aspekten) auf jeden Fall!

 

[FoXMorayn]

60 von 100 ! die seite könnte schneller sein :mrgreen:

leider sieht man nicht viel. der grund sind fehlende angaben zum ablaufdatum von bildern.. daher meint pagespeed nur 60 punkte vergeben zu müssen. glanzleistung!

 

[ladomat]

it depends

die ladegeschwindigkeit ist EIN Faktor. Das sollte klar sein. Das hängt aber alles auch vom Aufbau Deiner Seite und anderen Optimierungspotentialen ab. Backlinks werden wohlmöglich mehr helfen und wenn ich mir anschaue, wie viele Bilder und Grafiken da teils schon für die Grundstruktur verballert werden, dann sind die wenigen KB, die durch Code-Kompression gewonnen werden können sicherlich nur ein Tropfen auf den heißen Stein. GZIP&Co zu nutzen ist allerdings recht einfach, den Code etwas zu koprimieren ebenfalls. Einige Kommentare würde ich aber nie löschen, das ist es nicht wert, insb. auch da ich ständig an meiner Seite arbeite. Kennst Du schon Nibbler - take a taste of your website ?