HTML - Daten zwecks Übertragung komprimieren
Kalle_B
- programmiertechnik
Hallöle,
habe Zeitprobleme beim Anzeigen großer Listen.
Beispiel: Eine Personenliste hat 9 Spalten, 333 Zeilen.
Diese HTML- Datei ist 157 kB groß, dazu kommen noch zwei CSS- Dateien mit zusammen 9 kB.
Das PHP- Programm zur Erzeugung der Liste läuft 0,52 sec.
Aber bis zur kpl. Anzeige vergehen - je nach Layout - von 20 sec bis zu mehreren Minuten.
Am schlimmsten ist es, wenn ich die Spalten in jeder Zeile mit float:left nebeneinandersetze. Da rechnet Firefox sich heiss.
Und die Version
.sp01 {margin-left: 0%;width: 3%;margin-top:-1.2em;text-align:right}
.sp02 {margin-left: 4%;width: 30%;margin-top:-1.2em}
Klappt nicht, wenn <button> in der Zeile vorkommt. Habe keine Ahnung warum, aber bei <button> kommt immer eine Treppe dabei heraus.
Für den Aufbau einer Liste muss ja eine Unmenge an Redundanz geschickt werden. Pro Tabellenzelle z.B. <td></td>. Bei 3.000 Zellen also 27.000 redundante Zeichen.
Hat jemand mit irgend einer Art an Komprimierung Erfahrung?
Wie wäre es, eine "nackte" Javascript Tabelle zu schicken und sie vor Ort mit Javascript anzuzeigen?
Habe jetzt leider nicht die Zeit, das durchzuprobieren. Aber vermutlich ist diese Scriptsprache nicht gerade der Porsche auf der Datenautobahn und verschlimmbessert mein Problem nur noch.
Lieben Gruß, Kalle
P.S. Kann die Liste leider nicht posten, die Daten sind nicht öffentlich. Hoffe auch so auf Tipps.
Moin!
Beispiel: Eine Personenliste hat 9 Spalten, 333 Zeilen.
Also eine Tabelle.
Aber bis zur kpl. Anzeige vergehen - je nach Layout - von 20 sec bis zu mehreren Minuten.
Was durchaus an deinem Versuch liegen könnte, aus der Tabelle etwas anderes zu machen.
Am schlimmsten ist es, wenn ich die Spalten in jeder Zeile mit float:left nebeneinandersetze. Da rechnet Firefox sich heiss.
Hat jemand mit irgend einer Art an Komprimierung Erfahrung?
Es gibt beispielsweise mod_gzip, mod_deflate und die Ausgabepufferung und -komprimierung von PHP.
mod_gzip verkleinert die Forumshauptdatei hier (unkomprimiert etwa 450 KB) um über 85%.
Wie wäre es, eine "nackte" Javascript Tabelle zu schicken und sie vor Ort mit Javascript anzuzeigen?
Wird auch nicht schneller werden, weil du dann Javascript-Performance brauchst, die auch sehr fraglich und unterschiedlich ist.
- Sven Rautenberg
Moin!
Beispiel: Eine Personenliste hat 9 Spalten, 333 Zeilen.
Also eine Tabelle.
Könnte sein. Aber im SELFHTML Forum ist das doch ein "böses Wort"?
Es gibt beispielsweise mod_gzip, mod_deflate und die Ausgabepufferung und -komprimierung von PHP.
mod_gzip verkleinert die Forumshauptdatei hier (unkomprimiert etwa 450 KB) um über 85%.
Und die wird beim Anwender online ent-zippt?
Bitte mehr Information und Links zum Nachlesen, hört sich interessant an.
Kalle
hi,
Beispiel: Eine Personenliste hat 9 Spalten, 333 Zeilen.
Also eine Tabelle.Könnte sein. Aber im SELFHTML Forum ist das doch ein "böses Wort"?
Nein.
Sowas würde nur jemand behaupten wollen, der unreflektiert etwas nachplappert, was er gar nicht verstanden hat.
Tabellen sind alles andere als "böse", wenn du sie zur Auszeichnung tabellarischer Daten nutzt - sondern _genau dafür sind sie da_.
gruß,
wahsaga
hi,
Könnte sein. Aber im SELFHTML Forum ist das doch ein "böses Wort"?
Nein.
Sowas würde nur jemand behaupten wollen, der unreflektiert etwas nachplappert, was er gar nicht verstanden hat.
Ja, natürlich. Nur gut, dass wir beide so jemanden gar nicht kennen.
Tabellen sind alles andere als "böse", wenn du sie zur Auszeichnung tabellarischer Daten nutzt - sondern _genau dafür sind sie da_.
Okay, aber es ist rübergekommen, dass ich meine HTML- Datei verkleinern wollte und deshalb nach Alternativen zur Tabelle suchte?
Lieben Gruß, Kalle
Hallo
Okay, aber es ist rübergekommen, dass ich meine HTML- Datei verkleinern wollte und deshalb nach Alternativen zur Tabelle suchte?
Wenn es aber tabellarische Daten sind, ist eine Tabelle genau das Richtige.
Was die Komprimierung betrifft:
Wenn der Browser, bei der Anfrage nach der Datei, im Header die Information mitschickt, dass er komprimierte Inhalte entpacken kann, liefert der Server diese auch komrimiert aus. Fehlt diese Info, wird die Datei unkomprimiert gesendet.
Tschö, Auge
Hallo
Wenn es aber tabellarische Daten sind, ist eine Tabelle genau das Richtige.
die bei geeigneten Vorgaben gut zu rendern sein könnte. Du siehst ja: Wer Tabellen fälscht oder nachmacht, kann mit Renderzeiten von mehreren Minuten bestraft werden ;-)
Was die Komprimierung betrifft:
Wenn der Browser, bei der Anfrage nach der Datei, im Header die Information mitschickt, dass er komprimierte Inhalte entpacken kann, liefert der Server diese auch komrimiert aus. Fehlt diese Info, wird die Datei unkomprimiert gesendet.
Selbst wenn nur 80% erreicht würden, wäre das Datenvolumen der HTML-Datei von ca. 150kB auf ca. 30kB reduziert. Vom Quellcodeumfang sehe ich auch beim Missbrauch anderer Elemente sowieso wenig Optimierungsmöglichkeiten im Vergleich zu Tabellenzeilen. Die "redundanten" 30kB der Auszeichnung sollten sich übrigens für eine ordentliche Komprimierungsrate sorgen.
Freundliche Grüße
Vinzenz
Hallo
Wenn es aber tabellarische Daten sind, ist eine Tabelle genau das Richtige.
... Du siehst ja: Wer Tabellen fälscht oder nachmacht, kann mit Renderzeiten von mehreren Minuten bestraft werden ;-)
Keine Festungshaft unter erschwerten Bedingungen? ;-)
Was die Komprimierung betrifft:
Wenn der Browser, bei der Anfrage nach der Datei, im Header die Information mitschickt, dass er komprimierte Inhalte entpacken kann, liefert der Server diese auch komrimiert aus. Fehlt diese Info, wird die Datei unkomprimiert gesendet.Selbst wenn nur 80% erreicht würden, wäre das Datenvolumen der HTML-Datei von ca. 150kB auf ca. 30kB reduziert. Vom Quellcodeumfang sehe ich auch beim Missbrauch anderer Elemente sowieso wenig Optimierungsmöglichkeiten im Vergleich zu Tabellenzeilen.
Wie soll sowas auch gehen? Eine "endlos" verschachtelte Liste? Neun <div>s nebeneinander (Es waren ja wohl neun Werte pro Zeile/Datensatz.)?
Alles Lösungen, die höchstwahrscheinlich ohne Gewinn bei der Codemenge "auskommen".
Die "redundanten" 30kB der Auszeichnung sollten sich übrigens für eine ordentliche Komprimierungsrate sorgen.
Anzunehmen. Kalle kann ja auch mal darüber nachdenken, ob _alle_ Datensätze _zusammen_ ausgegeben werden müssen, oder ob er nicht z.B. eine alphabetische oder numerische Navigation einsetzt (alphabetisch wäre hier wohl zu bevorzugen).
Tschö, Auge
Hallo
Kalle kann ja auch mal darüber nachdenken, ob _alle_ Datensätze _zusammen_ ausgegeben werden müssen, oder ob er nicht z.B. eine alphabetische oder numerische Navigation einsetzt (alphabetisch wäre hier wohl zu bevorzugen).
Natürlich ist das enthalten. Ich kann wählen von Firma X.. bis Firma Y..
Aber die Liste wird von den Anwendern auch benutzt, um fehlende Einträge zu erkennen. Die sind ROT markiert.
Fehlende Einträge pro Adresse können sein:
Deshalb wird die Liste meistens komplett ausgegeben.
Ich weiss, man kann das auch alles halbautomatisch vor-auswählen. Aber die Anzahl der Programme ist jetzt schon reichlich hoch, da nimmt man gerne ein Vorhandenes und packt noch Funktionen dazu.
Und dann kommen diese Laufzeitprobleme ...
Lieben Gruß, Kalle
Hallo
... ob er nicht z.B. eine alphabetische ... Navigation einsetzt.
Natürlich ist das enthalten. Ich kann wählen von Firma X.. bis Firma Y..
Aber die Liste wird von den Anwendern auch benutzt, um fehlende Einträge zu erkennen. Die sind ROT markiert.
Lass mich überlegen. Anwender meint die, die Kunden sind, also in der Liste stehen, oder jene, die die Kunden(daten) verwalten?
Erstere interessieren sich für _alle_ Daten (auf einmal)? Letztere bearbeiten _alle_ Daten (auf einmal)?
Und dann kommen diese Laufzeitprobleme ...
Wie schon an anderer Stelle beschrieben (finde den thread gerade nicht), der Browser des Anwenders sendet bei der Anfrage im Header mit, ob er mit Komprimierung umgehen kann oder nicht. Somit wird das angeforderte Dokument komprimiert ausgeliefert oder halt unkomprimiert.
Ob du mit einer Optimierung des HTML-Codes erheblich besser kommst, wage ich zu bezweifeln. Du hast jetzt 333 Datensätze (bei denen es bestimmt nicht bleiben wird) á 9 Felder, die in der Tabelle ausgegeben werden sollen. Beantworte dir die oben gestellten Fragen[1] (Was will der Kunde oder der Bearbeiter in der Tabelle finden/mit der Tabelle tun?).
Mit einer einfach zu bedienenden Kombination aus z.B. alphabetischer Navi, Suchmöglichkeiten/Filtern und einer daraus resultierenden eingeschränkten Anzeige der Daten wäre die auszugebende Datenmenge jedenfalls stets geringer. Zumindest, wenn auch, ohne vom Benutzer erfolgte Vorauswahl, beispielsweise nur die Datensätze der ersten x Kunden ausgegeben werden.
[1] Unter der Voraussetzung, dass ich mit meiner ersten Frage (Für wen ist die Tabelle gedacht?) richtig liege.
Tschö, Auge
Hallo
Wie schon an anderer Stelle beschrieben (finde den thread gerade nicht)...
*gargelarks* Wer gucken kann, ist klar im Vorteil! *grmpf*
Tschö, Auge
hi,
Aber die Liste wird von den Anwendern auch benutzt, um fehlende Einträge zu erkennen. Die sind ROT markiert.
Fehlende Einträge pro Adresse können sein:
- Für Messebesucher noch keine Anwesenheit eingegeben
- .. noch keine Gesprächswünsche
- .. noch keine Gruppe gebildet
usw.Deshalb wird die Liste meistens komplett ausgegeben.
Warum werden dann nicht _nur_ die "fehlenden" Einträge ausgegeben, damit diese gezielt bearbeitet werden können?
Deren Anzahl sollte doch etwas überschaubarer sein.
gruß,
wahsaga
Hallo.
Warum werden dann nicht _nur_ die "fehlenden" Einträge ausgegeben, damit diese gezielt bearbeitet werden können?
Deren Anzahl sollte doch etwas überschaubarer sein.
Nicht nur die Anzahl. Auch die fehlenden Einträge selbst dürften gut zu übersehen sein.
MfG, at
hi,
Okay, aber es ist rübergekommen, dass ich meine HTML- Datei verkleinern wollte und deshalb nach Alternativen zur Tabelle suchte?
Ich habe nicht die Verkleinerung des Dokumentes als dein vordergründiges Problem verstanden, sondern die zum Rendering benötigte Zeit, vor allem auf Grund der Aussage
Am schlimmsten ist es, wenn ich die Spalten in jeder Zeile mit float:left nebeneinandersetze. Da rechnet Firefox sich heiss.
Bei einer Tabelle weiß der Browser bereits, wenn er deren Kopf, und dabei insbesondere die vordefinierten Spalten, "gelesen" hat, welches Teile jeweils nebeneinander darzustellen sind, und idealerweise auch schon in welcher Breite.
Wenn du Tabellenzellen jedoch durch nebeneinander gefloatete Elemente ersetzt, muss er bei jeder neuen solchen "Zelle" prüfen, ob sie noch neben die anderen passt, und auch ob er auf Grund eines clear wieder die nächste "Zeile" beginnen muss ...
Alle diese Informationen, die du ihm bei der Tabelle gleich von Anfang an mitteilen kannst, muss er hier für jede einzelne "Zeile" und jede einzelne "Zelle" beim Rendern erst mal wieder neu ermitteln.
Ja, als Browser würde ich mich dabei vermutlich auch ans Motto "ich bin hier auf der Arbeit, und nicht auf der Flucht" halten - und mir beim Rendern entsprechend mehr Zeit lassen.
wahsaga
Hallo!
Aber bis zur kpl. Anzeige vergehen - je nach Layout - von 20 sec bis zu mehreren Minuten.
Für mich klingt das nach Serverüberlastung oder einer Modemverbindung in Verbindung mit einer ziemlich schlechten Grafikkarte.
Am schlimmsten ist es, wenn ich die Spalten in jeder Zeile mit float:left nebeneinandersetze. Da rechnet Firefox sich heiss.
Weil Firefox nicht im Windowssystem integriert ist, braucht er im allgemeinen etwas länger als das MS-Gegenstück.
Wie wäre es, eine "nackte" Javascript Tabelle zu schicken und sie vor Ort mit Javascript anzuzeigen?
Dann würde trotzdem zuerst PHP abgearbeitet werden, erst dann Javascript.
Aber vermutlich ist diese Scriptsprache nicht gerade der Porsche auf der Datenautobahn und verschlimmbessert mein Problem nur noch.
Genau, und zweitens kann Javascript deaktiviert sein. Also lieber verzichten lernen.
Gruß, Matze