nicht angemeldet
HTML 'komprimieren'
0 0 0 Warum nicht gzip-Komprimierung bei HTTP verwenden?
0 0 0 0
HTML 'komprimieren'
Hallo Leute,
mittlerweile gibt es HTML-'Komprimierer' wie Sand am Meer. Diese ersetzen bestimmte Teile einer HTML-Datei mit mehr oder minder äquivalenten, jedoch platzsparenderen Teilen und erzielen somit eine Reduzierung der Dateigröße.
Somit müsste rein rechnerisch der Upload auf den FTP sowie der Download in den Browser flotter vonstatten gehen.
Und wenn man nicht die Originaldatei 'komprimiert', sondern nur eine Kopie dessen, die kurz danach auf den FTP hochgeladen wird, dürfte auch das Bearbeiten des (Original-)HTML nicht darunter leiden.
Was haltet Ihr von solchen Programmen? Gefährlicher Humbug oder nützliche Tools?
Auf Eure Meinung gespannt ... Peter
-
Ich halte von solchen Progs garnix.
Die bearbeiten dir den Quelltext ja echt so dasten nimmer lesen
kannst.
Ich halt mir meine HTML Dateien selber klein und des reicht mir.
Grüße aus Nürnberg
Julius-
also wenn man wirklich die alte version noch behält und nur zum hochladen bearbeitet ne super erfindung, aber auf der platte würd ichnciht mit komprimierten dateien arbeiten wollen...
-
also wenn man wirklich die alte version noch behält und nur zum hochladen bearbeitet ne super erfindung, aber auf der platte würd ichnciht mit komprimierten dateien arbeiten wollen...
Vergiss auch keine möglichen Headcrashs oder Datenverluste durch Viren, in solchen Fällen liegt die unkomprimierte HP noch auf dem Server und du kannst sie zurück bekommen.
Falls du mal Fragen zu Problemen im Quelltext haben solltest wirst du bestimmt nicht mit offenen Armen empfangen, wenn man den koprimierten Matsch lesen soll.
York
-
-
Und wenn man nicht die Originaldatei 'komprimiert', sondern nur
eine Kopie dessen, die kurz danach auf den FTP hochgeladen wird,
dürfte auch das Bearbeiten des (Original-)HTML nicht darunter
leiden.Ich halte von solchen Progs garnix.
Die bearbeiten dir den Quelltext ja echt so dasten nimmer lesen
kannst.mmmh? Von Komprimierung der Originaldatei war ja auch nicht die Rede.
Grüße ... Peter
-
-
Hi
ersetzen bestimmte Teile einer HTML-Datei mit mehr oder minder äquivalenten, jedoch platzsparenderen Teilen und erzielen somit eine Reduzierung der Dateigröße.
Stimmt, MEHR ODER MINDER und eben nur das, es passiert ganz oft, dass eine HTML-Seite nach dem Komprimieren in jedem oder nur in einigen Browsern nichts mehr mit dem Original zu tun haben und das halte ich nicht für anstrebenswert.
Somit müsste rein rechnerisch der Upload auf den FTP sowie der Download in den Browser flotter vonstatten gehen.
Da lade ich lieber zwei Sek mehr rauf oder runter, als dass die Datei nachher nur noch im IE oder nur im Opera läuft. Es mag gute komprimierer geben, aber ich habe noch keinen gefunden.
Und wenn man nicht die Originaldatei 'komprimiert', sondern nur eine Kopie dessen, die kurz danach auf den FTP hochgeladen wird, dürfte auch das Bearbeiten des (Original-)HTML nicht darunter leiden.
Das ist die Grundvorraussetzung, denn sonnst wirst du nichts mehr ändern, sondern alles neu machen müssen.
Was haltet Ihr von solchen Programmen? Gefährlicher Humbug oder nützliche Tools?
HUMBUG
Gruß York
-
Hallo York,
ersetzen bestimmte Teile einer HTML-Datei mit mehr oder minder
äquivalenten, jedoch platzsparenderen Teilen und erzielen somit
eine Reduzierung der Dateigröße.Stimmt, MEHR ODER MINDER und eben nur das, es passiert ganz oft,
dass eine HTML-Seite nach dem Komprimieren in jedem oder nur in
einigen Browsern nichts mehr mit dem Original zu tun haben und das
halte ich nicht für anstrebenswert.Das wäre ein Argument...
Was haltet Ihr von solchen Programmen? Gefährlicher Humbug oder
nützliche Tools?HUMBUG
Danke für Deine Meinung & Grüße ... Peter
-
-
Hallo Peter,
Was haltet Ihr von solchen Programmen? Gefährlicher Humbug oder nützliche Tools?
Humbug. Der Sourcecode ist danach auch meist nicht mehr valide und macht den Browsern dadurch zu schaffen - denn diese müssen raten, wie etwas gemeint war.
Aber: Es gibt eine Möglichkeit, die Seiten on-the-fly bei jedem Übertragen zu komprimieren, wenn ein Browser, der das versteht, (recht viele) das anfordert.
Du solltest Dir vielleicht mal http://www.schroepl.net/projekte/gzip_cnc/ und http://www.schroepl.net/projekte/mod_gzip/ zu Gemüte führen. Das SELFForum wird auch komprimiert ausgeliefert. Die Hauptdatei ist an sich knapp 300 KB groß, transferiert werden aber nur 31 KB oder so. Der Quelltext der Datei wird nicht angefasst.
Christian
--
Ich bitte darum, dass ein Themenbereich (BARRIEREFREIHEIT) eingerichtet wird. -
Hallo,
seltens eine html-Seite gesehen, die aufgrund der Quantität der html-Tags zu fett ist. Das Problem sind eher die Grafiken und eingebundeneden Objekte. Wenn eine html-Seite aufgrund der html-Tags zu fett ist, dann stimmt schon etwas mit dem Konzept nicht. (gebe aber zu, daß ich eine Seite (von hunderten allerdings) "im Programm" habe, die in der Tat sehr html-mächtig ist ;-))
Chräcker
-
Hallo!
seltens eine html-Seite gesehen, die aufgrund der Quantität der html-Tags zu fett ist.
Doch, ich kenne eine Die Du vermutlich auch gut kennst: http://forum.de.selfhtml.org/ *SCNR*
Grüße
Andreas
-
-
Moin!
mittlerweile gibt es HTML-'Komprimierer' wie Sand am Meer. Diese ersetzen bestimmte Teile einer HTML-Datei mit mehr oder minder äquivalenten, jedoch platzsparenderen Teilen und erzielen somit eine Reduzierung der Dateigröße.
Ja, stimmt, aber der erzielte Gewinn ist praktisch nahe Null. Es gibt bessere Methoden, die Auslieferung der HTML-Dateien komprimiert zu beschleunigen.
Auf diesem Server wird die beste Methode angewandt: Komprimierung der Datei durch gzip, sofern der Browser die Seite (nach seinen eigenen Angaben) wieder dekomprimieren kann. Damit werden traumhafte Komprimierungsraten von bis zu 90% erreicht. Vergleiche doch einfach mal die zu ladende Datenmenge der Forumsstartseite mit der wirklichen HTML-Datenmenge. Du lädst so um die 30 KB, die Datei selbst ist aber weit über 200 KB groß.
Als Möglichkeiten für solch eine Wunderwaffe stehen dir zur Verfügung:
1. mod_gzip (wie auf diesem Server eingesetzt) (http://www.schroepl.net/projekte/mod_gzip/). mod_gzip muß vom Apache-Administrator eingebaut werden, dann kann es aber so ziemlich jeden Content, egal ob statisch oder dynamisch, komprimieren.2. gzip_cnc (http://www.schroepl.net/projekte/gzip_cnc/) - ein Content-Handler für statischen Inhalt, realisiert als Perl-Skript. Erfordert, dass du Perl ausführen darfst, kann aber unter Umständen (sofern du das in .htaccess-Dateien einstellen darfst) von dir selbst installiert und aktiviert werden.
3. PHPs ob_gzhandler (http://www.php.net/manual/en/function.ob-gzhandler.php) hilft dir, komprimierten dynamischen Content von PHP zu erzeugen, sofern mod_gzip nicht zur Verfügung steht.
4. Wenn alles nichts hilft, kannst du immer noch die Möglichkeiten von Apache ausnutzen, die er in fast allen Installationen hat: Multiviews für statische Seiten. Das erfordert, dass du jeweils immer zwei Dateiversionen auf den Server packst, eine normale (z.B. seite.html) und eine komprimierte (seite.html.gz), und deine Links dann nur auf href="seite" zeigen - Apache findet dann automatisch (bei korrekter Einstellung der Multiviews) die richtige Datei.
Was haltet Ihr von solchen Programmen? Gefährlicher Humbug oder nützliche Tools?
Zeilenumbrüche und Leerzeichen sind in HTML-Dateien nicht unbedingt nur zum Spaß da. Gerade in Tabellenzellen haben sie unter Umständen eine wichtige Bedeutung, die man nicht einfach wegkomprimieren kann.
Ich würde mod_gzip einsetzen, wo immer es geht.
- Sven Rautenberg
--
"Bei einer Geschichte gibt es immer vier Seiten: Deine Seite, ihre Seite, die Wahrheit und das, was wirklich passiert ist." (Rousseau)-
Hallo,
- Wenn alles nichts hilft, kannst du immer noch die Möglichkeiten von Apache ausnutzen, die er in fast allen Installationen hat: Multiviews für statische Seiten. Das erfordert, dass du jeweils immer zwei Dateiversionen auf den Server packst, eine normale (z.B. seite.html) und eine komprimierte (seite.html.gz), und deine Links dann nur auf href="seite" zeigen - Apache findet dann automatisch (bei korrekter Einstellung der Multiviews) die richtige Datei.
heißt das, dass das auch geht, wenn ich keine eigenen CGI Scripte auf meinem (Apache-)Server laufen lassen kann?
Brauch ich dann nur gzip_cnc?
Das wär ja Klasse.
Und die zwei Versionen auf dem Server hätten zudem noch den Vorteil, dass im schlimmsten Fall noch meine htmls auf dem Server liegen.Danke für Antwort
Fritz-
Moin!
- Wenn alles nichts hilft, kannst du immer noch die Möglichkeiten von Apache ausnutzen, die er in fast allen Installationen hat: Multiviews für statische Seiten. Das erfordert, dass du jeweils immer zwei Dateiversionen auf den Server packst, eine normale (z.B. seite.html) und eine komprimierte (seite.html.gz), und deine Links dann nur auf href="seite" zeigen - Apache findet dann automatisch (bei korrekter Einstellung der Multiviews) die richtige Datei.
heißt das, dass das auch geht, wenn ich keine eigenen CGI Scripte auf meinem (Apache-)Server laufen lassen kann?
Richtig, Variante 4 (Multiviews) geht ohne irgendwelche aktiven Komponenten - allerdings nur, wenn du Multiviews aktiviert hast oder aktivieren kannst. Bei Puretec ist das z.B. der Fall.
Brauch ich dann nur gzip_cnc?
Nein, du brauchst gzip, um die Dateien zu komprimieren. gzip ist bitte nicht mit ZIP zu verwechseln - das Datenformat ist unterschiedlich.
Auf Unix-Maschinen sollte das gzip-Tool schon installiert sein (ansonsten http://www.gzip.org besuchen), für Windows hab' ich mit Google folgende Seite gefunden: http://www.nodc.noaa.gov/woce_V2/disk01/utils/gzip/windows/index.htm. Bedenke: gzip ist ein Kommandozeilentool, nicht klicki-bunti, die Anwendung ist aber ziemlich leicht:
"gzip dateiname" komprimiert die angegebene Datei - allerdings ist die Originaldatei danach verschwunden, was in vielen Fällen durchaus erwünscht ist.
"gzip -9 -c dateiname > dateiname.gz" ist besser, die Originaldatei bleibt erhalten. Außerdem sorgt der Parameter "-9" für maximale Komprimierung.Wie du die Multiviews einstellst, steht u.a. (allerdings für Sprachvarianten - ist im Prinzip dasselbe) in http://aktuell.de.selfhtml.org/artikel/server/alt-http/index.htm#a5.
- Sven Rautenberg
--
"Bei einer Geschichte gibt es immer vier Seiten: Deine Seite, ihre Seite, die Wahrheit und das, was wirklich passiert ist." (Rousseau)-
Hallo Sven,
- Wenn alles nichts hilft, kannst du immer noch die Möglichkeiten von Apache ausnutzen, die er in fast allen Installationen hat: Multiviews für statische Seitenseite" ...
danke für die Hilfe. Hab mir gzip geholt, und die erste Datei "ge-gzipt" und auf den Server hochgeladen.
Leider ist mein Provider (Strato) mit Auskünften recht zähflüssig.
Daher noch eine Frage:
(Wie) kann ich feststellen, ob die datei.html.gz verwendet wird?
Cache löschen und Ladezeit mit der Stoppuhr festhalten kanns ja nicht sein.Gruß vom Chiemsee
Fritz-
(Wie) kann ich feststellen, ob die datei.html.gz verwendet wird?
Cache löschen und Ladezeit mit der Stoppuhr festhalten kanns ja nicht sein.telnet öffnen, eine Verbindung mit einem Webserver, Anschluss 80, herstellen und beispielsweise
HEAD /programm/film HTTP/1.0
Host: kino-fahrplan.de
Accept-Encoding: gzipeingeben. Dann kommt folgendes in der Art zurück:
HTTP/1.1 200 OK
Date: Mon, 27 Jan 2003 11:47:55 GMT
Content-Location: film.html.gz
Vary: negotiate,accept-encoding
[..]
Content-Length: 4645
Content-Type: text/html; charset=iso-8859-15
Content-Encoding: gzipDas gzip zum Übertragen benutzt wird, erkennst Du an der Zeile Content-Encoding. Die im Beispiel benutzte Datei ist im Original übrigens 64532 Bytes groß, die komprimierte Variante belegt also weniger als ein Zehntel, Komprimierungsrate über 90%.
Gruß,
soenk.e -
Moin!
(Wie) kann ich feststellen, ob die datei.html.gz verwendet wird?
Cache löschen und Ladezeit mit der Stoppuhr festhalten kanns ja nicht sein.Die zwei Dateien müssen ja nicht denselben Inhalt haben. :)
Du machst also eine "gzip-test.html" mit dem Text "Es wird keine Komprimierung verwendet", und du machst eine zweite Datei mit dem Text "Es wird gzip-Komprimierung verwendet", die du dann gzippst und umbenennst in "gzip-test.html.gz". Dann lädst du beide Dateien auf den Server und rufst die Seite "gzip-test" auf. Der erscheinende Text gibt dir dann Auskunft. ;)
- Sven Rautenberg
--
"Bei einer Geschichte gibt es immer vier Seiten: Deine Seite, ihre Seite, die Wahrheit und das, was wirklich passiert ist." (Rousseau)-
Hallo,
Die zwei Dateien müssen ja nicht denselben Inhalt haben. :)
verd.., da hätt ich auch drauf kommen können.
Gruß Fritz
-
Hallo,
Die zwei Dateien müssen ja nicht denselben Inhalt haben. :)
verd.., da hätt ich auch drauf kommen können.
jetzt weiß ich, dass mein Server das nicht tut :-( Ich krieg immer die "ungegzipte" Version.
Kann / muss ich da jetzt per .htaccess noch eingreifen.
Hab die entsprechenden Seiten in selfaktuell durchstöbert. Find mich aber leider nicht zurecht.
Kann mir bitte noch jemand weiterhelfen, wie der Eintrag in der .htaccess lauten muss. (wie schon erwähnt: von seiten Strato kommt leider keine Hilfe.)Gruß vom Chiemsee
Fritz-
Hi Fritz,
Kann mir bitte noch jemand weiterhelfen, wie der Eintrag in der .htaccess lauten muss.
http://httpd.apache.org/docs/mod/core.html#options
http://httpd.apache.org/docs/content-negotiation.html
http://aktuell.de.selfhtml.org/artikel/server/alt-http/(wie schon erwähnt: von seiten Strato kommt leider keine Hilfe.)
You get what you pay for.
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.-
Hallo Michael,
Kann mir bitte noch jemand weiterhelfen, wie der Eintrag in der .htaccess lauten muss.
hab folgende .htaccess probiert:
<Directory />
Options MultiViews
</Directory>und krieg leider einen internal Server Error.
Heißt das jetzt: Pech gehabt mit Strato?
Oder hab ich doch noch eine Chance?You get what you pay for.
wie wahr!
Grüsse vom Chiemsee
Fritz-
Moin!
hab folgende .htaccess probiert:
<Directory />
Options MultiViews
</Directory>und krieg leider einen internal Server Error.
Heißt das jetzt: Pech gehabt mit Strato?
Das würde ich so sehen.
Allerdings: <Directory> in einer .htaccess-Datei finde ich sehr seltsam, das kann für den Fehler auch verantwortlich sein. Einfach ein "Options Multiviews" sollte es tun - wenn es geht.
- Sven Rautenberg
--
"Bei einer Geschichte gibt es immer vier Seiten: Deine Seite, ihre Seite, die Wahrheit und das, was wirklich passiert ist." (Rousseau)-
Hi!
Allerdings: <Directory> in einer .htaccess-Datei finde ich sehr seltsam, das kann für den Fehler auch verantwortlich sein. Einfach ein "Options Multiviews" sollte es tun - wenn es geht.
Ich schlage
Options +Multiviews
vor. Ohne + werden saemtliche anderen Options abgeschaltet, mit dem + wird Multiviews zu den bestehenden Optionen hinzugefuegt.So long
--
Bier trinken fetzt!!!-
Hallo,
1. Options +Multiviews ist o.k., und geht lt. Strato Hotline auf dem Server.
2. die wollen aber ausserdem noch eine *.var Datei sehen. Aber das brauch ich doch nur, um z.B. mehrere Versionen (z.B. verschiedene Sprachen) anzubieten.
Mit *.gz Dateien sollte das doch auch ohne die *.var Datei gehen.
Habs aber nicht geschafft. Krieg immer einen Internal Server Error.
Wie müsste denn im Fall von gegzipten Dateien die *.var aussehen?Gruß (und immer noch nicht zur Aufgabe bereit)
Fritz-
Re!
- die wollen aber ausserdem noch eine *.var Datei sehen. Aber das brauch ich doch nur, um z.B. mehrere Versionen (z.B. verschiedene Sprachen) anzubieten.
Die Type-Map Files sind einfach ein anderes technisches Konzept, um das gleiche zu tun wie bei MultiViews. Beide haben dasselbe Ergebnis. Waehrend bei Multiviews die ganzen Parameter im Dateinamen kodiert werden, werden sie bei der anderen Variante in so eine Datei geschrieben. Man wuerde also entweder das eine oder das andere einsetzen, aber nicht beides zusammen (zumindest nicht im selben Verzeichnis).
Guckst Du: http://aktuell.de.selfhtml.org/artikel/server/alt-http/index.htm.
So long
--
Bier trinken fetzt!!! -
Hi Fritz,
- die wollen aber ausserdem noch eine *.var Datei sehen. Aber das brauch ich doch nur, um z.B. mehrere Versionen (z.B. verschiedene Sprachen) anzubieten.
was Du tun willst, ist technisch gesehen dasselbe (Du bietest eine komprimierte und eine unkomprimierte "Version" an und läßt den Server die Verhandlung anhand der vom Browser übermittelten HTTP-Header "Accept*" abwickeln).
Multiviews erlauben Dir, dies in einem eingeschränkten, aber meistens ausreichenden Umfang zu tun - wenn Du sehr komplizierte Verhandlungsmethoden nutzen wolltest, dann wäre die Verwendung der Varianten-Dateien möglicherweise notwendig (aber nicht in Deinem Fall).
Mit *.gz Dateien sollte das doch auch ohne die *.var Datei gehen.
Yep. MultiViews müssen in Deinem Fall reichen.
Habs aber nicht geschafft. Krieg immer einen Internal Server Error.
Und hast natürlich keinen Zugriff auf das error_log, wo die sprechende Fehlermeldung drin stehen würde? Tja, Server-Konfiguration ohne error_log ist ein Flug im dichten Nebel.
Hast Du denn das Privileg, "Options" innerhalb einer .htaccess-Datei verwenden zu dürfen?
("AllowOverride Options") Daran könnte es schon scheitern.
Laß Dir von Deinem Provider am besten gleich MultiViews komplett freischalten ...Wie müsste denn im Fall von gegzipten Dateien die *.var aussehen?
Wenn Du unbedingt wissen willst, wie es auf "die harte Tour" geht:
http://aktuell.de.selfhtml.org/artikel/server/alt-http/#a4Gruß (und immer noch nicht zur Aufgabe bereit)
Recht so.
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
-
-
-
-
-
-
-
-
-
-
mittlerweile gibt es HTML-'Komprimierer' wie Sand am Meer. Diese ersetzen bestimmte Teile einer HTML-Datei mit mehr oder minder äquivalenten, jedoch platzsparenderen Teilen und erzielen somit eine Reduzierung der Dateigröße.
Somit müsste rein rechnerisch der Upload auf den FTP sowie der Download in den Browser flotter vonstatten gehen.
Unfug. Wenn das tatsächlich etwas bringen sollte, dann hast _Du_ vorher schlechten Code geschrieben. Kaufst Du lieber ein gut konstruiertes Auto oder eines, das wegen Konstruktionsfehlern schon zehn Modifikationen hinter sich hat?
Es handelt sich so gesehen nicht um Komprimierer im üblichen Sinne, sondern um Codeausbesserer.Willst Du Deiner Leserschaft wirklich etwas sparen, dann setze gleich richtige Komprimierungsmethoden ein. Jeder aktuelle Browser versteht gzip-komprimierte Daten, je nach Inhalt sind Einsparungen bis 90% möglich - ohne Codefummelei.
Es sollte allerdings nicht unerwähnt bleiben, daß es gewisse Voraussetzungen für die Dokumente oder den Webserver gibt. Dafür ist die Methode aber auch seit Jahren standardisiert und passt sich automatisch Clients an, die gzip nicht verstehen.Wie das genau funktioniert, findest Du im Forumsarchiv: http://selfsuche.teamone.de/cgi-bin/such.pl?suchausdruck=multiviews+komprimiert&lang=on&feld=text&index_6=on&hits=10.
Gruß,
soenk.e -
Hi Peter,
mittlerweile gibt es HTML-'Komprimierer' wie Sand am Meer. Diese ersetzen bestimmte Teile einer HTML-Datei mit mehr oder minder äquivalenten, jedoch platzsparenderen Teilen und erzielen somit eine Reduzierung der Dateigröße.
es gibt viele mehr oder weniger funktionsfähige Ideen.
Eine solche Idee, die ich mal als Anregung der Diskussion zeigen möchte (ich bin gerade über den Link gestolpert und habe die Seite nur kurz angelesen), von der ich aber noch keine praktische Umsetzung kenne, ist:
http://www.ietf.org/rfc/rfc3229.txt
Ob das allerdings gerade bei HTML etwas bringen kann, hängt sicherlich sehr vom konkreten Einsatzfall ab.
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.