nicht angemeldet
Jahreskalender Belegung - zuviele Bytes...
Hallo,
für einen Jahresüberblick Zimmerbelegung habe ich mal angefangen, mit Tabellen...;
je sechs Zeilen, für die 6 versch. Appartements, mal rund 30 Spalten, das ganze 12 mal. Ob die Zellen nun mit den Zahlen gefüllt sind oder nicht scheint egal, das ganze ist 50 kb groß. Farbfüllungen für die drei Saisontypen bringen das auf mehr als 80 kb.
Ich könnte natürlich das zerlegen, was mehr Seiten mit wenig kb bedeuten würde...;
hat jemand eine Idee, wie man das in allem "günstiger" sprich kleiner bauen kann?
Dank Frank
-
Huhu Frank
hat jemand eine Idee, wie man das in allem "günstiger" sprich kleiner bauen kann?
Also ich finde 80 KB für eine komplette Jahresübersicht vertretbar.
Evtl. kannst Du ja Deine Besucher vorher darauf hinweisen.Da ja das "Einfärben" je nach Saison immerhin eine Vergrösserung um 30 KB mit sich brachte, hast Du da ggf. einen ungünstigen Lösungsansatz gewählt.
Poste doch mal einen Link auf den aktuellen Stand, dann kann man konkreter werden.Viele Grüße
lulu
--
bythewaythewebsuxgoofflineandenjoytheday-
Huhu Lulu und Schockdoc1,
dank für die Anmerkung. Das mit der Datenbank kriege ich z.Z. nicht hin.
jetzt hatte ich auch übertrieben. 49 kb hat der Farbleere Kalender. Und wenn ich die Tabellen erstmal einfärbe und dann die betreffenden Spalten extra, dann werden es auch nur noch 6 kb mehr.
zu bewunder unter http://www.spinneimnetz.de/test/termineteil3.htm und http://www.spinneimnetz.de/test/termineteil4.htm
Dank Frank
-
Hello Frank,
zu bewunder unter http://www.spinneimnetz.de/test/termineteil3.htm und http://www.spinneimnetz.de/test/termineteil4.htm
Ich habe bei meinen CMS-Generierten Seiten ein ähnliches Problem, dass ich noch nicht zufriedenstellend gelöst habe:
Ich generiere menschlich lesbaren Code mit Kommentaren. Genau das hast Du auch gemacht. Du kannst die Filegröße um 25 - 35% verringern, wenn Du die Kommetnare und die unnötigen Leerzeichen und Zeilenumbrüche herausnimmst. Wenn keine Kompression verwendet wird, ist das sinnvoll. Sie werden dann ja mit übertragen.
Ich habe das bei deiner Version eben nur auf die Schnelle ausprobiert und 25,4% Verkleinerung geschafft. 55kB -> 41kB
Nun nochmal kurz zu meinem Anliegen, weil es hierzu passt:
Muss oder sollte man den User überhaupt "lesbaren2 Code ausliefern? Also welchen mit Einzügen und Umbrüchen und Leerzeilen und Kommentaren?Sagen wir mal NEIN, wie ereiche ich dann auf billige Art die unterschiedliche Formatierung der generierten Seiten zum Debug (da möchte ich es alles hübsch aufgeräumt haben) und zum Ausliefern an den Client?
Hat da eine eine praktikable Idee?
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Moin!
Sagen wir mal NEIN, wie ereiche ich dann auf billige Art die unterschiedliche Formatierung der generierten Seiten zum Debug (da möchte ich es alles hübsch aufgeräumt haben) und zum Ausliefern an den Client?
Du fragst also: Wie kriege ich die Tabelle für den echten Einsatz mutwillig unaufgeräumt?
Das einzige scheint mir da: Zwei Templates. Aber: Das ist natürlich auch nur dann toll, wenn man das zweite (für Live) aus dem ersten mit einem Tool generieren kann.
Ansonsten: Eine passende Funktion schreiben, die Kommentare, doppelte Leerzeichen und Zeilenumbrüche aus dem Code herausfiltert. Unter PHP fiele mir ob_start() & Co. ein, um die Skriptausgabe aufzufangen und noch mal nachzubearbeiten. Allerdings dürfte das unvorteilhaft viel Performance fressen.
- Sven Rautenberg
--
"Habe den Mut, dich deines eigenen Verstandes zu bedienen!" (Immanuel Kant)-
Hello,
Du fragst also: Wie kriege ich die Tabelle für den echten Einsatz mutwillig unaufgeräumt?
Ja, so ungefähr. Seitdem ich mal festgestellt habe, dass mein Ordnungsfimmel tatsächlich ca. 32% Overhead mehr bringt (also, man kann ca. 25% einsparen), mache ich mir Gedanken darüber. Aber um das Problem zu lösen, brauchte man eine IDE für PHP. Dann könnte man den Quellfile wahlweise ausgeben lassen für die Auslieferung und für die Entwicklung.
Das einzige scheint mir da: Zwei Templates. Aber: Das ist natürlich auch nur dann toll, wenn man das zweite (für Live) aus dem ersten mit einem Tool generieren kann.
Die würden dann generiert werden.
Ansonsten: Eine passende Funktion schreiben, die Kommentare, doppelte Leerzeichen und Zeilenumbrüche aus dem Code herausfiltert. Unter PHP fiele mir ob_start() & Co. ein, um die Skriptausgabe aufzufangen und noch mal nachzubearbeiten. Allerdings dürfte das unvorteilhaft viel Performance fressen.
Genau das befürchte ich. Angesichts aber immer schneller werdender Rechner und nicht einer momentan sichtbaren (vorläufigen) Grenze von 768kBit für die Allgemeinheit rechnet sich das ggf. schon. Man will ja seine Kunden oder die seiner Kunden nicht vergrätzen.
Bleibt immer noch die Frage offen, ob es überhaupt opportun ist, derart "komprimierten" Code auszuliefern.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
-
-
-
-
-
Hallo,
Du könntest deine Werte die du eintragen willst in eine Datenbank schreiben. Dann machst du mit PHP eine for bzw while-Schleife, in der du die Spalten ausliest und automatisch einträgst. Dann hast du eine Tabelle die genau richtig oft ausgegeben wird...
Shockdoc1
--
www.LiHo-Gaming.de Onlinegaming since 2oo2-
Moin!
Du könntest deine Werte die du eintragen willst in eine Datenbank schreiben. Dann machst du mit PHP eine for bzw while-Schleife, in der du die Spalten ausliest und automatisch einträgst. Dann hast du eine Tabelle die genau richtig oft ausgegeben wird...
Das ist natürlich richtig - aber das HTML, was ausgegeben wird, wird dadurch ja nicht kleiner.
Und genau das ist hier das Problem.
- Sven Rautenberg
--
"Habe den Mut, dich deines eigenen Verstandes zu bedienen!" (Immanuel Kant)
-
-
Moin!
je sechs Zeilen, für die 6 versch. Appartements, mal rund 30 Spalten, das ganze 12 mal. Ob die Zellen nun mit den Zahlen gefüllt sind oder nicht scheint egal, das ganze ist 50 kb groß. Farbfüllungen für die drei Saisontypen bringen das auf mehr als 80 kb.
Ich sehe bei diesen Seitengrößen eigentlich kein Problem. Es dürfte unmöglich sein, diese Datenmenge wirklich effektiv mit HTML-Mitteln zu verkleinern. Die einzige Methode (die ist dann aber auch super-effektiv) wäre, die Seite gezippt ausliefern zu lassen, also z.B. mod_gzip oder Content Negotiation zu verwenden.
Ich schätze mal, dass du bei "guten" Tabellenstrukturen durchaus eine Datei mit nur noch 10% der Originalgröße erhälst.
Sofern du deine Tabellen insofern sinnvoll aufbaust, dass sie nicht als eine Tabelle dargestellt werden, sondern einzeln - und auch von Tabellenlayouts Abstand nimmst, hast du auch den Besucher auf deiner Seite. Denn der sieht ja während des Ladens einen Fortschritt.
Ich denke nicht, dass sich Alternativen lohnen würden. Eine Grafik als GIF wäre vielleicht gleichgroß, mit Glück etwas kleiner. Aber natürlich viel aufwendiger zu warten.
Ich könnte natürlich das zerlegen, was mehr Seiten mit wenig kb bedeuten würde...;
Wenn die Zerlegung in einzelne Seiten sinnvoll ist, kannst du das natürlich tun. Ich hätte aber lieber eine Jahresübersicht, und nicht exakt am Monat abgeschnittene Termine. Insbesondere, wenn die Übersicht nicht puntuelle Termine, sondern Zeiträume darstellen soll.
Summa summarum: Eine 80KB-Seite ist absolut in Ordnung. Manche Seiten haben auf der Startseite eine doppelt so große Flash-Animation, oder reichlich dekorative, aber inhaltslose Grafiken. Da ist mir eine entsprechend große Übersicht doch viel lieber.
- Sven Rautenberg
--
"Habe den Mut, dich deines eigenen Verstandes zu bedienen!" (Immanuel Kant)-
Hallo!
Die einzige Methode (die ist dann aber auch super-effektiv) wäre, die Seite gezippt ausliefern zu lassen, also z.B. mod_gzip oder Content Negotiation zu verwenden.
hab ich da was falsch verstanden, oder liefern nicht sogar server, auf denen mod_gzip nicht installiert ist, auf anfrage eines gzip-fähigen browsers eine gzip-version der datei aus, wenn sie durch den anbieter auf dem server bereitgestellt wurde (also ohne dynamische komprimierung)?
freundl. Grüsse aus Berlin, Raik
-
Moin!
Die einzige Methode (die ist dann aber auch super-effektiv) wäre, die Seite gezippt ausliefern zu lassen, also z.B. mod_gzip oder Content Negotiation zu verwenden.
hab ich da was falsch verstanden, oder liefern nicht sogar server, auf denen mod_gzip nicht installiert ist, auf anfrage eines gzip-fähigen browsers eine gzip-version der datei aus, wenn sie durch den anbieter auf dem server bereitgestellt wurde (also ohne dynamische komprimierung)?
Richtig. Wenn es konfiguriert ist. Von alleine passiert das aber nicht.
- Sven Rautenberg
--
"Habe den Mut, dich deines eigenen Verstandes zu bedienen!" (Immanuel Kant)
-
-