nicht angemeldet
Technik: HTML komprimiert übertragen
Im Web werden sinnvollerweise praktisch alle Daten komprimiert übertragen (GIF, JPG, ZIP) - nur HTML nicht. Mit JavaScript ist das aber möglich. Der Beweis:
das Original-Domument (19K HTML):
http://www.steffengerlach.de/htmlcompression/original.html
das komprimierte Dokument (nur 6K HTML):
http://www.steffengerlach.de/htmlcompression/compressed.html
Der Algorithmus ist nicht gerade ausgefeilt, erreicht in diesem Beispiel aber immerhin schon eine Kompressionsrate von 3:1.
Leider funktioniert das Ganze nur mit dem MSIE - Netscape zeigt nur eine leere Seite. Keine Ahnung, ob sich das Verfahren übertragen läßt. Ich habe jedenfalls in NS JavaScript noch keine Möglichkeit gefunden, HTML ins Dokument zu schreiben.
Was haltet ihr davon?
-
Was haltet ihr davon?
Ich weiß nicht. Wenn es die Möglichkeit gibt, den komprimierten Code in einen gängigen HTML-Editor zu laden und umgekehrt, wär das ne super Sache.
Ich frage mich, wie Du den Code überhaupt komprimiert hast.
Ist es nicht sinnvoll, nen Standard zu beschreiben? Meinetwegen .htc Dateien (HTML-compressed), bei denen alle Zeichen anhand von gängigen Komprimiermethoden komprimiert werden.
Gruß
Thomas
-
Hi allerseits,
Ist es nicht sinnvoll, nen Standard zu beschreiben? Meinetwegen .htc Dateien (HTML-compressed), bei denen alle Zeichen anhand von gängigen Komprimiermethoden komprimiert werden.
Wäre ja klasse, wenn man so was entwickeln würde, eine gute Idee. HTC ist allerdings schon vergeben, Microsoft nennt ihre HTML-Components so. Diese können zwar nicht komprimiert, aber genau wie HTML- und JS-Dateien verschlüsselt werden. Siehe http://msdn.microsoft.com/xml/articles/ICPXML.asp (ganz unten).
Gruß,
UlfL-
Hallo Ulf!
»»HTC ist allerdings schon vergeben, Microsoft nennt ihre HTML-Components so.
Dann mal gelich den richtigen Link zu "HTML Help" wie MS es nennt. Mit kostenlosen Sotfware zum erstellen von Windows Hilfedokumenten. (Die Sache muss ein ausrutscher von MS sein, denn es ist in der Tat brauchbar und gut! ;-) )
http://msdn.microsoft.com/workshop/c-frame.htm?935186362750#/workshop/author/htmlhelp/default.asp
Grüße
Thomas
-
-
-
Hallo Krabat
Was haltet ihr davon?
Nichts gegen die Idee der Komprimierung zur Uebertragungszeit - aber nicht unbedingt so! Denn das ist genau der Schritt zurueck ins Mittelalter der EDV, wo jeder seine eigenen Datenformate strickte. Deine komprimierten Daten wird z.B. keine Suchmaschine finden. Komprimierung ist zwar sinnvoll, aber Klartext ist in manchen Faellen noch wichtiger.
viele Gruesse
Stefan Muenz-
Deine komprimierten Daten wird z.B. keine Suchmaschine finden.
Das trifft auf den verwendeten, einfachen Algorithmus sicherlich zu. Das Grundprinzip - nämlich mehrfach vorkommenden Text nur einmal zu übertragen - verträgt sich aber durchaus mit der Funktionsweise von Suchmaschinen (abgesehen vielleicht von der Bewertung der Relevanz). Wenn man das Verfahren so modifiziert, daß es einzelne Wörter nicht mehr auseinanderreißt, ist dieser Nachteil schon mal stark verringert.
Wenn (wie in dem Beispiel) die Redundanz des Dokuments vor allem in den HTML-Tags liegt, könnte man sogar noch einen Schritt weiter gehen und die Kompression nur darauf anwenden, ohne große Einbußen bei der Kompressionsrate zu erleiden. Der eigentliche Text bliebe dann komplett erhalten.
-
-
Was haltet ihr davon?
Technisch gesehen erfordert Deine Idee
a) auf der Server-Seite die Ablage komprimierter Dokumente und
b) auf der Client-Seite die Aktivierung eines "plugins" zum Dekomprimieren.
Wenn Du das Ganze mit JavaScript realisieren willst, dann mußt Du Dein "plugin" mit übertragen. Wie groß ist das? Bei kleinen HTML-Dokumenten wird dieser Overhead schmerzhaft sein, bei großen weniger - aber die gelten in gewissem Sinne ja ohnehin als Fehldesign.
Der Caches des Besuchers könnte abgeschaltet sein, auf den kann man sich nicht verlassen, was die Ladezeit angeht (JavaScript in Datei auslagern und hoffen, daß es nur einmal geladen werden muß).
Außerdem erfordert Deine Technik, daß der Besucher JavaScript eingeschaltet hat, um überhaupt etwas zu sehen. Hat der das nicht, dann ist er völlig ratlos. Du zwingst ihm also Dein "plugin" auf - und überforderst ihn dabei möglicherweise.Viel sinnvoller wäre die Sache, wenn es tatsächlich ein standardisiertes Format "komprimiertes HTML" gäbe, welches von den Browsern unterstützt wird.
Wahrscheinlich sind wir gar nicht mehr weit davon entfernt: Bei Content negotiation melden die modernsten Browser bereits, daß sie bestimmte komprimierte Formate verstehen.
Mich würde nicht wundern, wenn man in einigen Monaten eine HTML-Datei einfach gezipt auf den Server legen kann und der Browser das dann automatisch korrekt anzeigen kann (eben weil es ein Standard ist - und das ist auch nicht schwieriger zu programmieren als die Anzeige von GIFs, und *das* können die Browser schon eine ganze Weile).Konkret für HTML-Dokumente läßt sich bei der Komprimierung eine ganze Menge herausholen. Wie bei jedem Klartextformat liegt der erzielbare Faktor etwa zwischen 3 und 12.
Allerdings wird eine "intelligente" Netzverbindung eine solche Komprimierung ganz von alleine vornehmen. Und das wäre ja auch sinnvoll so: Wenn wir Leitungskapazität sparen wollen, dann doch gleich für *alle* Dokumente - und nicht nur für diejenigen, deren Autoren explizit daran gedacht haben ...-
Wenn Du das Ganze mit JavaScript realisieren willst, dann mußt Du Dein "plugin" mit übertragen. Wie groß ist das? Bei kleinen HTML-Dokumenten wird dieser Overhead schmerzhaft sein, bei großen weniger - aber die gelten in gewissem Sinne ja ohnehin als Fehldesign.
Wie du in dem Beispiel siehst, ist das "plugin" genau 552 Bytes groß und in den 6K des komprimierten Dokuments schon mit enthalten. Du hast insofern recht, als das Verfahren unterhalb einer bestimmten Dateigröße (die aber im nur dreistelligen Byte-Bereich liegt!) nichts mehr bringt.
Außerdem erfordert Deine Technik, daß der Besucher JavaScript eingeschaltet hat, um überhaupt etwas zu sehen. Hat der das nicht, dann ist er völlig ratlos. Du zwingst ihm also Dein "plugin" auf - und überforderst ihn dabei möglicherweise.
Auf das komprimierte Dokument dürfte der Besucher eben nur dann umgeleitet werden, wenn er JavaScript aktiviert hat. Die anderen Besucher bekommen das umkomprimierte Dokument zu sehen und müssen die längeren Ladezeiten in Kauf nehmen.
Viel sinnvoller wäre die Sache, wenn es tatsächlich ein standardisiertes Format "komprimiertes HTML" gäbe, welches von den Browsern unterstützt wird.
Natürlich wäre das besser! Allerdings würden solche Dokumente dann einen noch neueren Browser voraussetzen als mein Verfahren, das "nur" JavaScript benötigt.
Allerdings wird eine "intelligente" Netzverbindung eine solche Komprimierung ganz von alleine vornehmen. Und das wäre ja auch sinnvoll so: Wenn wir Leitungskapazität sparen wollen, dann doch gleich für *alle* Dokumente - und nicht nur für diejenigen, deren Autoren explizit daran gedacht haben ...
Das ist nur teilweise richtig. Für jedes Datenformat ist nämlich ein anderer Kompressionsalgorithmus optimal. Stell dir vor, im Web würden statt JPG und MP3 die unkomprimierten Formate BMP und WAV stehen, und des Netzwerk würde darauf eine Standardkompression a la ZIP anwenden. Verlustlose Kompressionsalgorithmen arbeiten bekanntlich um Größenordnungen schlechter als verlustbehaftete Spezialverfahren. Und daß die Netzverbindung bei jedem Download eines Musikstücks eine MP3-Kompression durchführt, halte ich dann doch nicht für sonderlich sinnvoll.
-
-
Nachtrag: Es funktioniert jetzt auch mit Netscape-Browser.