nicht angemeldet
Fressen Browser auch geTarte HTML-Files
Hallo Community,
die Diskussion ob man HTML-Files gleich zippen sollte oder nicht hatten wir unlängst hier im Forum.
Ich möchte mal nen Schritt weiter gehen, können/könnte man gleich mehrere
Dateien zusammenpacken und als Packet an den Client schicken?
Hintergrund:
Es gibt da ein beliebtes Programm Latex2Html das (La)Tex-files in
Html-Code konvertiert. Um Mathematische Formeln 1-zu-1 umzusetzen werden
diese in lauter kleine gifs/pngs gepackt und eingebunden.
Problem: Auf der partition unseres Linuxservers ist eine Blocksize von 4K
eingestellt, d.h. selbst wenn das bildchen nur 100 Bytes braucht werden
gleich 4K auf der Platte verbraten.
Folge: Bei vielen Formeln wird so mehr Platz verbraucht als wenn man
gleich die komplette Seite in ein großes Bild packt. Eine _sehr_ paradoxe
Situation, die im Web immer bei vielen kleinen Bildern auftritt.
Ich weiss das es bei Java sogenannte jar-Files gibt, wo mehrere Klassen in
ein tar-file gepackt und komprimiert übertragen werden.
Gibt es ein analogon für html?
Oder gibt es (anderer Ansatz) auch sowas wie inline-bilder wie bei manchen
Emails für HTML?
Viele Grüße
Rolf
-
Hallo Community,
die Diskussion ob man HTML-Files gleich zippen sollte oder nicht hatten wir unlängst hier im Forum.
Ich möchte mal nen Schritt weiter gehen, können/könnte man gleich mehrere
Dateien zusammenpacken und als Packet an den Client schicken?Geht sicher nicht, da der Browser das nicht wieder entpacken kann. Aber das Problem ist ja auch nicht der Browser, denn...
Hintergrund:
Es gibt da ein beliebtes Programm Latex2Html das (La)Tex-files in
Html-Code konvertiert. Um Mathematische Formeln 1-zu-1 umzusetzen werden
diese in lauter kleine gifs/pngs gepackt und eingebunden.Problem: Auf der partition unseres Linuxservers ist eine Blocksize von 4K
eingestellt, d.h. selbst wenn das bildchen nur 100 Bytes braucht werden
gleich 4K auf der Platte verbraten.... das Problem (wenn man es denn also solches bezeichnen möchte) ist der Webserver mit seiner Festplatteneinteilung. Ich sehe die Problematik noch nicht so ganz (Festplatten sind billig, Platzprobleme eigentlich kein Thema, aber Webspace ist natürlich immer irgendwie begrenzt).
Wenn du wirklich was dagegen tun willst, könntest du ein CGI-Skript basteln, welches aus einer Datei mit vielen Bildern das jeweils gewünschte Bild herausholt und an den Browser schickt. Das braucht natürlich Platz für das Skript, aber spart Platz bei den Bildern. Sozusagen eine CGI-gewordene Entpackroutine. Du mußt dann nur noch alle IMG-Links umändern.
Oder gibt es (anderer Ansatz) auch sowas wie inline-bilder wie bei manchen
Emails für HTML?Inline-Bilder funktionieren AFAIK mit Netscape und IE, das macht aber natürlich auch viel Arbeit, und die Bilddaten werden durch diesen Prozeß größer, weil eine Konvertierung in druckbare Zeichen vorgenommen wird.
- Sven Rautenberg
-
Hi
Wenn du wirklich was dagegen tun willst, könntest du ein CGI-Skript basteln, welches aus einer Datei mit vielen Bildern das jeweils gewünschte Bild herausholt und an den Browser schickt. Das braucht natürlich Platz für das Skript, aber spart Platz bei den Bildern. Sozusagen eine CGI-gewordene Entpackroutine. Du mußt dann nur noch alle IMG-Links umändern.
Wobei man dann wieder Serverbelastung gegen Plattenverbrauch aufrechnen muß,
und wie du schon treffend bemerkt hast ist Plattenplatz ja billig.allerdings könnte ich mir vorstellen das die übertragung von sagenwir mal
20 kleinen Bilder pro Page sowohl überproportionale Serverbelastung als auch
Bandbreitenbelastung bedeutet...
oder ist das HTTP-Protokoll so flexibel dass nach Analyse der HTML-Seite
dann alle Bilder auf einen "Rutsch" geholt werden?Oder gibt es (anderer Ansatz) auch sowas wie inline-bilder wie bei manchen
Emails für HTML?Inline-Bilder funktionieren AFAIK mit Netscape und IE, das macht aber natürlich auch viel Arbeit, und die Bilddaten werden durch diesen Prozeß größer, weil eine Konvertierung in druckbare Zeichen vorgenommen wird.
ich schaus mir mal an, Danke für den Tip!
Tschuess Rolf
-
allerdings könnte ich mir vorstellen das die übertragung von sagenwir mal
20 kleinen Bilder pro Page sowohl überproportionale Serverbelastung als auch
Bandbreitenbelastung bedeutet...
oder ist das HTTP-Protokoll so flexibel dass nach Analyse der HTML-Seite
dann alle Bilder auf einen "Rutsch" geholt werden?Mit HTTP 1.1 kann man über eine HTTP-Verbindung mehrere Dateien vom Server holen. Das bei HTTP 1.0 zeitraubende Vorgehen, für jede Datei eine neue Verbindung herzustellen entfällt dadurch. Alle modernen Browser nutzen HTTP 1.1. Wie gut sie das nutzen kann ich nicht sagen. Dieser Kanal wird ja nacheinander für verschiedene Dateien genutzt, so daß die Parallelkommunikation mit dem Server, um gleichzeitig mehrere Bilder anzufordern, je nach Lage der Dinge auch schneller sein kann. Du kannst den Browser meist konfigurieren, wie viele Verbindungen er parallel eingehen soll. Konservative Werte aus der Zeit von Netscape 3.0 und 28.8er-Modems waren 4 Verbindungen. Das hab ich ohne Probleme auf 15 oder 20 hochgesetzt und damit eine subjektive Geschwindigkeitssteigerung festgestellt.
Was die Bandbreite angeht: Die Daten müssen so oder so über die Leitung - da ist die Art des Abrufes recht egal. Interessant ist da nur, ob irgendeine Leitung Kompression nutzt. (siehe Diskussion über gezippe HTML-Dateien)
- Sven Rautenberg
-
-